Why functional programming doesn't catch on
Although a lot of functional programming tutorials are very mathematical like the author says, not all of them are. Real World Haskell (http://book.realworldhaskell.org/read/) is a great book on Haskell that shows how to actually solve real world problems using functional programming. Maybe with enough references like this FP will catch on? Or maybe lack of good documentation isn't what's holding it back?
I think the best way to prove functional programming (or your favorite programming paradigm/practice/methodology/language) is as much an advance as you say it is is to implement something worth paying money for in it.
I have a deep, abiding affection for Ruby, for example. A few years ago it would have been a tough sell. Then along came Rails and people constructively demonstrated "Hey, this language is not quite C or Java-esque, but there are persuasive reasons to use it. Why, metaprogramming techniques let you build a web application framework which allows impressive tech demos in 15 minutes. And look, if you go a bit beyond the 15 minute demo, you can actually build applications that people will pay money for -- faster and easier than you could before."
The absence of something like a "Java Pet Store" for FP was what drove the topic for my MSc dissertation that I finished last year: I basically implemented a simple set of requirements for a publishing-workflow system in both Java and Haskell and then set out to evaluate the differences that the two approaches had from a software engineering perspective [http://www.lars-oppermann.com/dis/dis-lopperma-final.pdf].
The Haskell version turned out to be much more compact and some parts of the business logic could be expressed in a really straightforward way. The Haskell version also had a meta-programming based mechanism for automatically deriving and parsing XML representations of the domain objects. The persistence layer could also be made very unobtrusive due to Haskell's type-classes.
Nevertheless, the absence of extensible data types and the clunkiness of Haskell's record system made the domain model rather unwieldy. This is not a necessary limitation of FP. It rather seems that most users of FP today don't need such facilities because they are not normally building systems that require these kind of models.
It's also very important to note that object oriented programming and FP are not conflicting. Mainstream OOP languages tend to embrace an imperative execution model (Turing Machines) and FP languages are modeled around Lambda Calculus. Projects like Scala show how FP and OOP can augment each other nicely.
I've tried to learn FP a few times, but I never understood the advantages. Most recently, I opened up Armstrong's Erlang book.
The power of Erlang seems to be due to the fact that processes and crashes are part of the language, and the language makes it fast and simple to create processes and handle crashes. This (esp the process part) can be implemented in a non-functional language.
It wasn't obvious to me why the functional nature of Erlang gave it any power.
It seems to me that things like the Erlang book example where they provide reliability to any arbitrary app can be implemented in C++ using a base class + virtual methods.
I would appreciate any "killer articles" which will make me "get it".
I like this quote from the comments:
"I don't have a clue how one would be able to build a gui with it, or how one can easily interact with a database."
Because SQL is functional programming. Functional programming doesn't just mean Haskell, it also means Microsoft Excel (which, I've been told, is the most used programming platform in existence).
the simple answer is that functional programming makes the easy things trivial, but for the hard things FP makes it obvious that you need to do something clever that involves a capacity for abstraction in design that few people have. There is no way to sweep the complexity under the fuzzy rug, you need to knit it a tea cozy that's the right shape and mechanical properties
"Pure" FP languages eliminate state. All programs contain an (implicit or explicit) model of the domain they are computing on. Many aspects of the world (domains) that we need to model are stateful. Our programs, in modeling those domains, often must be stateful. This is why it's hard for programs to be entirely functional.
On the other hand, state dramatically complicates reasoning about code, since outputs are no longer purely a function of inputs. Moreover, even with lexical scoping, it's not immediately clear what the state variables are a function of. As the scope of state variables increases, it becomes ever harder to determine what a state variable is a function of. This is why programs should be as functional as possible.
Solution: a language like Clojure or Common Lisp, which naturally encourages a functional approach while allowing side effects when neeeded. Clojure has some advantages over CL in this regard, since it has several clever mechanisms such as agents and software transactional memory to control side effects.
Microsoft doesn't matter much anymore, but F# will be integrated to Visual Studio 2010, bringing a very powerful functional language to all .net/mono coders. And I'm sure there are quite a lot of them. So the argument of lack of decent library or nice IDE will fall apart (and I heard it quite a lot) : we'll see how well F# fare on the .net scene.
I'm quite enthusiastic about it, since F# is actually a very nice functional language, with strong infered typing. It's basically OCaml running on .net/mono. I've rewritten C# code in F#, and the latter is definitely much more concise than the former... Strong typing is actually quite nice too. For instance a small neat effect : it prevents any kind of null pointer exception, null being a type in itself. Though sometimes strong-typing gets in the way and I wish it had duck-typing...
That said Microsoft doesn't seem to advocate the use of F# for GUI... They still recommend using C#, or the ugly thing that has Basic in its name for doing so.
Every functional language I have tried has given me a compelling reason not to use it. In most cases, it was a stupid reason that had nothing to do with it being functional. Some of them force you to sort your functions by call dependence (caller must be after callee). Most of them are woefully lacking in library and toolchain support - no bindings for essential APIs, no graphical debugger, no code completion. In the end, it proved easier to add functional features to languages which already had these things and had proved themselves free of fatal flaws, than to fix the flaws and add support to the functional languages people were promoting.
Yeah, no two ways about, for average kinds of tasks, most commercial programmers just can't get it.
I did some (I thought) quite neat Clojure code to merge some data ranges in about 27 lines (versus a house programmer's effort of 1000 lines of c#). My solution was not received well, even though it could have fairly easily been translated into c#.
Sadly, if you get FP and the cool things it can do, it gets really painful to be somewhere people don't get it.
It's caught on as far as I can tell. Nearly half my recent projects have been Haskell.
Sure, some people are still using Java, but who cares? There's no reason why you can't use Haskell, OCaml, or F#.
God save FP from the "mainstream". I know I sounds elitist but I honestly don't see how it would benefit FP to have lots of Java drones descending on it and taking it directionally into "simplifying database access" (for instance).
The reason I like FP is because it is "pure" and I enjoy the difference in the thought-model when programming. Plus I usually can get things done much faster. I think this is why most people enjoy FP in one way or the other. Why ruin that in the quest for popularity?
To all the fellow FP fans - why spend so much time trying to convince nay-sayers that FP is great, that it makes code shorter, simpler, safer, more robust, more fun? They will not get it anyway, until they try it. And sadly, they won't try it. Let's just use FP to our advantage and crush the competition!
Practical Common Lisp (http://www.gigamonkeys.com/book/) is a pretty good book, that covers these things. Accessible, practical material is definitely out there, but some kind of sea-change will have to occur before it goes "mainstream." I'm not sure it ever will, though, or if it even matters. As other commenters have noted, F# might be our Obi Wan here.
Ever heard of Erlang? =)
It's getting pretty hot right now.
because it's harder to maintain.