The advantages of functional programming appear to put it ahead of other paradigms (like procedural and object oriented programming), yet it seems it still remains associated mostly with academia, if at all.
Because it's hard and non-obvious. Nothing in the real world works this way (including computers). It's mathy, it's hard like math, it's beautiful like a proof, but that only works for the small subset of the population who want to be mathematicians. Maybe there's some brain structure thing where this works better for 5% of the population. Maybe their biologically wired implicit grammar processor in their brain is a little different. Maybe in the next century we'll find a gene for 'functional programmer'. But it still just doesn't work for the majority of people. If it works for you, rock on with that for your solo work or find a group of likeminded people and do something with them, but I think it's just not going to have appeal to most people.
I would argue that for someone who never programmed functional programming will be much easier to learn.
Your statement is only correct for people who programmed for years in an imperative style and then tried to pick up FP, because at this point you have a lot of unlearning to do, and a lot of your know how becomes absolute, don't use variables, don't use loops, push your side effects out... and after all this unlearning you'll have to learn new concepts and abstractions like Monads and Applicative...
On one hand, I agree that there is something about the "biologically wired implicit grammar processor". I would view it more along the lines "if you state your problem in a way we are used to talk abou it, you will find your solution easier." I suspect this is the reason, why even my parents, that are mostly economists, like SQL whith its faux-english, but I wouldn't try to teach them relational algebra :-)
On the other hand, I am not sure functional programming is so far out of bounds of normal people.
Annecdotaly, when I was learning programming, in an after-school club, when ~12, I remember my teacher (a college student) complaining, how hard was it for me and other students to comprehend a statement like "i = i + 1". I think the language was Basic. I suspect that if we have been taught something more functional, we might not even encounter this :-)
I am actually not sure why we had problems with this. Maybe because we already were solving equations in school, and "i = i + i" is looks like "0 = 1" nonsense. Maybe the self-reference tripped us up, and recursion would trip us the same or worse. Maybe the = sign was the problem, where it means sometimes equality check and sometimes value assignment.
First, I think functional programming is used more often than you realize. Not _pure_ functional programming, to be sure, but the use of functions instead of objects is found in tons of real-world software.
Now, as to why pure functional programming is not used, well it's the same reason why pure anything is not found much outside of academia, or why there aren't always unit tests, or why there is still lots of procedural programming. The software gets written in a hurry, by lots of different programmers with different levels of experience, and they do it in different ways. Some of them use a functional style, and some use objects, and some use bubble gum and duct tape.
It's unclear though if functions that are not pure can be considered functional programming, or those are just procedures, and the use of procedural programming.
I love functional programming, and actually work in Clojure at my job, we switched from Java.
That said, it is not a killer feature. It is only marginally better in a way that only converts can appreciate.
To management and devs not using it, they don't notice anything different about the software we deliver.
Yes, it makes you marginally more productive. Yes, our code is marginally safer. And ya, you could probably measure the difference given rigorous study. But its not big enough to be obviously better.
And while you gain a marginal boost in productivity, safety, evolvability and simplicity. You also lose in performance and memory consumption. Unfortunatly, the latter two metrics are much easier to measure, and thus more noticeable.
Also, most FP languages have extra barriers to entry. Lisps have unfamiliar syntax and meta-programming tacked on. MLs have complex type theory tacked on. There's not really an FP language that has a simple type system, and familiar Algol like syntax.
Finally, the fact that the benefits are not obvious, and only marginal, combined with the huge lead that procedural and OOP languages have. Which they gained because for a long time FP was too slow to be practical. Means that its almost impossible to make a dent in the industry. The momentum for OOP and procedural is too strong. More experts to teach beginners, and more existing code writen in them, means people only learn and work on and get better at OOP and procedural.
Because for the vast majority of software, fast to build is far more important than provably correct.
Because there aren’t any batteries-included RAD frameworks in functional languages yet.
Because most undergrad degrees, if they touch on functional programming at all, do so in only a cursory manner.
Because for most purposes a smart CTO will choose to develop a project in a language/framework that’s good enough and for which it’s relatively easy to hire skilled developers over a language/framework that offers some minor technical advantages but will make hiring even more excruciating than it is for widely-used tools.
One of the reasons could be that most programming languages do not have immutable datastructures by default, and most students are taught to progam within a "mutable" environment. Isn't of the first things they teach at schools about "variables", symbols which refer to locations in RAM which might change their contents at any time (at languages like C, Java and C#)?
I think Rich Hickey calls this "place oriented programming" ;)
It is funny how mathematical formulas do not have a "return" statement, they are just evaluated. Math doesn't have an assignment operation either.
I.e. I spent 3 years on nodejs project, and first require was either lodash or underscore, bringing in the usual suspects of map, reduce, filter along with some sort of pipelining operator.
I spent 6 months on C# project using RX, and the code was quite functional, with anonymous functions and closures everywhere.
Of course, once you move away from mutable data-structures and variables as default (i.e. clojure, erlang), or even to limitting side effects with type system (haskell), you are entering a niche.
For new projects, a lot of it has to do with what existing libraries and tools you can use to get to market quickly. For established projects, it's going to be a hard sell to switch over.
I really like OCaml for example but for web projects it's not practical. TypeScript is a decent compromise at the moment. I like that the industry is (veryyy) gradually moving towards strong typing though.
Funny, I'd say it is exactly the opposite. :) FP makes easy things almost trivial but hard problems almost impossible. E.g writing quicksort is trivial in Haskell, writing an implementation of quicksort that runs efficiently in Haskell is very hard.
[+] [-] brianolson|7 years ago|reply
[+] [-] SubMachineGhost|7 years ago|reply
I would argue that for someone who never programmed functional programming will be much easier to learn.
Your statement is only correct for people who programmed for years in an imperative style and then tried to pick up FP, because at this point you have a lot of unlearning to do, and a lot of your know how becomes absolute, don't use variables, don't use loops, push your side effects out... and after all this unlearning you'll have to learn new concepts and abstractions like Monads and Applicative...
[+] [-] a-saleh|7 years ago|reply
On the other hand, I am not sure functional programming is so far out of bounds of normal people.
Annecdotaly, when I was learning programming, in an after-school club, when ~12, I remember my teacher (a college student) complaining, how hard was it for me and other students to comprehend a statement like "i = i + 1". I think the language was Basic. I suspect that if we have been taught something more functional, we might not even encounter this :-)
I am actually not sure why we had problems with this. Maybe because we already were solving equations in school, and "i = i + i" is looks like "0 = 1" nonsense. Maybe the self-reference tripped us up, and recursion would trip us the same or worse. Maybe the = sign was the problem, where it means sometimes equality check and sometimes value assignment.
[+] [-] rossdavidh|7 years ago|reply
Now, as to why pure functional programming is not used, well it's the same reason why pure anything is not found much outside of academia, or why there aren't always unit tests, or why there is still lots of procedural programming. The software gets written in a hurry, by lots of different programmers with different levels of experience, and they do it in different ways. Some of them use a functional style, and some use objects, and some use bubble gum and duct tape.
[+] [-] didibus|7 years ago|reply
[+] [-] didibus|7 years ago|reply
I love functional programming, and actually work in Clojure at my job, we switched from Java.
That said, it is not a killer feature. It is only marginally better in a way that only converts can appreciate.
To management and devs not using it, they don't notice anything different about the software we deliver.
Yes, it makes you marginally more productive. Yes, our code is marginally safer. And ya, you could probably measure the difference given rigorous study. But its not big enough to be obviously better.
And while you gain a marginal boost in productivity, safety, evolvability and simplicity. You also lose in performance and memory consumption. Unfortunatly, the latter two metrics are much easier to measure, and thus more noticeable.
Also, most FP languages have extra barriers to entry. Lisps have unfamiliar syntax and meta-programming tacked on. MLs have complex type theory tacked on. There's not really an FP language that has a simple type system, and familiar Algol like syntax.
Finally, the fact that the benefits are not obvious, and only marginal, combined with the huge lead that procedural and OOP languages have. Which they gained because for a long time FP was too slow to be practical. Means that its almost impossible to make a dent in the industry. The momentum for OOP and procedural is too strong. More experts to teach beginners, and more existing code writen in them, means people only learn and work on and get better at OOP and procedural.
[+] [-] cimmanom|7 years ago|reply
Because there aren’t any batteries-included RAD frameworks in functional languages yet.
Because most undergrad degrees, if they touch on functional programming at all, do so in only a cursory manner.
Because for most purposes a smart CTO will choose to develop a project in a language/framework that’s good enough and for which it’s relatively easy to hire skilled developers over a language/framework that offers some minor technical advantages but will make hiring even more excruciating than it is for widely-used tools.
[+] [-] nikonyrh|7 years ago|reply
I think Rich Hickey calls this "place oriented programming" ;)
It is funny how mathematical formulas do not have a "return" statement, they are just evaluated. Math doesn't have an assignment operation either.
[+] [-] modells|7 years ago|reply
Or maybe computer programming should start bottom-up, progress through single-static assignment (SSA) and then get to impure, mutable constructs.
[+] [-] a-saleh|7 years ago|reply
I.e. I spent 3 years on nodejs project, and first require was either lodash or underscore, bringing in the usual suspects of map, reduce, filter along with some sort of pipelining operator.
I spent 6 months on C# project using RX, and the code was quite functional, with anonymous functions and closures everywhere.
Of course, once you move away from mutable data-structures and variables as default (i.e. clojure, erlang), or even to limitting side effects with type system (haskell), you are entering a niche.
[+] [-] seanwilson|7 years ago|reply
I really like OCaml for example but for web projects it's not practical. TypeScript is a decent compromise at the moment. I like that the industry is (veryyy) gradually moving towards strong typing though.
[+] [-] m3kw9|7 years ago|reply
[+] [-] xmklb|7 years ago|reply
[+] [-] UK-Al05|7 years ago|reply
Companies would rather hire 100 replaceable monkeys over 10 highly paid functional programmers who are hard to replace.
- Replaceable monkey.
[+] [-] Sevii|7 years ago|reply
[+] [-] bjourne|7 years ago|reply
[+] [-] cam3ham|7 years ago|reply
[deleted]