Live data from Hacker News

Reflections on leaving Haskell

alsonkemp.com

11–20 of 24 posts

Re: Reflections on leaving Haskell

#11
post #3

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 satis…

I'm really just beginning to learn Haskell while working professionally with Ruby. My gut instinct is that with Haskell you have to put in a lot of extra effort but you are repaid doubly in robustness. Obviously in real world scenarios there is a balance to be struck since a lot of code is just for throw-away purposes, or failure around edge cases does not affect the bottom line. However I suspect that the lack of traction Haskell gets in the commercial software world is more a result of human nature than actual economics of long-lived software projects.

The reason I'm bullish on Haskell is because I suspect it can be a significant competitive advantage in a lot of the type of data processing scenarios that start out simple in a startup, but can become slow/buggy/unmaintainable over time.

Re: Reflections on leaving Haskell

#13
post #2

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

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-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."

Re: Reflections on leaving Haskell

#14
post #3

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 satis…

I'm really just beginning to learn Haskell while working professionally with Ruby. My gut instinct is that with Haskell you have to put in a lot of extra effort but you are repaid doubly in robustness. Obviously in real world scenarios there is a balance to be struck since a lot of code is just for throw-away purposes, or failure around edge cases does not affect the bottom line. However I suspect that the lack of tr…

+1. I'm wondering what will be Haskell's killer app, aside GHC ;)

Re: Reflections on leaving Haskell

#15
post #3

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 satis…

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.…

The Writer monad is better suited to logging than IO.

http://www.haskell.org/all_about_monads/html/writermonad.htm...

Re: Reflections on leaving Haskell

#16
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.

Re: Reflections on leaving Haskell

#17
post #14

Earlier quoted context omitted.

I'm really just beginning to learn Haskell while working professionally with Ruby. My gut instinct is that with Haskell you have to put in a lot of extra effort but you are repaid doubly in robustness. Obviously in real world scenarios there is a balance to be struck since a lot of code is just for throw-away purposes, or failure around edge cases does not affect the bottom line. However I suspect that the lack of tr…

+1. I'm wondering what will be Haskell's killer app, aside GHC ;)

Xmonad!

Re: Reflections on leaving Haskell

#18
post #16

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…

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

Re: Reflections on leaving Haskell

#19
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.

Re: Reflections on leaving Haskell

#20
post #2

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

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.

Post reply on HN