Sarah Thompson (sarah@telergy.com) wrote:
I hate to have to say this for all kinds of reasons, but what the FP
world *really*
needs is for something called 'Microsoft Visual Haskell' to ship as standard with some new future version of Visual Studio, and be supported by a big, expensive marketing effort targeted specifically at corporate managers. Particular attention would have to be given to interoperability with other languages, so managers could be convinced that they had a way out.
... [various industry-attitude "horror stories" snipped out] ...
I appreciate Sarah's dose of reality here: I've seen plenty of the sort of thinking she describes during the (short, infrequent) periods I've crept out of my ivory tower and into the real world. Of course with the .NET support of Haskell and the F# effort at Microsoft, we may ultimately get what she describes (wasn't there even an internal MS Visual Haskell at some point?). But before we accept "what the FP world *really* needs", I think we ought to recognize the assumptions behind this claim, i.e., the statement should perhaps read: "IF we want Haskell (or FP more generally) to be widely accepted in the business world, THEN what the FP world *really* needs is ..." And, personally, I'm not sure I *want* to see FP be widely accepted in the business world. I suppose this is some sort of heresy, given the seemingly universal desire by all language adherents to see "their" languages grow to wider and wider acceptance, but I rather like the close-knit feel of the community as it is, and I cherish the set of design principles that community shares. Do we really want every snake-oil salesman around hawking Haskell seminars at $2K per weekend to stuffed auditoriums of business people, showing them how to write imperative code in a monad to do things that might be better done with map or filter? Could we accept an ISO standard that elevated unsafePerformIO and such-like to a new level of acceptability? I think it was John Launchbury who made a case at the Pittsburgh Haskell Workshop for letting Haskell stake out a certain extreme on the language design spectrum, one which supports formal reasoning through functional purity; I think this is a noble purpose the language serves. We even seem to be having some influence on the mainstream of language development: the recently-announced enhancements to Java read like a subversive attempt to inch that language toward FP style (and, hmmm, there is Martin Odersky's name on some of the Expert Group listings :) ); see http://java.sun.com/features/2003/05/bloch_qa.html. Of course, it would be nice to have more "warm bodies" to devote to projects like standard GUI libraries, browser plug-ins, IDEs, language inter- operability, etc. (no sleight intended to current efforts). But I think this is a question of getting more of the *right* people involved, rather than spreading the word to the business masses. Personally, I try to help in this effort by teaching my (liberal arts undergrad) students about FP and its sensibilities and then steering the best of them to compatible graduate schools. It may not be much, but I think quality is more important than quantity (besides, with recent FP class sizes of 6 and 9, I really can't contribute much quantity anyway! People like Manuel Chakravarty can probably afford to do both, see http://www.cse.unsw.edu.au/~chak/teaching.html). So, call me an elitist and bring the torches to my (ivory) tower door, but I have to question whether *broad* acceptance is what FP (or Haskell) really needs. -- Fritz Ruehr