It's pretty difficult to have an intelligent conversation about programming languages. Thus it's likewise difficult to advance the state of our art.<p>You try talking to most FPers about this stuff, and they get angry because you're telling them that Haskell is not the most optimal language for building a GUI. Go look at XMonad, they say. I'm sorry, but one damn example doesn't quite cut it.<p>You try talking to mainstream folks, and they always default back to the "where are the big, successful functional programs?" For christ's sake, when did the size of your codebase become something to be proud about? Did you become a goddamn excel-spreadsheet manager or something? The fact that all current systems are done in OO/imperative is not a good thing because quite frankly, most code SUCKS. And you know it.<p>For myself, personally, I've found the purity and laziness of Haskell too useful to dispense with. It's just <i>that</i> much better than other languages like OCaml because of the lazy bit. So what do I advocate? Leave the UI code to the imperative/OO languages, and do the backend in Haskell. This wins no fans in either camp.<p>But the pure FP camp is the one that has something to prove, so we're the ones at a loss here.<p>I think we should try to build <i>part</i> of a good, stable system in something our language is good at. In the real world, 80% is usually good enough, so lets get the 80% we're really darn good at (yes, I think <i>pure</i> FP is good at 80% of any task in any stack). Things that exploit parallelism and/or correctness seem ripe for the picking. Things like databases, or any sort of data processing.<p>Look at what the Erlang guys are doing with CouchDB. Even a full blown web backend seems like fair game. The problems I've had doing one have not been technical or related to Haskell. They're psychological (i.e. student syndrome). Someone with more experience than me ought to just go and do a better job.
An interesting read, but I found this a bit bizarre:<p><i>No one seems to place a purity test on stateful programming: "Try writing that without any functions!".</i><p>It seems like the author is somehow placing imperative and functional languages on opposite ends of the spectrum, but in reality imperative programming is just a direct model of programming physical machines and functional programming is a constraint layered on top of that to impose a much more reasonable order.<p>State is an unavoidable consequence of machines operating in time and space. Functional programming just lets you pretend the physical computation doesn't exist to various degrees, but under the hood it's all imperative.
After linking to James Hague's article "Functional Programming Doesn't Work", Wallingford argues that a practical compromise is to write programs that contain about 90% pure and 10% stateful code. Interestingly, Hague came to the same conclusion in a followup to his own article:<p><i>"My real position is this: 100% pure functional programing doesn't work. Even 98% pure functional programming doesn't work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches--say to 85%--then it really does work."</i> <a href="http://prog21.dadgum.com/55.html" rel="nofollow">http://prog21.dadgum.com/55.html</a>