Saturday, April 18, 2009

[Haskell] still very difficult to write robust programs


Our informal poll shows Haskell to be the most "popular" FPL, but is Haskell suitable for serious work?

Adrian H., a prominent member of the FPL community and an experienced Haskell programmer, shared this in comp.lang.functional newsgroup:






IMO by far the biggest problem with Haskell is that, for all it's sophistication, it's still very difficult to use it to write *robust* programs (as opposed to programs that are merely "correct" in an academic sense). But often you can live with this, if all you're using it for is to knock up quick and dirty "run once" programs to get whatever answer you're looking for. As long as the program terminates eventually (as it usually does), who cares about all those space leaks or the sucky performance?

I suspect that most Haskell users use the language this way (as I kind of super calculator or for private "in house" stuff). I do anyway. As you have observed before, what might be regarded as "serious" publicly available applications written in Haskell seem to be pretty rare :-( (ghc,pugs,darcs,xmonad are about all I can think of off the top of my head).
The second biggest problem with Haskell is..something I dare not mention again (it's tabboo in the Haskell community).
The second biggest problem was explained later:
the embarrassing fact that the worlds finest imperative programming language could never be used to implement most of its own standard or non-standard IO infrastructure
[due the inability to safely use unsafeFoo required for this task (see link) and the flaws in its otherwise neat type system]

Thank you, Adrian, for your candor. Characterizing Haskell as a sophisticated academic calculator and an experiment, whose main value is in teaching us how not to design languages, certainly wouldn't sell many books.

Earlier, I proposed that the FPL community should explore other, more practical, approaches to language design, specifically, for the eagerness/laziness issue I advocate the kind of approach Clojure uses. The functional programming community needs to get out of its rut and move on.

4 comments:

  1. On another note, why was Erlang not in that poll??

    ReplyDelete
  2. @ Thomas

    Slipped my mind, along with a few other languages. Adding them now would bias the poll against them (they start at 0).

    ReplyDelete
  3. There's some really interesting stuff going on in the software transactional memory (STM) space dealing with concurrency. The researchers specifically mention they are using Haskell to prove the concepts:

    http://channel9.msdn.com/shows/Going+Deep/Programming-in-the-Age-of-Concurrency-Software-Transactional-Memory/

    ReplyDelete
  4. Adding up all the LISP variants makes total more than Haskell and if Clean is to be considered as well for Haskell, both families have more or less equal weightage, going by atleast this poll

    Theoretically (and incidentally, historically), LISP is the lingua franca of functional languages by virtue of its s-expr syntax which maps well to the functional program's flow. Macros were an interesting and great side effect for better abstractions

    ReplyDelete