3 ms·
I do think that FP IS a snake oil fad and unsuitable for 90% of all code, which is all about mutable state and IO: manipulating data bases and game worlds, writ
by copx 14y ago
I do think that FP IS a snake oil fad and unsuitable for 90% of all code, which is all about mutable state and IO: manipulating data bases and game worlds, writing and reading files, sending and receiving network packages, user interaction etc. all of which is awkward in FP.
Back then OOP was paraded around as the silver bullet of software engineering some people rightfully pointed out that many problems do not map cleanly to OO abstractions. People tried to force all code into that straightjacket anyway, most infamously Java, and thus we ended up with things like "Singleton"s and "AbstractFactoryFactory"s.
Yet OOP was a success, because most problems can be expressed in a decent to good way using that paradigm, and it forced some structure on bad programmers. In contrast, most problems can not be expressed in a straightforward way in FP and the advantage of forcing structure on bad programmers is mostly gone.
I think the current FP fad is actually an unfortunate side effect (pun intended) of the OOP craze. All these younger programmers who learned programming with Java, who had to write all that AbstractFactoryFactory "Enterprise Java" code, they see FP examples and think they have seen the light.
As the article almost admits, FP is basically a restricted subset of procedural programming. However, while these people were taught that "procedural programming" is an archaic evil and everything must be wrapped into classes by their Java schools, nobody told them that about FP (because the instructors probably did not even consider/know it). So now they can enjoy the simplicity and freedom of procedural code without the feeling of being "politically incorrect".
However, as I said, FP is simply unsuitable for most real world problems. The problematic thing about Haskell is not understanding monads, it's that they are necessary! They and other constructs like that are the "Singleton"s and "AbstractFactoryFactory"s of FP - what happens if you try to force something naturally "unfunctional" into a functional straightjacket.
The right solution is multi-paradigm programming. Use FP where it makes sense, don't use it where it doesn't.
- Drbble 14y agoRead "Tackling the Awkward Squad" paper by Peyton-Jones et al.
- EvilTerran 14y agoLink for the lazy: http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers... It's a good bit of writing, that.
- EvilTerran 14y ago"The problematic thing about Haskell is not understanding monads, it's that they are necessary! They [... are ...] what happens if you try to force something naturally "unfunctional" into a functional straightjacket." Er, I'm going to have to disagree with that as strongly as it is possible to do so. Monads are an incredibly powerful abstraction, to the point where they'd be useful even in a side-effect-ful language; for instance, for expressing non-determinism, or exceptions, or continuations, or any number of other features that would bloat your language spec if they were built-in. In Haskell's case, one of those features is IO, yes; but they're also used to provide many other features, including all the ones I just mentioned. And every feature implemented via monad is restricted to only the parts of the code where you need it - your exceptions aren't going to sneak out of the module they're meant to be in because of a forgotten catch; you can parallelise non-IO code with impunity, knowing there are no surprise side-effects; etc etc. I'd be inclined to compare monads, in terms of utility, to the abstract notion of objects, or to LISP-style macros. "Use FP where it makes sense, don't use it where it doesn't." Okay: http://augustss.blogspot.co.uk/2007/08/programming-in-c-ummm-haskell-heres.html http://augustss.blogspot.co.uk/2007/08/programming-in-c-ummm... There. Reasonably clean imperative code where you want it, with Haskell's enforced purity stopping your side-effects leaking into parts of your code where you don't want them. If you'd started from an inherently imperative base language, that wouldn't be possible. And all thanks to monads. [edit: a discussion of monads in the imperative context of C#: http://mikehadlow.blogspot.co.uk/2011/01/monads-in-c1-introduction.html http://mikehadlow.blogspot.co.uk/2011/01/monads-in-c1-introd... ]