
Why hasn't functional programming taken over yet? - 56k
https://web.archive.org/web/20150519053755/http://stackoverflow.com/questions/2835801/why-hasnt-functional-programming-taken-over-yet/2835936
======
coldtea
> _Stateless programs; No side effects_

Which is not all it's touted up to be.

> _Concurrency; Plays extremely nice with the rising multi-core technology_

Nice, but not that nice. Don't expect any significant speedup for the most
common kinds of programs.

> _Programs are usually shorter and in some cases easier to read_

For some people they are harder to read. As for shorter, Python can be pretty
terse too, as can lots of other languages.

> _Productivity goes up (example: Erlang)_

Anecdotal. In the real world, most systems in production (including at NASA
and the most critical environments) are made with imperative/oo/etc
programming, which must count for something. For every WhatsApp there are
10,000 stories of such programs.

> _Imperative programming is a very old paradigm (as far as I know)_

Functional programming is 5+ decades old too. And parts of math are even
older, but we're still keeping them...

> _and possibly not suitable for the 21st century_

Citation needed.

~~~
im_down_w_otp
There are not 10,000 other WhatsApps, FWIW. By any useful measure. User base,
concurrent active sessions, both of those relative to size of dev team and/or
infrastructure footprint, acquisition price, user growth rate, etc.

Though WhatsApp's success was predicated on dogged adherence to core
principles of understanding their problem extremely well, selecting the right
tools to solve that problem, and do as much as possible with as little as
possible. Erlang was just one part of that. Choosing FreeBSD, not hiring
craploads of engineers just for the sake of hiring, keeping as little
intermediate state as possible, etc. we're all contributors to their success
story.

But if you have a high-concurrency, small-packet, low-latency, supreme-uptime
message processing shaped problem it's pretty dang hard to do better than
Erlang as a foundational choice.

~~~
coldtea
> _There are not 10,000 other WhatsApps, FWIW_

No 10,000 other WhatsApps. 10,000 success stories of programs doing what they
need to do with a small team behind them and reliability.

It's about the technical/project success aspects, not about the monetary side
of the equation -- not even about user count. After all Yahoo (back in the
day) and Facebook had a much higher user count while being written in PHP.

------
javajosh
I've noticed that programmers tend to become more interested in functional
programming over the duration of their careers. I think this is because, as a
paradigm, FP solves problems that only experienced programmers realize they
have. I'm not sure what the age distribution of working programmers is, but I
bet the median is in the low 30's at this point, which is when you start being
interested in FP in a real way.

The other side of the coin is that there is tremendous "practical momentum" in
software that is collected in the mass of code written in non-FP ways.
Experienced programmers are usually expected to fix the symptoms, not cure the
disease. Clever people might slip in some functional ideas here and there, but
you're almost always better off learning the nuts-and-bolts of integrating
Lucene with your Jetty app than you are learning Clojure.

~~~
pmarreck
> as a paradigm, FP solves problems that only experienced programmers realize
> they have

This is exactly what I've been saying... and it's the essence of the "FP non-
adoption problem." I came to FP because I became frustrated with classes of
bugs that appeared over and over again in OO (Ruby, in my case) but which seem
to plague FP code much less. In essence, I came to reduce labor/increase
productivity; it's "laziness/impatience/hubris" all over again.

One indicator that I was "naturally" coming to FP is that I noticed I was
writing Ruby code in a very functional style. I say "naturally" because 1) it
made it easier to test 2) it reduced spaghetti code and dependencies 3) it
made it more modular 4) it reduced side effects and bug generation. And all of
these worked together to just make better code, period.

Then I came across Elixir ([http://elixir-lang.org/](http://elixir-lang.org/))
and lo and behold, now I can't wait to find work in this shiny new FP
language.

If most people in a career came to prefer a certain paradigm after 10-20 years
in that career, shouldn't everyone in that career be taking a serious look at
it?

------
sotojuan
Not "taken over" but in many ways functional programming techniques have
gotten big in front-end land, not only with JavaScript but also "real"
functional languages like Elm or ClojureScript.

~~~
jondubois
Good point, languages like JavaScript support both imperative AND
declarative/functional styles. A language that lets you do both covers more
use cases than a language that only does one. With a multi-paradigm language
like JS, companies can choose what approach they want to use (and to what
extent) and enforce it via a programming styleguide. With JavaScript, you
could even run a linter over your code to strictly enforce your own FP rules.

There is no doubt that FP has taken over JavaScript - All new popular
frameworks including Angular, Polymer and React are declarative/functional
with the exception of a few minor (but very useful) imperative concepts (e.g.
these frameworks do encourage you to keep 'state' inside models).

FP is awesome but 100% pure FP is just not practical - When building real-life
systems, ultimately, you need to keep stack of state somewhere - Be in in the
database or inside a model in your code.

~~~
eru
> Good point, languages like JavaScript support both imperative AND
> declarative/functional styles. A language that lets you do both covers more
> use cases than a language that only does one.

For what's it worth, some people refer to Haskell as their favourite
imperative language. And they are only semi-joking: while the library
ecosystem is firmly in the camp of functional idioms, imperative programming
is Haskell is pretty nice and straightforward---you'll just have to tag your
code with eg IO or the State Monad.

~~~
spion
If you use the ST monad instead of State, you get actual mutable variables.
STArray lets you write typical imperative algorithms that work with mutable
arrays, like sieve of Eratosthenes or dynamic programming.

Imperative sieve of Eratosthenes:

[https://gist.github.com/rik0/1171446#file-
erat1-hs](https://gist.github.com/rik0/1171446#file-erat1-hs)

~~~
eru
Yes. Though sieve of Eratosthenes really cries out for a sort-of-lazy infinite
array.

------
panic
It has! Almost all major languages today let you pass functions (and closures
with captured bindings) as values.

~~~
iopq
That's not really what functional programming is about. Functional programming
is more about avoiding state and referential transparency. Most programmers do
not attempt to do this in mainstream programming languages.

~~~
Avshalom
It's what functional programming was about for the first twenty years.

That and everything being an expression that returns a value.

~~~
coldtea
20? More like 40. Until 2005 or so few considered this "pure" style essential
to FP.

------
DrScump
Why does this point to the Wayback archive of the page instead of the native
page?

[http://stackoverflow.com/questions/2835801/why-hasnt-
functio...](http://stackoverflow.com/questions/2835801/why-hasnt-functional-
programming-taken-over-yet/2835936)

~~~
iconjack
I was wondering that myself. Figured it must be because SO deleted the
original, but like you, I checked and there it was, not even closed.

------
a3n
Possibly because the way we learn math, and the math that most of us learn, is
taught procedurally. It's the mindset that many of us grow up with.

I'm not in the valley, and I can't recall ever seeing an ad for functional
anything, not even Erlang. I'm sure there's some around, around here, but not
enough that I'll see it when I'm casually looking.

------
pacala
Between Excel and SQL, I'd say collection-oriented programming has pretty much
taken over the world.

~~~
pklausler
One could make a case for a spreadsheet being a limited kind of pure
functional programming language.

~~~
dang
Not pure, because you have state at the top level.

~~~
pklausler
Sure, but it isn't being modified by the expressions in the cells.

~~~
dang
True, and that's a good way of putting it.

------
xyzzy4
Because it doesn't have enough advantages to justify the added complexity.

~~~
the_cat_kittles
extremely testable, easier to reason about, automatically dry, parallelizable,
automatically reusable, memoizable, composable, can be analyzed with some
theoretical systems, and most important- you get stuff that works better (in
my experience)

~~~
voltagex_
That's great, but how do I write a functional version of
[https://github.com/voltagex/junkcode/blob/master/CSharp/spot...](https://github.com/voltagex/junkcode/blob/master/CSharp/spotprices/spotprices/Program.cs)?

All this does is pull a list of "spot instance" prices from AWS EC2, sort them
and filter them. I rewrote this from a python script that became too complex.

The last time I looked at Haskell, it needed ~700MB of dependencies before I
could even get started.

Edit: Clojure looks like a good way to start, although
[https://github.com/mrowe/clj-aws-ec2](https://github.com/mrowe/clj-aws-ec2)
isn't really complete.

~~~
rtpg
There are ways to write things that are similar with Haskell. Just like there
are design patterns for functional techniques in imperative languages, there
are design patterns for imperative techniques in functional language....

So for example, here you could make a nice little EC2 DSL that would get your
stuff (for the actual Haskellers: Free Monad):

    
    
        spotPrices :: Region -> EC2 [SpotPrice]
        spotPrices = GetSpotPrice -- DSL Leaf, executed by runEC2
    
        spotPricesForAllRegions :: [Region] -> EC2 [SpotPrice]
        spotPricesForRegions regions =
            concat <$> MapM spotPrices regions
        

Your spot price update function becomes something even simpler now:

    
    
        runEC2 :: EC2 a -> EC2Config -> IO a
        runEC2 = stuff -- this is where you call whatever EC2
        -- lib is available
    
     
        updateSpotPriceFile :: [Region] -> IO [SpotPrice]
        updateSpotPriceFile regions = do
            spotPrices <- runEC2 (spotPricesForAllRegions regions)
                                 (myEC2Configuration)
            writeToFile (toJSON spotPrices) "spotprices.json"
            return spotPrices
    
    

I'm not going to port all of it, but with a more functional version you could
avoid having to keep on making EC2 clients all over the place, and you could
keep your config in one place.

The problem is that it's pretty obtuse if you don't know the right design
patterns. There's a myth in FP circles that design patterns are for OOP only
("we have functions, we don't need observer patterns!"), but it's a myth. But
if you get good, you can write some pretty concise code + get all the goodies.

Haskell has the whole GHC thing, and also the issue of lack of good library
documentation (or lack of libraries on certain stuff)...

~~~
voltagex_
Thanks for this. The syntax is definitely taking a bit to get my head around,
but it looks very tidy.

------
zelcon5
Because programming is primarily a business and it's cheaper to hire dumb
programmers for whom functional programming is too difficult.

------
jonsmit
Because most people are not smart.

And because customers will pay more for software with bugs in it.

~~~
zcdziura
Careful, you may cut yourself on all that edge.

