James Hague offers this assessment of functional programming:
My real position is this: 100% pure functional programming 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. You get all the advantages of functional programming, but without the extreme mental effort and unmaintainability that increases as you get closer and closer to perfectly pure.
That’s why Clojure is becoming so popular – it mix purity with non-purity in right proportions
Is Haskell the 100% Pure solution that doesn’t work? or does the IO monad count as -5% since it makes Haskell actually usable, bringing it to 95% pure?
Imperative programming in Haskell has some advantages not available in other impure languages, since IO actions are first class and you can define your own control structures. But I agree in general that other languages are often easier to just get stuff done, like C# if you need to build a large GUI-based application, or Python if I just need to parse some text. Or C, if you need performance and you’re not a Haskell wizard like Don Stewart.
I enjoy James Hague’s blog as well, although I sometimes wish he allowed comments.
You are very right. Every abstraction has a danger when you assume that an abstraction is absolute. You should understand whenever working with abstractions, that there is a layer of abstraction on which you are working. But if that layer of abstraction isn’t there, then our jobs will be a lot tougher. For instance, if there were no layer of abstractions, then we would still be coding in binary.
Nice Reminder
This totally reminds me of the Law of Diminishing Returns.
Where’s the evidence for this? There are examples of things where less than 100% imposes a fatal cost – you can’t do optimizations or make the assumptions you need to. Here’s one.
MS tried to get STM – much more reliable than thread locks – into .Net. They failed since their endproduct performed pretty badly even after all they could do http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with-software.html :
> “It’s the gift that keeps on giving… in terms of complexity. The overhead is terrible also. We’re looking at two-fold and four-fold increases in processing time even in the best case scenario.”
SPJ points out that the lack of purity in .Net languages means STM has crippling burdens in logging reads/writes that Haskell STM simply doesn’t have to do; http://thread.gmane.org/gmane.comp.lang.haskell.cafe/78755/focus=78833 concluding
> Each of these features was strongly motivated, and the MS guys in Redmond are extremely smart, but the result was necessarily complex and, as it turned out, unacceptably slow.
This is exactly the conclusion that I came to with Erlang.
It captures the transformational paradigm of functional, pattern matching, and a lack of side effects. However, instead of weighing that down with static code generation or typing madness, it wraps it in a very nice concurrency model with a solid VM runtime.
In the end, it’s generally fast enough, a joy to build networked or embedded systems in, and practical in a way that 100% functional languages just can’t do.
Clojure is similar.
@Jayson Vantuyl: static code generation or typing have literally nothing to do with purity though.
My experience has been that using 85% functional style ends up more like 95% by the time the project is done (at least, in languages that support a highly functional style.) The reason for this is that, since pure code is so much easier to reason about, the desire to extend that purity to more parts of the application is strong, particularly since it seems like the majority of the bugs end up cropping up in the less functional parts (particularly error handling around IO and inter-system communication.)
So, I’m kind of the opinion that more is better with respect to functional style. There’s an undeniable conceptual overhead that is imposed the closer that you get to 100%, but ultimately you only pay the conceptual cost once, whereas the errors that crop up as a result of impurity are a permanent tax.
Erik Meijer’s counterpoint:
“‘Mostly functional’ programming does not work.”
Ref:
http://queue.acm.org/detail.cfm?id=2611829
I’ve read Erik’s article a while back, but I didn’t get it.
My experience is more like “100% functional programming doesn’t work.” Or at least that the last 1% of purity doubles the effort required. But I could see how in some contexts there are benefits that you don’t get with mostly pure code.
I wholly disagree, Erik Meijer said it best in his paper “The Curse of the Excluded Middle” when he said that “‘Mostly functional’ programming does not work.”