4 ms·

> I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++ Challenge accepted: FP lang

> I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++ Challenge accepted: FP languages emphasise restriction of mutation.

tel 11y ago
Javascript has Object.freeze and Object.seal built right in! How is that not emphasis? (He asks with a touch of both sarcasm and seriousness.) (I seriously believe that any attempt to define FP will end in tears. It's a marketing term and has no real likelihood of producing legitimate technical value.)
- DanWaterworth 11y ago
  Well, some people write very functional javascript. I've thought of a better definition that circumvents the issue of what constitutes emphasis. Functional languages are languages used predominantly by functional programmers. Being functional probably has more to do with how a language is used than the set of features it boasts.
  - tel 11y ago
    That is precisely my favorite definition :)
  - AnimalMuppet 11y ago
    I don't quite agree. Languages push you in different directions. Haskell pushes you toward FP; you can fight the language and "do" (pun intended) imperative programming, but it's going to be painful. Can you do FP in any language? Maybe not COBOL, but you could do it in C with function pointers. But it's still easier to do it in Haskell than in C, and it's still easier to do imperative programming in C than in Haskell. So you have a point. But languages have different characteristics, too, and those differences let us classify languages, if not as "FP" and "non-FP", at least as "more FP" and "less FP".
    - DanWaterworth 11y ago
      I'm not saying that every language is the same. I'm saying it's very difficult to define styles of programming, but if you have a particular style (in this case functional), you will gravitate towards languages that facilitate that style. At the boundary, where a language doesn't have a particular leaning, the style that you will adhere to is going to be influenced much more by the community around the language than its features.
- dragonwriter 11y ago
  > I seriously believe that any attempt to define FP will end in tears. FP as a programming style to which a programmer may adhere to a greater or less degree is easy to define. FP as a binary is-or-is-not characteristic of programming languages is, well, a misguided concept. To the extent it makes sense to talk about FP -- or OOP, or any other style -- as a feature of a programming language, it is more in terms of the degree to, or better the particular manner in, which it facilitates that style of programming, rather than a binary descriptor.
  - tel 11y ago
    I agree, but then I also add to that the roughly four major definitions of what that means today and the various misinterpretations therein and call it a wash. It's a series of cultures all bandied about within a larger cultural phenomenon and you can take or leave whatever pieces of it you like.
pron 11y ago
That's a good categorization, but it's not a definition. For example, the distance between Haskell and Clojure when it comes to allowing (or discouraging) mutation, is bigger than the distance between Clojure and Java. Which, BTW, I think is true. Imperative "FP" languages have more in common with other impure languages that are not commonly categorized as FP, than with PFP. Clojure, Erlang and even ML really are closer to Java than they are to Haskell. I'd argue that the line is between using the continuation abstraction (or the thread abstraction) vs. monadic composition to achieve side-effects (and it is ironic that more people -- probably orders of magnitude more -- use monads in Java than in Haskell :)). Favoring immutability is a great property, but it is not a hard dividing line. The Java community started encouraging immutability no later than 2001, and Scheme was called functional long before anyone categorized its main features as "restricting mutation".

> I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++ Challenge accepted: FP languages emphasise restriction of mutation.

tel 11y ago

Javascript has Object.freeze and Object.seal built right in! How is that not emphasis? (He asks with a touch of both sarcasm and seriousness.) (I seriously believe that any attempt to define FP will end in tears. It's a marketing term and has no real likelihood of producing legitimate technical value.)

DanWaterworth 11y ago
Well, some people write very functional javascript. I've thought of a better definition that circumvents the issue of what constitutes emphasis. Functional languages are languages used predominantly by functional programmers. Being functional probably has more to do with how a language is used than the set of features it boasts.
- tel 11y ago
  That is precisely my favorite definition :)
- AnimalMuppet 11y ago
  I don't quite agree. Languages push you in different directions. Haskell pushes you toward FP; you can fight the language and "do" (pun intended) imperative programming, but it's going to be painful. Can you do FP in any language? Maybe not COBOL, but you could do it in C with function pointers. But it's still easier to do it in Haskell than in C, and it's still easier to do imperative programming in C than in Haskell. So you have a point. But languages have different characteristics, too, and those differences let us classify languages, if not as "FP" and "non-FP", at least as "more FP" and "less FP".
  - DanWaterworth 11y ago
    I'm not saying that every language is the same. I'm saying it's very difficult to define styles of programming, but if you have a particular style (in this case functional), you will gravitate towards languages that facilitate that style. At the boundary, where a language doesn't have a particular leaning, the style that you will adhere to is going to be influenced much more by the community around the language than its features.
dragonwriter 11y ago
> I seriously believe that any attempt to define FP will end in tears. FP as a programming style to which a programmer may adhere to a greater or less degree is easy to define. FP as a binary is-or-is-not characteristic of programming languages is, well, a misguided concept. To the extent it makes sense to talk about FP -- or OOP, or any other style -- as a feature of a programming language, it is more in terms of the degree to, or better the particular manner in, which it facilitates that style of programming, rather than a binary descriptor.
- tel 11y ago
  I agree, but then I also add to that the roughly four major definitions of what that means today and the various misinterpretations therein and call it a wash. It's a series of cultures all bandied about within a larger cultural phenomenon and you can take or leave whatever pieces of it you like.

pron 11y ago

That's a good categorization, but it's not a definition. For example, the distance between Haskell and Clojure when it comes to allowing (or discouraging) mutation, is bigger than the distance between Clojure and Java. Which, BTW, I think is true. Imperative "FP" languages have more in common with other impure languages that are not commonly categorized as FP, than with PFP. Clojure, Erlang and even ML really are closer to Java than they are to Haskell. I'd argue that the line is between using the continuation abstraction (or the thread abstraction) vs. monadic composition to achieve side-effects (and it is ironic that more people -- probably orders of magnitude more -- use monads in Java than in Haskell :)). Favoring immutability is a great property, but it is not a hard dividing line. The Java community started encouraging immutability no later than 2001, and Scheme was called functional long before anyone categorized its main features as "restricting mutation".