A philosophical difference between Haskell and Lisp (2015) • Hacker News Board

Re: A philosophical difference between Haskell and Lisp (2015)

#131

Post by kizer » Mon, Aug 03, 2020, 4:26 AM UTC

mncharity wrote: post #114

cc_ashby wrote: post #17

There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…

> There is a strange... kind of poetry with Haskell. It is like math on wheels [...] pure and dream-like For me too there is a feeling of poetry... but for me it's more the nails-on-blackboard grating of awful poetry, and the ice-pick-to-ears screeching of abrading subway wheels. :) Lisps merely inspire me towards elegant craftsmanship. But Haskell tempts me to dream of more. It's my fault, but ouch. Dreams of math m…

God, reading these comments generates inspiration in me to create a pristine, beautiful language for you all to lust over. Lolol

Re: A philosophical difference between Haskell and Lisp (2015)

#132

Post by kizer » Mon, Aug 03, 2020, 4:29 AM UTC

enriquto wrote: post #53

alentist wrote: post #44

Earlier quoted context omitted.

This comment would be more informative if you briefly explained why you abhor it and hate almost everything about it.

Yep, sorry. This is a matter of feeling, completely irrational, but just my experience. When I program in lisp I get the same feeling when I'm solving an ODE by hand, or a Diophantine equation, or designing a numerical method to approximate the solution of a PDE, or finding the Euler-Lagrange equations of a physical problem. The thing is real and it gets shit done really fast; it is just exhilarating. Moreover, lisp…

Now I want to really learn math. Is the aesthetic experience comparable to programming? Probably greater. I need something where I can invent if I want to get my fix. As a layperson, math never scratched that itch entirely (aside from proofs which as we know are basically programming).

Re: A philosophical difference between Haskell and Lisp (2015)

#133

Post by wirrbel » Mon, Aug 03, 2020, 5:09 AM UTC

Its a great article, unfortunately it barely mentions Lisp's function composition capabilities and thats a bit unfortunate because it makes I guess a nice case for differences in API design in Haskells standard library and Common Lisp's.

Lisp did in fact pioneer the introduction of higher-order functions and function composition into programming language and its fairly remarkable that lisps are still around and highly versatile / usable.

What's being shown are Collection Pipelines(https://www.martinfowler.com/articles/collection-pipeline/) which can be implemented in lisp and in fact are. Clojure and Scheme for sure have these procedures and I am sure they are available for common lisp as well.

Whether one prefers Haskell or Lisp is probably in parts a subjective decision (and also has to do with socialisation). I think I am falling onto the lisp side of things because of the explorative nature of programming and I had my heureka moment of programming with Test-Driven Development and for some reason I am gravitating to that in my programming and its easier to do TDD without a type-checker actually.

For anyone who is curious about exploring Lisps, I suggest having a look at Clojure or Common Lisp (potentially Dylan if you don't want to bother with parentheses) and not Scheme (because it doesn't have polymorphism and is heavily fragmented).

Re: A philosophical difference between Haskell and Lisp (2015)

#134

Post by ajarmst » Mon, Aug 03, 2020, 5:12 AM UTC

eru wrote: post #125

ajarmst wrote: post #60

This seems to imply that extensive use of composition in Haskell is a notable stylistic decision rather than an entailed effect of the fundamental design choices (first-class functions, lazy evaluation, type classes) that explicitly encourage such composition and a terse, mathematical syntax that makes the composition operation obvious. Heavy use of Composition is idiomatic in lisps, too. It’s just the syntax doesn’t…

> It’s pretty common to see form in lisp that ends in a dozen close-parentheses as we see chains of forms being passed as arguments to other forms. That's just a chain of function applications. Function composition puts the emphasis on the fact that functions are values in their own right and can be manipulated (eg with a composition operator) as objects without regard to any values they might act on. If you want to…

I’m not convinced that chain application and composition are meaningly distinct in anything but a syntactic sense if the language in question offers first-class functions and deterministic evaluation (eg no side effects). In mathematics, composition ($f \circ g$) is invariably described in terms of chaining f(g())—in fact, the composition operator is usually defined as alias for chaining. Yes, there are subtleties I’m glossing, but I don’t think support the thesis that function chaining and composition are significantly different at this level (i.e. the level of syntax and idiom rather than the level of Category Theory).

Re: A philosophical difference between Haskell and Lisp (2015)

#135

Post by galaxyLogic » Mon, Aug 03, 2020, 5:12 AM UTC

I think it is much because Common Lisp standard library was written in the keywords-fashion. I assume it could have been written also using small composable functions. No?

Re: A philosophical difference between Haskell and Lisp (2015)

#136

Post by ajarmst » Mon, Aug 03, 2020, 5:14 AM UTC

eru wrote: post #125

ajarmst wrote: post #60

This seems to imply that extensive use of composition in Haskell is a notable stylistic decision rather than an entailed effect of the fundamental design choices (first-class functions, lazy evaluation, type classes) that explicitly encourage such composition and a terse, mathematical syntax that makes the composition operation obvious. Heavy use of Composition is idiomatic in lisps, too. It’s just the syntax doesn’t…

> It’s pretty common to see form in lisp that ends in a dozen close-parentheses as we see chains of forms being passed as arguments to other forms. That's just a chain of function applications. Function composition puts the emphasis on the fact that functions are values in their own right and can be manipulated (eg with a composition operator) as objects without regard to any values they might act on. If you want to…

And thanks for the link to the loop monad. I didn’t know it or forgot. I don’t know whether to be delighted or appalled.

Re: A philosophical difference between Haskell and Lisp (2015)

#137

Post by bollu » Mon, Aug 03, 2020, 5:44 AM UTC

sukilot wrote: post #124

dan-robertson wrote: post #88

I think it should be stressed that most languages (except maybe bash I guess) can’t provide the kind of compositionality that Haskell does. This is because Haskell’s lazy evaluation allows these compositions to do an asymptotically appropriate amount of work. Consider this Haskell: xs = [1..20] p n = if n If a strict language were being used then the processing would be as follows: 1. drop 3 ys is [4..20] 2. When com…

Since bash and the Unix core utils are written in C, I strongly challenge your claim that "most languages" can't do stream processing. You don't have to have a lazy language to implement a lazy data type.

The difference is between pervasive laziness (laziness by default) v/s laziness by opt-in.

If you have laziness by opt-in, then most parts of the language will not opt-in [from prior experience with, say, racket which also has lazy streams].

It's the pervasive and efficient compilation of laziness in Haskell which makes it actually useful to write lazy programs.

Now, am I a fan of writing lazy programs? No, I find the upshot of referential transparency gained by laziness to be overshadowed by the warts it brings --- lack of a good debugging experience, tie-the-knot semantics being fragile, etc. I'd rather live in a strict total programming language.

But one cannot "handwave" away laziness in haskell that easily by saying "you can emulate it in $STRICT_LANGUAGE". By the exact symmetric argument, one can emulate strict code inside haskell: just use `ST` or `IO`. But very rarely does one see whole libraries written strictly, because this style of code doesn't compose with the (default) laziness and purity in haskell.

Re: A philosophical difference between Haskell and Lisp (2015)

#138

Post by dan-robertson » Mon, Aug 03, 2020, 7:26 AM UTC

reikonomusha wrote: post #101

dan-robertson wrote: post #84

Earlier quoted context omitted.

Strictly speaking, Common Lisp does not have series because they were not included in ANSI Common Lisp. Therefore even though you could use the macros provided with a separate streams package, you’d need to make sure that all your code used that package (rather than the CL definitions of let and lambda and so on) and properly declared stream functions. This ends up making code using streams not super composable which…

GHC does have special support for fusion and rewriting. See e.g. [1]. The laziness comes with the language, but turning it efficient requires a series of these rewrite rules expressed as GHC-specific metadata. [1] https://markkarpov.com/tutorial/ghc-optimization-and-fusion....

I was referring to the RULES pragma. My argument was that it is a general mechanism and not a built in understanding of list functions in the compiler. I suppose I ought not conflate the with Haskell but approximately everyone uses ghc.

Re: A philosophical difference between Haskell and Lisp (2015)

#139

Post by tsimionescu » Mon, Aug 03, 2020, 7:41 AM UTC

dan-robertson wrote: post #91

dllthomas wrote: post #86

Uh guys? [1]> (remove-if-not #'evenp `(1 2 3 4 5 6 7 8 9 10) :count 3 :start 1) (1 2 4 6 8 9 10) As pointed out by owl57, the Haskell translation is incorrect and the correct implementation isn't quite so trivial. I don't see a way to pull the :count argument out into a separate function. We certainly can for skip, though, and I might. Prelude> skipThen 1 (removeIfNot even 3) [2,3,4,5,6,7,8,9] [2,4,6,8,9] as implemen…

You’re lisp syntax is weird but you’re right: The start argument specified where to start removing things and the end or count arguments specify where to stop removing things (ie at an index or after a certain number of elements respectively). I claim this is a pretty good argument against the keyword arguments as they don’t necessarily do what one expects.

Honestly, I think the mistake comes from thinking of `remove-if(-not)' as `filter'.

When I see code saying (remove-if #'condition '(1 2 3 4 5 6) :start 5 :count 3), I would be pretty surprised if it removed anything prior to the 5th element. :count is worse, just by looking at this code I would not be sure whether it would always remove 3 elements (at most) or if it would remove all elements within a subsequence of 3 elements starting at index 5.

Re: A philosophical difference between Haskell and Lisp (2015)

#140

Post by lispm » Mon, Aug 03, 2020, 7:46 AM UTC

nabla9 wrote: post #87

Deeper philosophical differences: * Lisp is multi-paradigm languages. Haskell is pure functional language. * Haskell wants to be mathematics. Lisp wants to be an operating system. I believe the composition vs. monolithism difference comes from these deeper differences.

> Lisp wants to be an operating system.

Lisp wants to be interactively used.