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 speed of Rails development is more about Rails than Ruby. There's nothing about Rails that couldn't be duplicated in Python, or even Perl.
So I'd refine your statement: the best way to make functional programming popular is to develop a popular package that happens to use functional programming. The tail doesn't wag the dog.
I sell a desktop application that is written in Java. My web site is written in Rails (with the obligatory Javascript bits).
The distinction between the two is blurring these days. The core feature of my website is a backend where my freelancers enter new content, which is then operated on by my program, and turned into a page on my website advertising "Here's a taste of content you find compelling. You could make something like this if you only pushed yonder download button". This was originally intended to be mostly for marketing and SEO.
Then I got a bright idea: wait, I pay people to add to that content every month. What if I could update the application with it automatically? My users don't care about the distinction between code and data one iota: from their perspective, adding more content to the program improves what it can do. So I offer access to the new content as one of the benefits of purchasing the application -- free at the margin for me, high perceived benefit to the customers. Its like having a program that gets an automatically generated .1 upgrade every month.
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".
The idea behind FP is to minimize or eliminate implicit state change.
This has several advantages. The first is that it eliminates errors caused by unexpected state change. This is a larger class of errors than you might expect.
The second advantage is that FP applications are easier to unit test. When given a certain argument, FP functions always return the same value, so if f(1) is 2 in your tests, you can be guarenteed it'll be 2 in your application, too. FP generally more predictable.
The final advantage I can think of is concurrency. Concurrency in imperative languages is made harder because a data structure referenced by one thread can be mutated by another. In FP, data structures are immutable, so this problem doesn't occur.
In my experience, the advantage of functional programming is that it is very easy to understand and debug. If my program consists of series of small functions that each have no side effects, things become very straight forward. I won't have one function mysteriously causing problems in another part of the program because it modifies global state in some unexpected way.
Combined with decent unit testing to ensure that each small function works as expected, it becomes exceedingly unlikely that changes will introduce difficult to debug issues.
One of the best books that first showed me how you can use a lot of the features of functional languages (first class functions, lambdas, etc) to build better functional programs was Norvig's PAIP.
Have you checked/asked on Stack Overflow? It tends to be good on this kind of question.
Basically, I think functional programming is a particularly good match for some problems (e.g. tree transformation) and for proving theorems. So, like every technique, it's good to have in your toolbox if it's not too expensive for you to acquire. Apart from that, it's a matter of taste/religion.
For issues like global variables, it's considered good practice to avoid them in imperative languages too. For example, Java/C++ have private/public/protected access modifiers to help you manage this.
I too read Armstrong's book, and concluded same: Erlang's concurrency power is due to pure-message passing, not due to it being functional. The processes could be written imperatively, and provided the communication was pure-message passing (and you tuned the implementation as the Erlang team did), you'd get the same benefits.
BTW: I like to think of Guy Steele, who co-invented Scheme (used in SICP), and also co-wrote the Java Language Specification.
Using FP is like learning to ride a bike. It's difficult to give you "advantages" over riding a car (or bus) - you have to try it out and get comfortable to appreciate it.
Just give it a try - write out a few of your (semi-serious) projects in an FP language. Start with Scheme. You may enjoy it!
Functional Programming is just beautiful. You can't write beautiful code in C++. Functional Programming, however, is like maths, where you can create and exploit nice structures. It's just beautiful code.
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
something clever that involves a capacity for abstraction in design that few people have
Anyone smart enough to use C++ professionally is smart enough to use any language.
Remember that people once built enormously complex systems in assembly language. Academics have always vastly underestimated the intelligence of commercial programmers.
"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).
I disagree. SQL, by definition, is natively nonfunctional. The concept of a database requires state. However, you can write functional-esque (monadic) layers on top of SQL.
Excel is basically a wrapper around spaghetti code. It's great for small presentations, but using it for real programming is incredibly risky. There are an enormous number of stories floating out there about business apps written in Excel that turned out to have subtle but sometimes disastrous bugs due to random human errors as well as poor maintenance when the "program" changed hands.
If you don't use UPDATE or DELETE, then you're treating SQL as a static-single-assignment language.
This is pretty much what I do at work; we have massive quantities of geographic and linguistic data that we have to translate to [REDACTED], and we do this by uploading it all into PostgreSQL and then running through a long sequence of "CREATE TABLE foo AS SELECT hairy_expression FROM bar;" statements.
I think I see your point, but is "natively nonfunctional" how you would describe lisp? There's not really any difference. One is binary relations and one is set relations.
"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.
Being largely stateless is the hardest thing for me to wrap my head around when I first started writing Lisp code but after a while it is liberating. I still think that data representation is what scares most people away. People are used to defining their data as objects and not many people program any other way today.
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.
Indeed. To be basically useful in a commercial setting a language must have rock-solid bindings to a) a major GUI toolkit on all its supported platforms and b) the big 3 databases. This is why I have high hopes for F# - an industrial-grade OCaml with full access to the vast .NET libraries and integration into one of the best IDEs around.
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.
Believe it or not, but java can be written functionally: you have to use an interface (and a few classes) to implement a list and you can use objects as functions... but it's not usually something people get into.
Not only will you fight against the language, but the functional style code you produce will be awkward and unreadable by other Java programmers. If this doesn't matter because you are working alone, then why would you choose Java in the first place?
Who needs libraries for non-destructive programming in java?
You can just use an interface for a list of T (ILoT), a representation of an empty list (MtLoT), and a ConsLoT which has a first (which is of the type T) and a rest (which is of the type ILoT).
Bam, you've got a list implementation ( new ConsLoT(new T(arg1, arg2, argN), new ConsLoT(new T(argA, argB, argN), new MtLoT)); ).
Lists are a major part of functional programming, you could use arraylists and just make a new one every time you need to "change" data, but they're essentially lists (just not as clear).
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.
I certainly don't think the code itself is harder to maintain or change, quite the contrary, good functional code is more modular than object-oriented.
just anecdotal, could be a problem with something I'm doing or I could have just gotten luckier with OO than with F and encountered much better code in the former.
