I suspect FP will have more resistance to cargo-cult application. I suspect far fewer people who have a partial understanding of FP will be able to hold a job doing FP than was the case for OOP.
Heck, I know of one programmer who not only held an OOP programming job, but got to write a major subsystem -- with all long deeply nested class-side methods with 4 to 5 temp variables acting as merge-sort style incrementing indexes and not a single instance method or instance variable in sight. Last I heard, she was promoted and has great job security.
I'm not so sure. OOP entered the scene and became a dominant paradigm in a short amount of time - this doesn't happen without massive amounts of evangelization (from existing users) and marketing, neither of which can be particularly smug if they intend on being successful.
OOP was able to become dominant because it came with some clearly defined "killer apps", the likes of which I have yet to see materialize from the FP world. I mean, Smalltalk shows up in Byte and says "look, here is an entire system for graphically interacting with a computer, creating music, simulations, animations, drawing programs, documents, and more. It is so easy that school children can use it. We have managed to accomplish all of this in a few hundred thousand lines of our language called Smalltalk, which incidentally also contains the implementation of all the dev tools and the standard library. How large would this be in the language you are currently using (probably COBOL, Pascal, C or something similar)?"
I get that FP has some very good characteristics, and I have tried to add a bit more "functional-ity" to my code over the years, but at the same time I get an overwhelming urge to say "put up or shut up" every time I am confronted with an article talking about how terrible OO and the programmers who work in it are, and how those working in FP are in some sort of enlightened programming utopia.
Convince me by showing me some examples of programs so good that I can't possibly ignore them, the way OOP did. Convince me by becoming the foundation of almost every program I am currently running on my computer right now, the way OOP did.
Don't convince me by writing article after article showing how insanely elegant your implementation of a mathematical function (My head will literally explode if I see another Fibonacci example) is, and how brain damaged what I am currently using must be. Numerical code comprises probably 0.1% of any computer system I am currently using. Show me instead how easy you just made to it interact with my computer, to write the type of programs that I am currently using and, for bonus points, to write the types of programs that I didn't even think were possible.
Hmmm. The killer app, when it comes, will probably be for parallelism. Since FP languages are better able to control state, they can neatly sidestep many of the contention issues that plague imperative programming in multi-core scenarios. Problems that require heroic programming in imperative realms become much simpler in certain FP languages. And given that clock speed is settling down while core numbers are ramping up, I think this alone will make FP more compelling.
It's more about appropriateness, though, than anything else. I still think OOP is great for things like GUIs, modeling complex domains.
As always, the trick is to pick either the right language for your problem, or pick a multi-paradigm language, and choose the right approach for your problem.
The killer app, when it comes, will probably be for parallelism.
If that's the case, then FP's got a problem in the form of OOP having already done it first and famously with projects like Hadoop.
I think that too much hay is made of the tradition of minimizing mutable state in functional programming. It's not something that's exclusive to FP. And I'd even go a step further and suggest that excessive use of mutable state isn't a hallmark of imperative programming so much as a hallmark of bad imperative programming. Though I'm sure there's also plenty of room for argument there.
Regardless, the fact remains that when functional programming proselytizers suggest that imperative programmers need FP to escape from the bugaboos of excessive mutability, it comes across as somewhat naive. While many functional languages make mutability less convenient, this is not the same as making immutability more convenient. Which I mention by way of pointing out that really the only thing people working in imperative languages need to do to cut back on their use of mutable state is cut back on their use of mutable state.
Now, if the current fad for FP made more noise about something that distinguishes functional languages much more tangibly, it might be more impressive. Take higher-order programming, something most functional languages do very well and most imperative languages do poorly (if at all). Imagine doing something like node.js in a non-functional language.
Or this couple minutes from a lecture on F#, where the presenter converts sequential code to asynchronous parallel code in just a few keystrokes. Sure, managing state properly is an important precondition to being able to do that, but the real magic is in the async workflow (a type of monad). http://youtu.be/HQ887aOZITY?t=53m
Yes. That's precisely why I chose it as my example. One of the major themes in my post was statements to the effect of "you need functional programming languages to do X" often being mistaken, so that detail makes Hadoop a rather poignant case.
I agree. I think perhaps, a better point to make is that FP makes certain things easy, or the default, while doing it in am imperative language requires discipline, which I think is a mistake to rely on at the industry level.
It's a bit of a reductio ad absurdum, but remember: technically everything could be written in assembler. Languages and their idiomatic usage matter. Any C++ person could point out that, yeah, everything you can do in Java can be done in C++, but the fact that Java does automatic memory management still has value to many people.
Totally. And I also think a lot of imperative languages make that kind of discipline more of a hassle than it needs to be. (Giant peeve: .NET does not have any decent options for immutable collections in its standard libraries.)
But the author does bring up a good point: The industry is full of people who were taught using Scheme in university, but quickly switched to an imperative language when given the chance. Having TA'd classes that are taught in Scheme, and spent a lot of time tutoring people who fit into that class, and watching the way they go nuts when they're finally shown set! for the first time, I've come to the conclusion that it isn't merely a preference. Most of them really do have a genuinely easier time reasoning about and writing correct imperative code. It would also be a mistake to rely on a programming paradigm in which many people have a hard time functioning at the industry level.
If there's a middle ground that allows people to keep their FOR-loops while discouraging them from using mutability in the contexts where it's dangerous, that's the direction I think industry should be headed in.
Well, OOP had some help in the form of C++. It was easy to sneak in because it didn't strictly require people who were used to C to change their habits. Folks could, in effect, switch compilers first and then learn the language at their leisure. Of course, you could also make the argument (and I would) that C++ wasn't really an object-oriented language so much as a structured language with classes thrown in.
Most of the popular functional languages, on the other hand, require folks to do a whole lot of mental gearshifting before they can be productive in the new language. That's a natural impediment to adoption.
I suspect, though, that functional programming has finally found its C++, in the form of more recent versions of C#. Like with C++, it doesn't require users to immediately switch programming styles to be able to get the job done. Also like C++, though, you really can't use the language to its full capacity without getting very comfortable with a lot of functional programming concepts. Pretty much all of the neat new stuff in the .NET 4 class libraries, for example, is built around higher-order programming. Most of it will also be useless (or at least severely crippled) for someone who can't get past relying on mutable state.
I don't agree that "OOP entered the scene and became dominant in a short amount of time", though I guess it depends how you define "entered the scene" (Simula 67? Smalltalk 80? C++ in the mid 80s? Java in the mid 90s?) and "dominant" (presumably the rise of Java as a mainstream language in the late 90s?). Maybe if by OOP you just meant Java?
Note that in the early days of OOP (pre-Java, say the first few years of OOPSLA in the mid to late 80s) there was a lot of overlap between the FP and OOP communities, both because CLOS was one of the pioneers exploring some of far corners of OOP, and because aficionados of weird languages tend to flock together.
