That and everything being an expression that returns a value.
Mainstream languages are slowly moving towards more and more functional concepts. The progress towards referential transparency is slow, but ongoing.
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.
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.
Clojurescript has a lot of other problems -- e.g. not really having an ecosystem outside of Lein -- but using cljs/om for the first time was like a breath of fresh air.
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 isn't really complete.
But, hey, even C++ got lambdas.
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.
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.
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.
> Which is not all it's touted up to be.
It's not even true!
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.
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/) 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?
And because customers will pay more for software with bugs in it.
http://stackoverflow.com/questions/2835801/why-hasnt-functio...
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.
