The Functional Era

Language evolution is an interesting subject. At least to me. How languages experiment with concepts delivered as features and then find those features making their way into competitor languages because they worked (or ignored because they didn't). It's also interesting how so many of the great languages that we use everyday were designed by a single person or a small group - think about C, the original, pre-standards C++, C#, Basic, Java, and so on. It's also interesting what happens to great languages such as C++ once committees get ahold of them and tack on everyone's favorite wish list of features.

You could ask the question - should a programming language have a lifetime - a birth, middle age and then death, or at least obsolescence. Should C++ have stopped its trajectory of change before its syntax was garbled to the point of being an example of what not to do in language design? Should Java have added generics? Is C# complete enough now or do we need more LINQ style language additions?

One things these languages have in common is that they are within the imperative programming model landscape. That is, they are designed to allow the programmer to specify step-by-step how a task should be accomplished. They've served us well for decades now. However, there's a new kid on the block. The functional languages.

Actually, it's more of a kid who has been a kid for decades now.

For the vast majority of day-to-day programmers, we spend our days working in the imperative languages. Once in a while, we come across an odd article or two about functional, functionally oriented, or functional-object hybrid languages. Some of us may have even fiddled with academic functional languages during university days. But few use them everyday. They've seemed an oddity to programming-in-the-main.

However, with the launch of Microsoft's F# with Visual Studio 2010 next year, the world of functional languages will be upon us and I fear that many programmers will be in for as much of a culture shock as we had moving from DOS to Windows, or C/C++ to .NET. Possibly much more than may be in store.

Simply put, functional programming is unlike anything you do day-to-day in C#, Basic, Java, or any other similar language. A language that has been popular of late is Ruby through its use in the Ruby on Rails web development framework. Ruby has a functional syntax that is both very productive and very different than a C# or Java. The Microsoft entry into this world is F# and was created by Microsoft Research based upon the ML programming language. F# has been bubbling around the edges of .NET for awhile now, but next year it will be make its grand appearance along side C# and VB.NET as a premier language option for .NET developers.

Functional programming, to put it simply, is very, very different from imperative programming. You focus more on what you want to do rather than writing algorithms to make it happen. There are some basics though - in general, functional languages elevate functions (and methods) to first-class status alongside variables. They can be declared, defined, used, discarded and created dynamically. For an object-oriented developer used to imperative languages this can be the first hurdle - getting over the notion of data being the only thing that is dynamic.

There is much, more more to functional programming than what I've covered so far, but follow along with me this year and next as we take a longer look at F# and functional programming in general.

Posted by Mark M. Baker at 12:15 PM  Permalink