For future reference, here are two different takes I've come across. They should illustrate the difficulty of defining what a functional programming language is.
The Ceylon FAQ writes:
What makes a programming language "functional"?
I suppose I can try to take a bit of a guess at what you might mean, but that leaves me even more confused:
Does it mean that all functions are pure (without side effect) and there are no variables? Then Lisp and ML aren't functional? So the only well-known functional language is Haskell?
Does it mean support for higher-order functions? Then Smalltalk, Python, Ruby, JavaScript, C#, Java 8, Ceylon, and arguably even C are all functional programming languages?
Does it mean no loops? What if a programming language defines
foras a syntax sugar for a function call? Oh, so then "functional programming language" boils down to not havingbreak,continueandreturn?Does it mean support for parametric polymorphism? Then C# and Java 5 are functional?
Could it mean an emphasis upon higher-level abstractions named after definitions in category theory? Then, again, Scheme and ML are excluded?
But this approach seems to be based on identifying a single individual feature that makes a language into "a functional programming language". This is obviously flawed. It seems rather obvious that the definition of a functional programming language must be a combination of features.
They conclude with such a combination:
Perhaps what you really want to ask is:
- Does [a certain language] encourage you to write code using immutability, parametric polymorphism, and higher order functions?
Another take goes by Richard Feldman, where he illustrates:
How do you look at a programming language and decide this is a functional programming language or not? How do you do it?
A: It's a functional programming language if it has support for first-class functions!
B: Ok, so Java is a functional programming language?
A: No, no, not Java. They have to be pure.
B: Ok, so OCaml and Clojure are not a functional programming languages?
A: No, no, those count. But ok, you need immutability, that's important.
B: Ok, so Rust is a functional programming language? It's immutable by default, even.
A: No, no, not like that...
Then he concludes:
You know you just go around in circles. One person suggested a score, like if you have a certain number of things checked off,
then like you cross a threshold and the language is considered functional.But ultimately I ended up concluding that classifying languages as functional or not is:
- kind of arbitrary
- definitely very fuzzy
and ultimately not as important as talking about the functional style and the language's support for the style of being able to avoid mutation and side-effects, and still have a really good experience.
Top comments (5)
Some say it’s more about which languages allow you to program in a:
«
Functional style
«
fpcomplete.com/blog/2018/10/is-rus...
To compare and contrast FP, it is useful to ask:
What defines Object-Orientation (or OOP), then?
Here is a list of features, and a tease of the problem of defining even OOP:
paulgraham.com/reesoo.html
On Rust - is it an FP language?: reddit.com/r/functionalprogramming...
Could you even make a definition for a Functional Programming language?
Wittgenstein and the postmodernists would argue against the possibility for such an essentialist definition. Here's why (you can't even define soup!): youtu.be/26fIBA7O5Ag?t=290
Feedback from Functional Programming in Erlang MOOC, week 1 (Simon Thompson)
"What features do you need to call yourself a functional language? My take on this is that nearly every language now has functional features. I think to be a functional language it's as much to do with the features you don't have as to do with the features you do. So if you're in a language where there isn't mutable state um where there aren't imperative ways of doing things you write functions in a purely functional style and that's how you compute from the base upwards. Whereas if you add functions, lambdas say to Java the base computation model is still one where you're changing values inside attributes and you build on top of that a functional layer that lower layer doesn't exist in a function language or at least if it does it's constrained … A functional language is characterized as much by what it doesn't contain as by what it does."
And perhaps "What defines a functional programming language?" is the wrong question.
So a functional language is designed to support computation through "transformation of values".
The genius of Rust is that even as an imperative language it conceptually supports "computation through the transformation of values" because it's largely expression based. That said it's probably easier to learn "value-oriented programming" in a language that only supports that single paradigm - lacking the imperative escape hatches one is forced to adopt the value-oriented mindset in full. However after attaining fluency, value-oriented programming can be applied in languages that aren't strictly "functional".
So I think the contrast isn't "imperative" vs "functional" language but the "flow of control" vs "transformation of values" computational model.
Dr. Alan Kay on the Meaning of “Object-Oriented Programming”
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP."
I think it's interesting that mainstream OOPLs replaced message passing with the transfer of "control flow" from one object to another via a method call. Likely done for pragmatic reasons but perhaps it made OO more imperative than it needed to be.