6 ms·

Reflections on leaving Haskell

64 points by semmons 17y ago

jgrant27 17y ago
"And without Haskell I would be trapped in Scala-land, writing syntax-sugared-Java, confused about why functional programming was so great…"
- deleted 17y ago
  [deleted]
- sreque 17y ago
  I'm starting to take this particular criticism as a major compliment to Scala. Scala makes it really easy to get stuff done and you're not forced to write functional solutions to imperative problems. Also, I learned more from functional programming in Scala than I did when learning about Lisp. For one, Scala's default data structures are persistent and immutable, whereas the Lisp ones are mutable. Scala's library also operates better on abstract data types, whereas most functions in traditional Lisps operate on concrete data types, making Scala again more functional. The above two points, by the way, highlight two major problems Rich Hickey had with traditional Lisps and therefore why he decided to write Clojure. See http://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/ http://www.simple-talk.com/opinion/geek-of-the-week/rich-hic.... "Even Lisps are built on some primitive things, and those primitive data structures in traditional Lisps are mutable. I wanted the core data structures of Clojure to be immutable. In addition, I wanted the core algorithms to be based upon abstractions rather than concrete data structures as in traditional Lisps. These are things that can't be retrofitted in a compatible way."
- xtho 17y ago
  I personally think it's sad that hardly anybody mentions OCaml or F# as alternatives to haskell. For a while I had the impression that OCaml had the potential to become really big but now it seems to have slipped people's minds. BTW it sounds odd to me that the author wasn't able to compile a hello world program and that he calls the error messages of the OCaml compiler incomprehensible. I could understand calling OCaml's type system complex (in comparison to the usual suspects). And I still don't get the clojure hype. I probably would change my mind if there were a native clojure interpreter (like jruby for ruby) but the way it is you're tied to the jvm which precludes clojure from many use cases where a dynamically typed language would be preferable.
- jimbokun 17y ago
  Instead, he can now see that Clojure is the more enlightened JVM language.
plesn 17y ago
The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??). Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satisfying way) or bad (others have to understand it...).
- coffee_dregs 17y ago
  plesn, I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the issues/reasons are basic that it's hard... Also, I'm confused by your comment about the IO monad & logging... How would you log outside of the IO monad? Would also be cool if you'd point me to your Haskell repo. I'd be curious to see how you solve these problems. - Alson
  - jrockway 17y ago
    How would you log outside of the IO monad? By collecting status messages in addition to computation results. The Writer monad is one (convenient) way to do this.
    - harshavr 17y ago
      Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?
      - tel 17y ago
        It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.
Miky 17y ago
I'm not arguing that Haskell can't improve in a lot of ways, but his complaints all seem to stem from attempting to program in Haskell using idioms that don't work well there. If you want to incrementally add to a data structure, use currying, or multiple constructors if that fits better. Don't use Maybes, and definitely don't subclass datatypes. He doesn't really seem to understand monads at all. If you want to log something, use a monad like Writer, not IO.
- coffee_dregs 17y ago
  Agreed that, in some senses, I was trying to force a square peg into a round hole, but the comments on my blog suggest that others share my experience and they're mostly from planet.haskell.org. So I think something is missed if my experience is entirely chalked up to ignorance. My post was written fairly quickly and got more attention than I expected. Looking at it again and looking at Turbinado's code, I can see how you could suggest that I don't understand monads. And I probably don't understand them to your level, but the code reflects the result of trying to compose together a number of libraries into a sensible system. Wrapping those libraries in composed monad transformers was vastly more complicated than just dropping down to the IO monad, so I stripped down... w.r.t monads: they're lovely for constraining code behavior and for building DSLs, so other languages have added monad libraries. They haven't forced the entire language to live within monads... w.r.t incremental data structures: I mentioned in my post that I wasn't happy with multiple data types. Multiple constructors sound even less productive. Currying is a solid suggestion. - Alson
iman 17y ago
The problem with Haskell is that it is way ahead of its time, in kind of the same way that lisp was ahead of its time. lisp had high order functions and garbage collection, and now 30 years later all mainstream languages have these features. Haskell has lazy evaluation, compiler enforced function purity and a type checker that doesn't get in your way. I predict that in 30 years all mainstream languages will have these features.
- Xichekolas 17y ago
  Well said, but I don't think it's a problem per se. Lisp was way ahead of its time, but it also hung around until everyone caught up with it. Programmers tend to think about code at the level of the most powerful language they know. Show someone partial application who has never used it and they say "that's a neat trick I guess", but take partial application away from someone that is used to it, and they suddenly feel like something vital is missing. So at the moment, Haskell's new ideas seem at best to be "neat tricks" and at worst "confusing" to most programmers, but, as with Lisp, those ideas and features will get added to other more mainstream languages a bit at a time. Haskell's contribution probably won't happen because a bunch of people go out and learn Haskell, but because it's ideas will slowly move the cluster of mainstream languages up the curve.
- andrewcooke 17y ago
  that's all true, but the type system in haskell is hard. it seems to me that means one of the following: * i am old and stupid, and the next generation will find it easy (although i was about ten years younger when i first tried haskell, and it was simpler then...) * technology will advance and better abstractions and/or interfaces will be found. * programming really is that hard. personally i hope for the second, suspect the first, and fear the third :o)

64 points by semmons 17y ago

"And without Haskell I would be trapped in Scala-land, writing syntax-sugared-Java, confused about why functional programming was so great…"

deleted 17y ago
[deleted]
sreque 17y ago
I'm starting to take this particular criticism as a major compliment to Scala. Scala makes it really easy to get stuff done and you're not forced to write functional solutions to imperative problems. Also, I learned more from functional programming in Scala than I did when learning about Lisp. For one, Scala's default data structures are persistent and immutable, whereas the Lisp ones are mutable. Scala's library also operates better on abstract data types, whereas most functions in traditional Lisps operate on concrete data types, making Scala again more functional. The above two points, by the way, highlight two major problems Rich Hickey had with traditional Lisps and therefore why he decided to write Clojure. See http://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/ http://www.simple-talk.com/opinion/geek-of-the-week/rich-hic.... "Even Lisps are built on some primitive things, and those primitive data structures in traditional Lisps are mutable. I wanted the core data structures of Clojure to be immutable. In addition, I wanted the core algorithms to be based upon abstractions rather than concrete data structures as in traditional Lisps. These are things that can't be retrofitted in a compatible way."
xtho 17y ago
I personally think it's sad that hardly anybody mentions OCaml or F# as alternatives to haskell. For a while I had the impression that OCaml had the potential to become really big but now it seems to have slipped people's minds. BTW it sounds odd to me that the author wasn't able to compile a hello world program and that he calls the error messages of the OCaml compiler incomprehensible. I could understand calling OCaml's type system complex (in comparison to the usual suspects). And I still don't get the clojure hype. I probably would change my mind if there were a native clojure interpreter (like jruby for ruby) but the way it is you're tied to the jvm which precludes clojure from many use cases where a dynamically typed language would be preferable.
jimbokun 17y ago
Instead, he can now see that Clojure is the more enlightened JVM language.

plesn 17y ago

The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??). Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satisfying way) or bad (others have to understand it...).

coffee_dregs 17y ago
plesn, I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the issues/reasons are basic that it's hard... Also, I'm confused by your comment about the IO monad & logging... How would you log outside of the IO monad? Would also be cool if you'd point me to your Haskell repo. I'd be curious to see how you solve these problems. - Alson
- jrockway 17y ago
  How would you log outside of the IO monad? By collecting status messages in addition to computation results. The Writer monad is one (convenient) way to do this.
  - harshavr 17y ago
    Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?
    - tel 17y ago
      It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.

Miky 17y ago

I'm not arguing that Haskell can't improve in a lot of ways, but his complaints all seem to stem from attempting to program in Haskell using idioms that don't work well there. If you want to incrementally add to a data structure, use currying, or multiple constructors if that fits better. Don't use Maybes, and definitely don't subclass datatypes. He doesn't really seem to understand monads at all. If you want to log something, use a monad like Writer, not IO.

coffee_dregs 17y ago
Agreed that, in some senses, I was trying to force a square peg into a round hole, but the comments on my blog suggest that others share my experience and they're mostly from planet.haskell.org. So I think something is missed if my experience is entirely chalked up to ignorance. My post was written fairly quickly and got more attention than I expected. Looking at it again and looking at Turbinado's code, I can see how you could suggest that I don't understand monads. And I probably don't understand them to your level, but the code reflects the result of trying to compose together a number of libraries into a sensible system. Wrapping those libraries in composed monad transformers was vastly more complicated than just dropping down to the IO monad, so I stripped down... w.r.t monads: they're lovely for constraining code behavior and for building DSLs, so other languages have added monad libraries. They haven't forced the entire language to live within monads... w.r.t incremental data structures: I mentioned in my post that I wasn't happy with multiple data types. Multiple constructors sound even less productive. Currying is a solid suggestion. - Alson

iman 17y ago

The problem with Haskell is that it is way ahead of its time, in kind of the same way that lisp was ahead of its time. lisp had high order functions and garbage collection, and now 30 years later all mainstream languages have these features. Haskell has lazy evaluation, compiler enforced function purity and a type checker that doesn't get in your way. I predict that in 30 years all mainstream languages will have these features.

Xichekolas 17y ago
Well said, but I don't think it's a problem per se. Lisp was way ahead of its time, but it also hung around until everyone caught up with it. Programmers tend to think about code at the level of the most powerful language they know. Show someone partial application who has never used it and they say "that's a neat trick I guess", but take partial application away from someone that is used to it, and they suddenly feel like something vital is missing. So at the moment, Haskell's new ideas seem at best to be "neat tricks" and at worst "confusing" to most programmers, but, as with Lisp, those ideas and features will get added to other more mainstream languages a bit at a time. Haskell's contribution probably won't happen because a bunch of people go out and learn Haskell, but because it's ideas will slowly move the cluster of mainstream languages up the curve.
andrewcooke 17y ago
that's all true, but the type system in haskell is hard. it seems to me that means one of the following: * i am old and stupid, and the next generation will find it easy (although i was about ten years younger when i first tried haskell, and it was simpler then...) * technology will advance and better abstractions and/or interfaces will be found. * programming really is that hard. personally i hope for the second, suspect the first, and fear the third :o)