FP is becoming the new OOP. People who don't understand its original meaning are misinterpreting it and incorrectly expounding its usefulness. Newcomers are not grasping how it fits into the bigger picture. Be cautious.
Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"?<p>Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro Lisp and Hadoop, so I haven't had the deep dive indoctrination others appear to have had.<p>But as each new computing metaphor comes, we find ways to make it easy for folks trained in older metaphors to come over. Other than Scala, I've found few bridges that are trying to help procedural and OO lang folks adopt functional. It's no-one's fault, I guess, other than new folks are trained in it, and older folks aren't.<p>But I'll keep looking for that bridge, that shining one thing that will make me go "aahhha, I see" and not "one of these books will explain how passing this function through this multi-nested other function is better than just making a loop".<p>Because after all these articles, I know functional is great. I just feel bad that I haven't been able to make it great for me... yet.
The thing that got me really interested in learning Haskell was the realization that something like 90% of the nasty bugs that I fixed in production over the years would be have been impossible in a pure functional language.<p>The thing that slows me down is the prospect of actually getting paid to write Haskell, and my doubts about it's ultimate suitability for iterate-quickly, fail-fast software world.<p>But reading this article reinvigorates me. Pure functional programming may be much harder, but its rigor allows for more powerful abstractions. Grokking those abstractions is no doubt useful regardless of what language you're using.
It is worth noting that there are a few other paradigms that can change the way you think of programming - recently there was a post providing a good overview of languages that will make you learn some new abstractions, functional programming being one of them: <a href="http://blog.fogus.me/2011/08/14/perlis-languages/" rel="nofollow">http://blog.fogus.me/2011/08/14/perlis-languages/</a>
I have done a few real, production projects with Haskell, and I've come to realize that a lot of interest in it is hype. The paradigm is neat, the language is relatively well designed (considering that it's an academic committee language) and the implementation is passable.<p>Programmers sadly forget that the greatest challenge of software creation very often happens outside of your text editor: it happens in the domain, in architecture, specification and communication. If you succeed in those, your project will succeed, no matter which language* you chose. If you fail in them, no amount of strictness in your programming language will save you.<p>* <i>unless of course it's Java</i>
I see that some people are saying that functional programming is more powerful than OOP. I disagree with that.<p>I do not think one is less than the other. Actually there is a mathematical argument why one is not less than the other. To me functional programming is "what does what I'm trying to describe do?". In object oriented programming it's "what are the properties of the thing I'm trying to describe?". In functional programming I describe the interactions directly and in OOP the interactions come about from how I have described the objects. Done properly, they are both about interactions, it is just a difference of what you focus on.<p>It has been shown that classes of OOP can be modelled for the most part as co-algebras. This means that objects are a mathematical dual to algebraic types of functional programming. The reason why functional programming is important is that some things are easier to express in a dual space. This means that many things that are hard in OOP are trivial in functional languages. But the reverse is also true. This is why it is important to not drop one for the other.<p>The real advantage IMO in functional programming is that these languages tend to be developed with stronger mathematical foundations. Hence programming in them tends to encourage people to be principled and rigorous (at least in theory). It is very likely that if you study the subject you will naturally come to be interested in why monads are only one particular type of functor, that polymorphic functions are well described as natural transformations or try to wrap your head around mechanically generating dynamic algorithms in terms of hylomorphisms. The more mathematical nature also makes it less magical and rickety to the self taught programmer (such as myself). That I think is the real advantage. But there is nothing inherent in OOP that stops it from also being built from more rigorous foundations. Such things will come to matter more with increasing concerns in security.<p>I think functional programmers sleep on the power of coalgebras. In fact his example of google map reduce is completely ignorant of the fact that the real hero in MapReduce tm is unfold not reduce.<p>I have a pet theory that the fact that algorithms are written in dual styles is why experienced OOP people find functional programming so hard. They literally have to reverse their style of thinking. This takes a lot of energy. Just because it takes place in your head doesn't make it any less physical than trying to roll a boulder uphill or get a wagon wheel out of a rut.<p><a href="http://www.cs.ru.nl/E.Poll/papers/durham97.pdf" rel="nofollow">http://www.cs.ru.nl/E.Poll/papers/durham97.pdf</a>
And here I was expecting the surprise moral to be, "Functional code looks better than average, just because only smarter-than-average programmers can manage to work in FP languages."
<i>Functional Programming Is Hard,
That's Why It's Good</i><p>This is a major issue in software development. Developers like a challenge so they are often drawn to complexity. Unfortunately, this interest in complexity often carries over into their work.
I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too."<p>I'd really love to see the code for something that one would do in a day or two in Lisp, but would be much longer in another language. I don't suspect there exists a wide class of such things -- I suspect the features tend to look like embedding Lisp compilers.
"Pointers are a very powerful and fundamental abstraction"<p>An abstraction of what? Can't get much closer to the metal than with pointers. Frankly I'm not sure someone writing this have much insight worth wasting time on.
I love Erlang so much I haven't yet gotten around to learning another functional language. (still growing with erlang).<p>I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!
This is the lie that every functional programmer has perpetuated for the last 50 years since the dawn of Lisp - that somehow, automagically, productivity or effectiveness of programmers increase with the use of functional languages.<p>It's the biggest lie in the programming world, and it was designed to make the uber-geeks of this world, those people that you walk around the block just to avoid saying hello to because you know they are deeply and profoundly anti-social, feel good about themselves, to feel special, as though they have the "upper hand" that other normal people who deliberately choose other languages over purely functional ones.<p>There is value in learning how to think recursively, but a lot of programming, especially systems programming doesn't need to have its for loops transformed into recursive functions, or its addition operators into primitive recursive functions.<p>I am sick and tired of people expounding on the alleged efficacy and efficiency of functional languages and I wish they would just STFU once and for all and go back to their porn intermezzos between their functional programming spurts.