
Why functional programming doesn't catch on - raju
http://confusion.tweakblogs.net/blog/1418/why-functional-programming-doesnt-catch-on.html
======
jedi_stannis
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?

------
patio11
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."

~~~
jacoblyles
If you don't mind answering, what did you write the software for your startup
with?

~~~
patio11
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.

------
voidpointer
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.

~~~
psranga
Interesting. Thanks for the link to your report.

------
psranga
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".

~~~
weavejester
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.

------
davidmathers
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).

~~~
time_management
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.

~~~
sethg
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.

~~~
time_management
Good point.

For the time it was written (1970s, I believe) the SQL language was way ahead
of the curve compared to the languages being used in enterprise.

------
carterschonwald
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

~~~
gaius
_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.

~~~
carterschonwald
How many truly gifted c/c++ programmers are there as a fraction of all who
professionally use these languages?

~~~
arohner
As a percentage, it's probably smaller than the percentage of gifted
programmers using lisp/haskell/erlang.

However, it's a small percentage of a huge number. It wouldn't surprise me at
all if there are more talented C/C++ hackers than FP hackers.

------
miked
"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.

~~~
weavejester
Pure FP languages eliminate _implicit_ state. You can still have state; it
just has to be explicitly passed in as an argument.

~~~
eru
Or handled as a Monad.

------
Xixi
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.

------
jimrandomh
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.

~~~
gaius
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.

------
raganwald
[http://enfranchisedmind.com/blog/2009/02/22/programming-
does...](http://enfranchisedmind.com/blog/2009/02/22/programming-doesnt-suck-
or-at-least-it-shouldnt/)

------
watmough
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.

------
jrockway
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#.

~~~
speek
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.

~~~
jrockway
Why bother? Round hole, square peg. You will spend 99% of your time fighting
against the language, instead of writing code.

~~~
brl
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?

------
visitor4rmindia
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?

------
miloshh
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!

------
dgabriel
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.

------
suhail
Ever heard of Erlang? =)

It's getting pretty hot right now.

------
nazgulnarsil
because it's harder to maintain.

~~~
schtog
To find replacers you mean?

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.

~~~
nazgulnarsil
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.

