Why Isn't Functional Programming the Norm? [video]

The top comment on YouTube raises a valid point:

> I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage collection, you name it. FP will always occupy a niche because of where it sits in the abstraction hierarchy. I'm a real time graphics programmer and if I can't mentally map (in rough terms, specific if necessary) what assembly my code is going to generate, the language is a non-starter. This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

I’m all for mechanical sympathy, and I’m sure that some programmers legitimately need their language to map neatly to assembly, but that isn’t the norm as evidenced by the overwhelming popularity of interpreted and VM languages. Lots of companies are making money hand over fist with Python, which is probably 3 orders of magnitude (or more) slower than the optimized C or C++ that this real-time graphics engineer is writing.

EDIT: Is this controversial? What are downvoters taking issue with? That Python is a very popular language? That it is much slower than C/C++?

we users pay a price for this trend though :( Those python users could switch to F#/OCaml/Clojure and get a big speed boost too!

Python is perfectly fine for glueing together functionality that deals with high latency systems, like a data pipeline that executes queries that are running for minutes. It does not matter from the performance point of view if this code is in Forth or Python, but it matters from the point of view how long does it take to implement and how many engineering hours need to go into it. This is why Python is a good option and F#/OCaml/Clojure is not going to bring much to the table in such cases. Even if I want to implement the ETL pipeline in Clojure or OCaml the rest of the engineers are not ok with these languages, the build systems involved and package management or IDE options, integrations. These are also factors when you select a language. Clojure is my absolute favourite language but there are no people in most of the companies where I work who could buy into it. Management sees it as a risk, not to be able to hire engineers for it. There are many dimensions to this problem than it appears at first.

I would not advertise Python as a language with good IDE support nor package management. I fight with both of these regularly. Also, Python is reasonably suited for gluing together other high performance systems, but not everything in the world is glue code, and as soon as you need to do something O(n) on your dataset, you’re either paying an enormous performance penalty or you’re not writing that bit in Python. People kid themselves into thinking that Python’s C interop will make things fast, and sometimes it does, but it often makes it even slower if the system needs to cross the language boundary O(n) or worse.