After being introduced to it in half a dozen different classes over my academic careen, I have a new-found respect for functional programming :)

Of course, it wasn’t always that way. I still remember my first introduction to the Lisp family, taught by a professor who held a “list up and get it through your heads *cough*simpletons*cough*: Lisp is awesome!” attitude without doing much in the way of showing why it was so great. (At least, that’s the way I remember it ;) And there was the obligatory introduction to λambda calculus in the intro to programming languages course, but such abstract machinations are not usually parsed in a single pass.

It wasn’t until I took a graduate class in programming languages, taught by another excellent instructor, that I really got a feel for what was going on. With the background from my undergraduate intro class, I was able to keep up with the discussion of all the various topics: denotational semantics, typing rules, state transformations, encoding objects in the lambda claculus, existential types, etc, etc. Neat stuff!

Still, when push comes to shove, I am an object-oriented person at heart :) In fact, for the final project in that class I chose to examine John Hughes’ famous Why Functional Programming Matters paper from an object-oriented perspective. Although I did show that modeling average functional programs in an OO language is not that difficult in my half of the project, my main complaint with Hughes’ paper is that it ignores what I consider to be some of the main strengths of functional programming. Namely, data immutability and garbage collection (yes, yes: macros and code-as-data are all well and good, but I’m talking about bread-and-butter features here). Then again, at a time when FORTRAN was considered the latest and greatest, I suppose I can’t be too hard on the guy ;)

More recently, I had the opportunity to take a class where functional programming was the goal and not just an incidental aspect. There, through a variety of programming exercises, we got to learn Haskell and Scheme, and I finally found out why everyone is so enthralled with the latter :) Getting a hands-on feel for how functional programming works in practice has done more to reinforce my interest in the style than any amount of theory could have.

Haskell really is a very clean, elegant language. Indeed, while working with it, I was inspired to incorporate many of the common list processing idioms like map into my own procedural work (which I may post some day). Function composition is a very convenient technique. I do wish the GHC authors had spent more time polishing their type inferencing error messages, but I guess everyone can’t be as user friendly as C# :) Seriously!

Scheme is also much nicer than I remembered. Readable function names, excellent macro facilities. Where Lisp presented a stained and dirty window into the world of functional programming, Scheme opens the shutters and gives a fresh look on those lackadaisical lambdas.

And when I say “Lisp”, I am referring to the only dialect that I have had the misfortune to work with: Gnu Common Lisp. I could rant on about all the little nits and annoyances I endured while working with it, but I’ve tried writing it down before and it just hasn’t met my standard of entertainment ;) Suffice it to say that my resentment stems largely from an instructor in another class who was a real lisp hack. After all, who needs structure when you can simply create list upon nested list of arbitrarily organized information; and woe be unto you should a misplaced cdadr or unnecessary cons wreck such pristine code! (See, over-reactive silliness: it’s inescapable ;)

In summary: Scheme, decent; Lisp, despicable; Haskell, awesome ;)