A great lecture by Richard Feldman, on the Elm team, entitled "Why isn't functional programming the norm", explores why some languages are popular.

Is there a TL;DW (too long; don't watch) somewhere? 😉

It's interesting that he doesn't consider Swift or Kotlin to be functional languages.

I don't consider a language to be completely functional unless it allows me to write an entire program in functional style, with no side effects. Virtually all modern languages have first class functions, but most of those require the use of side effects to write any realistic program. So, in addition to function values, I'm also looking for functional data structures (that can be efficiently mutated without using side effects) and functional i/o.

Yeah I was being slightly facetious, but I do think Swift and Kotlin are as functional as something like Scala, and it seems weird to classify them as OO first.

In what way are Swift and Kotlin functional languages, rather than OO first? I just don't see it. Smalltalk is surely an OO first language, and it has always had first class functions and higher order functions as a core feature, only the terminology is different. Functions are called "blocks", the "reduce" or "fold" higher order function is called "injectinto", and so on. Kotlin and Swift support both mutable and immutable objects. Immutable objects are an OO technique for controlling and limiting side effects on data structure objects, and are not the same as functional data structures.

yeah, if your definition is that narrow, I'm guessing Haskell is it, for languages that have some use outside of academia?

The video lists Elm, Closure and ReasonML as functional languages. This is accurate. Elm is a pure functional language. Clojure and ReasonML are imperative/OO as well as functional, but they both support functional data structures: so you can efficiently mutate data structures from inside a pure function, without side effects.

I think "functional" and "pure functional" are getting confused

I’d add one more factor to the causes of popularity: being first. Examples: Unix was the first portable operating system. C was the first language of Unix. Perl was the first full scripting language for Unix. Python was the first OO scripting language for Unix…

@Dan Cook The goal of functional programming is to write programs using pure mathematical functions. The term was invented in the late 1950's/early 1960's and the definition has never changed. In the early days, you couldn't write an entire program using functions because the theory and practice of things like functional data structures and functional i/o hadn't been developed yet. So you had to use hybrid function/imperative languages to do functional programming. Early functional languages like ML and OCaml are hybrid languages. Haskell was the first general purpose language to allow you to write entire programs, including i/o, without leaving the functional paradigm. So that's why Haskell is a "pure functional language", rather than a hybrid functional/imperative language. But FP has always been about programming with mathematical functions, and it is a false dichotomy to claim a distinction between "functional programming" and "pure functional programming".

Backus of FORTRAN fame invented FP at IBM. He was frustrated with the inability to achieve interchangeable parts and compose larger programs. He was convinced that FP would solve this problem, but he died only getting half way to the solution. His Turing award lecture is still interesting, as it points out some of the problems he was trying to solve. Two things he didn't realize is that all programs have a minimal naive implementation, and that really the only difference between languages is convenience of notation, and how the codebases in each language grow in relation to problem complexity. Some grow at n^2, some at n^1.5, and some at n^1.2, and that only in large code bases does the number of dependencies and thus problems grow large enough that exponent can be perceived, and that the asymmetries and imperfections of the underlying hardware is the true source of many problems and issues, and that you have to virtualize a nicer set of hardware to avoid these problems.

It bothers me when decisions like that are left to developers (who are not the ones who own the product and the business), when if the business has a clear understanding, they'd likely go for the clear ROI. In a sense, that means the developers are not really doing the job the business trusted them to. Granted, there are other factors to consider; but my point is that the decision over a 2x ROI should not be the developers choice to make

In fairness to the managers who can't tell the difference between languages; to them it is all greek, they rely on the programmers to point out these things. But there is also the ease of hiring; if you stick to a trailing edge language (like COBOL in the old days, and Java today), you can find thousands of experienced people who know that tool.