in which there is no such thing as a functional programming language

There is no such thing as a functional programming language.

Ahem. Is this thing on? Let me try again.

There is no such thing as a functional programming language.

All right, now that I've got your attention, let me explain. Functional programming does not have a single definition that's easy to agree upon. Some people use it to mean any kind of programming that centers around first-class functions passed around as arguments to other functions. Other people use it in a way that centers on the mathematical definition of a function such as ƒ(x) = x + 2; that is, a pure transformation of argument values to return values. I believe it's more helpful to think of it as a "spectrum of functionalness" rather than criteria for making a binary "functional or not" judgment.

So functional programming is an action; it describes something you do, or maybe you could say that it describes a way that you can program. Functional programming results in functional programs. Any given program exists somewhere on the spectrum between "not functional at all" to "purely functional". So the quality of "functionalness" is a property that you apply to programs.

Obviously "functional programming language" is a term in widespread use that people do use to describe a certain kind of language. But what does it really mean? I would argue that a language cannot be functional; only a program can be more or less functional. When people say "functional programming language" what they mean is a language that encourages or allows programs to be written in a functional way.

Except for very rare cases, the language itself does not force the programs written in it to be more or less functional. All the language can do is make it more or less difficult/awkward to write functional programs in. Ruby is rarely called a functional programming language. But it's possible (and often wise) to write functional programs in Ruby. Haskell is basically the textbook example of a functional programming language, but imperative Haskell programs exist. So calling a programming language functional (when taken literally) is a bit of a category error. But "a language that encourages programming in a functional way" is an awkward phrase, so it gets shortened to "functional programming language".

Incidentally the exact same argument about "functional programming language" can be applied to the term "fast programming language". There is no such thing as a language that is fast. Only programs can be fast[1]. The language affects speed by determining the effort/speed trade-off, and by setting an upper bound to the speed it's possible to achieve while preserving the semantics of the language[2]. But it does not on its own determine the speed.

Please don't misunderstand me—I don't say this in order to be pedantic and shout down people who use the term "functional programming language". I think it's actually pretty clear what people mean when they use the term, and it doesn't really bother me when people use it. I just want to offer an alternate way of thinking about it; a new perspective that makes you re-evaluate some of your assumptions to see things in a different light.

[1] If you want to be even more pedantic, only individual executions of a program can be fast or slow. There is no inherent speed to the program that exists in a meaningful way without tying it to specific measurable runs of the program.

[2] For instance, the Scheme programming language has scores of different implementations. The same program run with the Chez Scheme compiler will often run several times faster than when it's run with TinyScheme. So saying "Scheme is fast" is a category error; Scheme is not fast or slow. The same is true of Lua; you will usually get much faster measurements when you run a Lua program with LuaJIT vs the reference implementation.

« older | 2021-03-22 08:35:03