"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.
An imperative program advances computation through "flow of control"
A functional program advances computation through the "transformation of values" (value-oriented programming)
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.
"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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.