Kevin's Weblog

2008-02-12

Last night at the Portland Functional
Programming Study Group, someone claimed that 90% of learning
Haskell is figuring out monads. I replied back, “The problem is that
the first 90% of learning Haskell is figuring out monads; the
second 90% is figuring out arrows; the third 90% is figuring out
monad transformers...”

In seriousness, we had a good discussion about the issues
“practical programmers” have with using Haskell, which largely has
to do with the need to learn seemingly irrelevant mathematical
abstractions to get almost anything done. Sure, the difficulty of
doing IO is vastly overblown. However, if you looks at my series
on writing a web spider (1,
2,
3)
you’ll see an example of this. HaXML failed, not because using monads
is hard, but because properly separating pure and monadic tasks is
hard. In particular, parsing a DTD is not a pure function! HXT
required learning about arrows, then about derivatives of regular
expressions. I ran into a problem with leaking file descriptors,
which I assumed had something to do with laziness so I learned about
strictness annotations, but in fact Paul
Brown recently showed that it’s actually an error
handling bug in Network.HTTP. I finally got a working
program, which I then proceeded to never use because it takes too
damn long to run and trying to figure out how to add concurrency
just felt too overwhelming at that point, as it would undoubtedly
require some new abstraction to learn, and I was just out of steam.

Comments

Mike wrote:

Yeah, this is about where I ended up, too (although I didn't write much code). Although there are many things about Haskell that seem cool, the whole purity thing is just a huge practical stumbling block. We have a fairly liberal environment where I work, so I could entertain things like this, but how can I possibly justify it? If I get hit by a bus, they'd have to toss everything I wrote in Haskell...

Your examples don't seem to have anything to do with learning mathematical abstractions, but more to do with particular libraries having poor docs, if anything.

(2008-02-12 15:01)

lechesnay wrote:

I hear that there is that fast language made by some French guys and that lives in the same monad as you and I do, and people do pretty nifty network and systems programming with it. It's called Oh Caml or something...

(2008-02-12 15:08)

chrisk wrote:

It looks like 2 difficulties: poor library documentation is one problem. But that can be overcome if one already knows how similar systems are designed and used. The second problem is that the library's design and use is unfamiliar. Whether to label this unfamiliarity as an "irrelevant mathematical abstraction" is a labeling debate.

I think we all learned forms of abstract thinking when learning to program, and Haskell just has a slightly different set of abstractions than those in C/C++/Java.

(2008-02-12 15:13)

Justin George wrote:

Hey, that was me! Cheers.

(2008-02-12 15:18)

Eric Mertens wrote:

I think you've managed to make some terribly misguided generalization from your experiences with a single user-contributed library (HXT).

I replied back, “The problem is that the first 90% of learning Haskell is figuring out monads; the second 90% is figuring out arrows; the third 90% is figuring out monad transformers...”

Let's ignore the fact that 90% of 10% is 9% and that 90% of 1% is 0.9% (gee, things sure are getting easier). Hopefully someone corrected you last night, but in case they didn't; Programming in Haskell generally does not use arrows and like you stated, the extra 0.9% needed to go from using monads to monad transformers is pretty painless, yet are not a necessity for general Haskell programming.

Bloggers seem to be in the business of getting attention by being controversial, but you should be able to do that without just being wrong.

(2008-02-12 15:24)

Tac-Tics wrote:

The only thing hard about learning Monads is spending too much time trying to learn __what__ they are. Learning how to use them is really not so bad. Or it wouldn't be if more of the tutorials did less handwaving ;-) But once you understand IO, State, and List the rest are all just variations (STM, Reader) or very specialized (Parsers and Cont).

@chrisk: yes, we can debate what's a "mathematical abstractions" or not. The point is probably more that not only is the Haskell learning curve steep, it's also unusually _long_.

@Eric: it was a joke playing off a famous quote about software development that "the first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." I actually rather like Haskell, but that doesn't mean that I won't point out the problems that I see. How do you think improvements happen?

Seriously. Dons is on point here. Underdocumented and too-clever libraries are a big issue here, as well as occasional bugs. I don't think it's hard to Haskell, but its rough to do it on your own still, without the lovely support network that #haskell, -cafe, etc. provide.

@Kevin: TagSoup contains a mini-validator within it that checks for basic well formedness, and you can layer a full validator against some DTD on top of that. It would be an interesting and useful exercise, and shouldn't be too much work. See the example tagsoup tool, validate option.

(2008-02-13 02:36)

Reid wrote:

Hey guys, it's #haskell come to defend their beloved language! But seriously, I'm a major fan of the language too. Unfortunately, I agree there's a pretty steep learning curve.

(2008-02-13 08:02)

mrd wrote:

I actually use HXT + Network.HTTP all the time and have no problems with parsing XML generated by web sites. I do remember when you had that bug though. Weird stuff!

The HXT API is, I suppose, under-documented, but I figured out much of it just by looking at the types. I used it to learn the Arrow syntax and functions.

@mrd: The Network.HTTP bug apparently only bites on Mac OS. As for the other issues, parsing was no problem; it was validating where I ran into problem, and while most docs had no problems, certain documents caused an exponential blowup. Uwe fixed this in darcs back then, and it might be in the lastest release by now.