Steve Yegge posts an article about this that, the other thing, and statically typed functional programming languages. In it, he compares Haskell to something you can:

"build beautiful, lithe marionettes with"

Unfortunately, I haven’t had the time or inclination to learn Haskell (yet), but I have used Erlang professionally, so I do have a bit of experience using a functional programming language. What comes to my mind isn’t marionettes, but clockwork. That’s a purposefully neutral word, in case you were wondering. An enthusiast might say “a finely crafted swiss watch”, and a detractor might grumble “a windup toy”. In my mind’s eye, the concept is that in functional languages you get this succession of things happening one after the other that happen precisely the same way, if the program is wound up just the same each time. To paraphrase:

Do this with the result of this with what this produces when given  
this input that is derived from this function which takes the  
result of this other thing after calculating the result of 
something that is derived from the output of a function that ...

And so on and so forth…tick, tock, tick, tock.

While I can appreciate that in some ways, this is likely to produce clean programming, in other ways I am less convinced of its practicality. If you’ll bear with a poor comparison, sometimes programming is like a song. You do the tricky section, then you go back to an easier section and catch your breath for a bit. That seems to work out in a language like Ruby or Java fairly well, depending on how densely you like your code. You get sections with DoThisAndThisAndThatWithTheResultsOfSelectThisFromTableXYZ that you have to slow down to think through. And then:

• You assign the result to a variable.

• Which gives you a few lines to

  • slow down
  • consider where the program is

• And then

GoToTheNextTrickyBit where ManyThingsHappen.

All in all, you wind up with a sort of ebb and flow that works out pretty well if you’re in tune with the code being written, going from intense calculations, to a line or two where you do no more than store things in a variable, take a breather, and prepare for the next important stanza.

In my limited experience, I have to say that I didn’t always get that sensation from Erlang (which in some ways is apparently less “hair shirt” oriented than Haskell). You always had to be writing something with an eye to where it was coming from, and where it was going.

Without a doubt, this produces code that is more compact in terms of meaning and functionality, but at times it leaves a guy like me, who grew up with Basic, C, Python, and so on with the desire to say “woah there, nelly”, let’s take a breather and sort things out a bit in a few variables before moving on to the next bit of fancy code gymnastics.

What I’m curious about is what will catch on from academically oriented programming languages like Haskell. The people working on them are without doubt very smart, and there are some interesting concepts being bandied about (pattern matching is pretty cool, just to cite one). But academia doesn’t always produce things that catch on with the average Joe programmer, either, and while the more elitist out there may attribute this to simplistic reasoning such as ‘well then Joe is just stupid’, I think that the more thoughtful language crafters will attempt to ascertain what works, and what doesn’t, and perhaps we will see the Ruby of functional languages emerge from Haskell, the Smalltalk of functional languages.

What do you think?