3 ms·

> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a

by pyrale 6y ago

> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a self-contradicting definition that can be wrestled with, and it is really aggravating. Functional programming as a concept is well defined, and it's not merely "first-order functions". The reason why many functional languages don't have the same feature set is that programming languages are works of engineering, and that the essence of engineering is to make tradeoffs. For instance, F#, a functional language, has many non-functional bits, because the goal pursued was to bring FP to .net, and they made sensible choice to promote interop above functional purity. Likewise, most people doing FP with Lisp in the early days still used mutable variables, because they were limited by the machines they had. Another example is the ability to perform all kinds of side-effects in many FP languages (Erlang, Clojure, etc.). That doesn't mean FP practicioners are totally fine with having side-effects. It means that totally separating side-effects from code in a general-purpose programming language is not always easy, and that in the interest of having useful projects, sometimes this goal is set aside. On the other hand, programs running on more limited runtimes (eg. Elm in browsers) achieve it completely. It is really a pity that so many people can't or don't want to acknowledge the nature of engineering work, and hold imperfections against the creators, or the concepts they try to implement.

dgb23 6y ago
I agree. Also in a practical sense, functional paradigms are sometimes or often implemented with a single global mutable variable as a sort of database. This pattern is quite typical for both Clojure programs and JavaScript frontend programs. It is really more about controlling state and avoiding it where deemed unnecessary, rather than adherence to a total philosophy. This is done for practical reasons (avoiding pain mostly), not for ideological ones.
kibwen 6y ago
> Functional programming as a concept is well defined, and it's not merely "first-order functions". Then, sincerely, what is the definition? Does that definition succeed in excluding languages that are not considered functional, e.g. C++, Java, Python, Go? And if it doesn't, and the definition is so broad as to encompass every language, then what is the useful purpose of going out of one's way to label a language as "functional"?
- benrbray 6y ago
  Functional programming languages, more often than not, distinguish themselves with some combination of the following features: * First-order functions * Partial function application / currying * Type inference * Algebraic data types * Typeclasses * An emphasis on pure functions (side effects must be explicitly annotated), opening up more possibilities for static analysis * Lazy evaluation This is not to say that the above features cannot be emulated by other languages. For instance, Rust has traits, which serve more or less the same practical purpose as Haskell typeclasses. However, FP is designed to prioritize the above features, whereas other languages may not be.
  - lifthrasiir 6y ago
    > However, FP is designed to prioritize the above features, whereas other languages may not be. This statement is pretty vauge and further supports kibwen's claim that a term "functional programming" ceased to be meaningful or is in the course of being so. I can't see the reason that Rust is not as functional as OCaml by your standard, as both fill four boxes out of seven (only OCaml has currying, only Rust has typeclasses). It can be argued that Rust was not originally designed as functional one, but that would be absurd because it doesn't relate to the current language.
- pyrale 6y ago
  This quote elsewhere in the thread lines up with my knowledge: > Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version. Other people have correctly pointed out that this is an extremely ambitious idea, since, as they have noted, you can't build a turing-complete language with pure and total functions. This very high bar explains why there has been so many different design decisions in languages, and why most fp languages make tradeoffs in order to reach a compromise between what they believe is important in that concept, and what they can pull in terms of usable software. As I noted as a response to that thread, we have seen in the recent years languages that achieve pure/total functions, but this was only possible because so many forebearers had tried different designs, and comprmised to produce usable software they could iterate from.
lifthrasiir 6y ago
> It is really a pity that so many people can't or don't want to acknowledge the nature of engineering work, and hold imperfections against the creators, or the concepts they try to implement. This would be a great stretch if it was meant to be a reply rather than a generic statement. To me the increasing irrelevance of a term "functional" is in fact the biggest success of the FP: it is entering the realm shared by, say, the term "structural programming" which is so universal that it became meaningless. It is an amazing feat given that no other terms for programming paradigms ever have been close this much! Given any standard about the FP, there is a definite disparity between languages that should be called functional and languages that are actually called functional. I think the increasing universality of functional paradigm explains this, and kibwen is merely proposing another term describing the latter.

by pyrale 6y ago

dgb23 6y ago

I agree. Also in a practical sense, functional paradigms are sometimes or often implemented with a single global mutable variable as a sort of database. This pattern is quite typical for both Clojure programs and JavaScript frontend programs. It is really more about controlling state and avoiding it where deemed unnecessary, rather than adherence to a total philosophy. This is done for practical reasons (avoiding pain mostly), not for ideological ones.

kibwen 6y ago

> Functional programming as a concept is well defined, and it's not merely "first-order functions". Then, sincerely, what is the definition? Does that definition succeed in excluding languages that are not considered functional, e.g. C++, Java, Python, Go? And if it doesn't, and the definition is so broad as to encompass every language, then what is the useful purpose of going out of one's way to label a language as "functional"?

benrbray 6y ago
Functional programming languages, more often than not, distinguish themselves with some combination of the following features: * First-order functions * Partial function application / currying * Type inference * Algebraic data types * Typeclasses * An emphasis on pure functions (side effects must be explicitly annotated), opening up more possibilities for static analysis * Lazy evaluation This is not to say that the above features cannot be emulated by other languages. For instance, Rust has traits, which serve more or less the same practical purpose as Haskell typeclasses. However, FP is designed to prioritize the above features, whereas other languages may not be.
- lifthrasiir 6y ago
  > However, FP is designed to prioritize the above features, whereas other languages may not be. This statement is pretty vauge and further supports kibwen's claim that a term "functional programming" ceased to be meaningful or is in the course of being so. I can't see the reason that Rust is not as functional as OCaml by your standard, as both fill four boxes out of seven (only OCaml has currying, only Rust has typeclasses). It can be argued that Rust was not originally designed as functional one, but that would be absurd because it doesn't relate to the current language.
pyrale 6y ago
This quote elsewhere in the thread lines up with my knowledge: > Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version. Other people have correctly pointed out that this is an extremely ambitious idea, since, as they have noted, you can't build a turing-complete language with pure and total functions. This very high bar explains why there has been so many different design decisions in languages, and why most fp languages make tradeoffs in order to reach a compromise between what they believe is important in that concept, and what they can pull in terms of usable software. As I noted as a response to that thread, we have seen in the recent years languages that achieve pure/total functions, but this was only possible because so many forebearers had tried different designs, and comprmised to produce usable software they could iterate from.

lifthrasiir 6y ago

> It is really a pity that so many people can't or don't want to acknowledge the nature of engineering work, and hold imperfections against the creators, or the concepts they try to implement. This would be a great stretch if it was meant to be a reply rather than a generic statement. To me the increasing irrelevance of a term "functional" is in fact the biggest success of the FP: it is entering the realm shared by, say, the term "structural programming" which is so universal that it became meaningless. It is an amazing feat given that no other terms for programming paradigms ever have been close this much! Given any standard about the FP, there is a definite disparity between languages that should be called functional and languages that are actually called functional. I think the increasing universality of functional paradigm explains this, and kibwen is merely proposing another term describing the latter.