It's not about technology for its own sake. It's about being able to implement your ideas.
In school and early in my programming career I must have written linked-list handling code fifty times. Those were the days of Pascal and vanilla C. I didn't have the code memorized either, because there were too many variations: singly-linked list, singly-linked list with dummy head and tail nodes, doubly-linked list, doubly-linked list with dummy head and tail nodes. Insertion and deletion routines for each of those. I worked out the pointer manipulation logic each time I rewrote them. Good thing, too, because the AP Computer Science exam was chock full of linked-list questions.
Early functional languages like Hope and Miranda seemed like magic in comparison. Not only were lists built into those languages, but there was no manual fiddling with pointers or memory at all. Even more so, the entire concept of memory as the most precious of resources, one to be lovingly arranged and conserved, was absent. That's not to say that memory was free and infinite, but it was something fluid and changing. A temporary data structure was created and used transiently, with no permanent cost.
All of this magic is nothing new in currently popular programming languages. Fifteen years ago you could say:
print join ',', @Items
in Perl, taking an arbitrarily long list of arbitrarily long strings, and building an entirely new string consisting of the elements of @Items separated by commas. Once print is finished with that string, it disappears. At a low level this is a serious amount of work, all in the name of temporary convenience. I never would have dared something so cavalier in Turbo Pascal. And yet it opens the door to what's essentially a functional style: creating new values rather than modifying existing ones. You can view a Perl (or Python or Ruby or Lua or Rebol) program as a series of small functional programs connected by a lightweight imperative program.
But there's more to functional programming than a disassociation from the details of memory layout. What about higher order functions and absolute purity and monads and elaborate type systems and type inference? Bits of those already exist in decidedly non-functional languages. Higher Order Perl is a great book. Strings are immutable in Python. Various forms of lambda functions are available in different languages, as are list comprehensions.
Still, the purists proclaim, it's not enough. Python is not a replacement for Haskell. But does it matter? 90% of the impressive magic from early functional languages has been rolled into mainstream languages. That last 10%, well, it's not clear that anyone is really wanting it or that the benefits are actually there. Purity has some advantages, but it's so convenient and useful to directly modify a dictionary in Python. Fold and map are beautiful, but they work just as well in the guise of a foreach loop.
The answer to "When will Haskell finally go mainstream?" is "most of it already has."
permalink July 6, 2008
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?