Why Functional Programming is not more widely used in industry? | Hacker News Reader

Why Functional Programming is not more widely used in industry?

8 pointsxmklb19 comments

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.

View on HN

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.

> Because it's hard and non-obvious.

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

Do you think monads, functors, recursion, and immutability (just to take a few staples of functional programming) are easier for a beginner to wrap their head around than loops, re-using variables, etc?

I would be surprised if, using a sample group of say 100 beginner programmers, the majority found Haskell easier to learn and write beginner stuff in than JavaScript, python, or insert-primarily-imperative-language-here.

Most of these are advanced topics though. You don't teach a beginner about OOP design patterns from the get go either.

If you start with defining functions, calling them, composing them, and using map/filter/reduce and all the stream like operations filter, remove, select, merge, substract, etc. I think it might be just as simple.

Haskell is a bad choice though, because it also forces you to learn about advanced type theory.

The truth is, I do believe there is a gap in that there's no FP language that doesn't also introduce another complex paradigm. MLs introduce advanced type theory. Lisps introduce advance meta-programming and homoiconicity.

If you take Python, and teach it using only its FP constructs, I think that is probably simpler to learn to a beginner.

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 think its because you don't need too.

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'll see your monad and lift you a functor.

Or maybe computer programming should start bottom-up, progress through single-static assignment (SSA) and then get to impure, mutable constructs.

Depends where.

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.

Another reason is not a lot of people know what it really means to go functional.

Do you mean they don't know the benefits of functional programming?

Has slightly higher barrier to entry than other languages.

Companies would rather hire 100 replaceable monkeys over 10 highly paid functional programmers who are hard to replace.

- Replaceable monkey.

Functional languages often fall into the trap of making hard things easy at the cost of making easy things hard and then no one uses them.

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.

However, efficiency should be secondary to ease of reading/writing and validity of the program (wrt target application) for most programs (obviously efficiency is a primary concern for certain embedded domains, network applications, and game engines).

The nice thing (from my view) about functional languages (particularly those of the ML family, but also the logic languages like Prolog) is that the semantic distance between specification and implementation is very short. This means you can rapidly describe your problem domain and translate that to a reference implementation.

If performance is critical, you can then work on improving the efficiency of this implementation, or write the program (or parts of it) in a separate language. When it comes time to verify the second program (with a larger semantic gap between specification and implementation) you can run both, ignoring timing, and observe whether they produce comparable output (within whatever constraints you need for your application, so equal or within some error bound).

When your specification changes, you can modify the reference implementation first (where reasoning about the problem ought to be easier) and then work on your deployed system. This does introduce overhead in that you're maintaining two systems, but if you're doing good V&V you're already building a comprehensive model of your deployed system. Why not have a model that can generate your test procedures and target results for you rather than hand building everything?

Reply on news.ycombinator.com