length

In an earlier post, http://chaource.livejournal.com/34530.html , I deplored the current state of functional programming. I said that functional programming is difficult because the programmer needs to develop an adequate mental model of the language in terms of how the compiled code will actually look and run.People pounced on me and (amid variously directed critique) pointed me to Haskell rather than Ocaml. I spent a few weeks reading various Haskell tutorials, especially about the infamous "monadic programming." I'd like to say that I am impressed. It appears that Haskell is a very interesting language indeed; more so than other "young" FP languages (Ocaml or Erlang; perhaps Clean comes close). Haskell is a language more interesting for a mathematically minded person, for a person not interested in fashionable topics, and for a person concerned a lot with conceptual clarity. If I had any time today for programming I would try to learn more about Haskell.Here is a blog entry about a Haskell program for Fibonacci numbers that was automatically parallelized with just a bit of human help. I was not very much surprised that parallelization worked "out of the box" because the program is purely functional and rather simple. What was more surprising to me: the single-CPU implementation was already essentially as fast as a pure C implementation. Fantastic, isn't it?In another article the same author (Don Stewart) explains how to optimize Haskell code. This article is about exactly the kinds of "insider tricks" I felt one absolutely needs to learn before being productive with functional languages.A trivial three-line Haskell program was written for computing the average of the list of numbers from 1 to 1 billion. This program crashes (apparently trying to allocate too much memory). Don then writes,In other words, a programmer who is presumably competent but comes from the imperative (not functional) Fortran-C-C++-Java-Python lineage is unable to write a working 3-line program in Haskell. The reason for this is that the programmer is insufficiently aware of the "interaction between strictness and laziness."To understand this interaction in all detail, one needs to take a look at the intermediate code produced by the Haskell compiler. Then (one month later, when one has finished learning the compiler innards and is able to read "core Haskell") one notices that the list of one billion items is prematurely forced into evaluation rather than kept unevaluated. Then one rewrites the code using straight recursion; perhaps instead one is supposed to use some fancy combinators or what not. (Yes indeed! The next article by the same author does just this.) I am insufficiently competent in Haskell (having written exactly 5 lines of code in that language) to understand quickly whether it's enough to keep away from thefunction, or there are more hidden traps.Of course, once we identify the problem we can work around it. The fact that we identify the problem by seeing the program crash is a really bad sign though.Haskell is a fine puzzle for mathematically inclined persons having lots of free time. I'd like to know whether Haskell is actually ready to be used. I have three programming projects on my mind; should I invest the time necessary to learn Haskell if I want to work on them?1. A GUI application that allows the user to construct from scratch and subsequently to modify its own graphical user interface interactively, using a set of GUI primitives and allowing limited access to its source code, but such that the user does not need to write any complicated source code and so cannot make a mistake.Which GUI toolkit can I use with Haskell? While there is a choice between Tk, Gtk, and wxWidgets, none of these Haskell bindings seem to be "standard" or complete or stable, and every one appears to be the result of a research project to invent a conceptually new, purely functional replacement of the traditional object-oriented, imperative GUI toolkits. I am unwilling to invest time into studyingin order to use a toolkit that eventually will not work because of missing library header file that was present five years ago when the toolkit was being developed. Maybe I'm being too pessimistic; but most today's languages come standard with a full set of GUI toolkits.I downloaded the Haskell bindings for wxWidgets but was unable to compile them because of some strange error message: "wxHaskellCore not found." They said the latest CVS version works only with the latest GHC (compiler); that's what I used. Anyway, I have no time to figure this out now.2. I'd like to find a Unix-like command shell that uses (more or less) Haskell as scripting language but provides easy interface to the file system, data streams, and the network. In this shell I'd like to implement some interesting bookkeeping operations, such as synchronize files over network using approximate filename matching. The usual Unix shell is too primitive for a large programming task.There are 3 or 4 more or less abandoned "Haskell shell" projects. Only one of them appears to be in any kind of finished state but not actively developed any more.3. I'd like to write a program for algorithmic music composition. The book by Hudak ("The Haskell school of expression") appears to be the only one touching on some sort of multimedia or music interfaces.Again, projects to have a Haskell interface in this area are, that is, they develop a new programming paradigm to represent, say, real-time signals ("functional reactive programming" for instance) and they are still figuring out whether this paradigm is useful.Also, it is unclear whether I will be tied to platform-specific (read: Windows-only) tools in this area.So for these reasons I'm a little hesitant to think that Haskell is the Next Great Thing (TM) and also hesitant to devote any of my free time to learning it in more detail.I'm still of the opinion that "hardcore" functional programming (which Haskell is a champion of) is just conceptually too difficult for a casual programmer. Surely it's okay to put an occasional "lambda" into your imperative Python code just to make the code occasionally shorter and more flexible. Most people will have no trouble doing that, but they will find it a hell of a time figuring out why their Haskell application does not work.Will I be able to figure out these things by myself? Maybe, at a rate of one trick per week if I work constantly on it. Let's wait until more books on Haskell come out.