
Reflections on leaving Haskell - semmons
http://www.alsonkemp.com/haskell/reflections-on-leaving-haskell/
======
Miky
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
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
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
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.

------
plesn
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
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
_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
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
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.

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

~~~
sreque
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...](http://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-
of-the-week/).

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

