Not having to choose between a big ecosystem and cutting edge features
Joel Spolsky has an interesting post on the Language Wars -- the permanent debate among those who think their currently preferred programming language is the best. He drew some heat from the blogosphere because he advocates a pragmatic approch for others ...
**
Lisp and OCaml and lots of other languages ...are totally, truly brilliant programming languages worthy of great praise, but just don't have the gigantic ecosystem you need around them if you want to develop web software...The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there's so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they're not life-threatening problems.
...but he has taken a dramatically different approach in his own company:
FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.
Some consider this either stupid, hypocritical, or a bad joke, but it got me thinking: What if you didn't have to choose betweeen a cutting edge language that supports functional programming constructs and Rails-like database driven web development on one hand and a big ecosystem on the other? That's one big part of the overall C# 3, VB9, and LINQ value proposition in a nutshell. None of the features inspired by functional-ly stuff such as lambdas and monad comprehensions force you to do things differently or break your existing code, but they do offer a migration path toward a less imperative, more modern programming style for those who want to go there.
Furthermore, the LINQ approach can let you have it both ways -- unlike Ruby on Rails (in the words of its creator) you probably won't have to choose between developer cycles and machine cycles -- you can get both the productivity benefits of working with declarative queries for all sorts of data, along with type inference of the sort that makes script languages easier to work with, but also get the performance optimizations that a long history and large ecosystem have forced into being. Furthermore, you gain the ability to architect applications to take advantage of "laziness", which has been a hallmark of the functional programming languages but now comes into the mainstream. For example, we are now prototyping various LINQ to XML classes/methods that should make it both easy and efficient to work with large XML documents or arbitrarily large streams. No more having to choose between the convenience of an infoset API such as XLinq or DOM and the speed of XmlReader or SAX ... well, for typical use cases anyway.
That's not to say that the LINQ technologies will magically give you the best of all possible worlds; there's a learning curve required to take advantage of these cutting edge approaches, and those who have already climbed it with Scheme or Haskell will probably not like the numerous "impurities" that legacy compatibility and real-world viability require. Nevertheless, people (well, like me) who have been baffled by Haskell and challenged by XSLT (a more or less functional approach to XML programming) are likely to enjoy not having to make so many hard choices.