A philosophical difference between Haskell and Lisp (2015)
1–10 of 181 posts
Re: A philosophical difference between Haskell and Lisp (2015)
#2When I was new to Haskell (and also not an experienced programmer), the following example on “functional style” had a huge positive impact on me -- where the same program is re-written in ten different ways, each time making it more modular & composable: http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
(section 3.1... Feel free to ignore everything before/after that)
It feels so much easier to both understand and modify the evolved version of the code.
Re: A philosophical difference between Haskell and Lisp (2015)
#3Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
Re: A philosophical difference between Haskell and Lisp (2015)
#4Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
For one Lisp is not lazy like Haskell.
Re: A philosophical difference between Haskell and Lisp (2015)
#5I wonder if the fat macro eDSL wasn't just a temporary trend in lisp. Some lispers like small and composable.. after all that was part of the reason behind scheme. picolisp is also very combinatorics in mindset. Clojure likes that too (even though it came after the fp revival).
Re: A philosophical difference between Haskell and Lisp (2015)
#6Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
Clojure takes that approach
Re: A philosophical difference between Haskell and Lisp (2015)
#7This is interesting to read having worked with Clojure, but never Haskell or CL. I expected the Haskell examples to look alien and the CL to look familiar, but the idiomatic Clojure solutions to the examples are almost identical to the Haskell solutions. E.g.
take 5 . filter (not . p) . drop 3
(->> s (drop 3) (filter (complement p)) (take 5)) ; for some sequence s
Re: A philosophical difference between Haskell and Lisp (2015)
#8Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
For one Lisp is not lazy like Haskell.
I don’t understand why the above got down-voted... Without fusing (lazy) loops, having a bunch of independent sequential transformations (each with its own loop) can make the same computation significantly slower!
Re: A philosophical difference between Haskell and Lisp (2015)
#9Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
For one Lisp is not lazy like Haskell.
Not super familiar either language, how does lazy evaluation promote the use of smaller functions?
Re: A philosophical difference between Haskell and Lisp (2015)
#10Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
For one Lisp is not lazy like Haskell.
The article elaborates on this point a bit:
> Like pipes in UNIX, the functions are clever enough to be performant when composed together–we don’t traverse the whole list and generate a new list each time, each item is generated on demand. In fact, due to stream fusion, the code will be compiled into one fast loop.
I imagine it is hard to do the same optimization in a non-lazy language.