5 ms·

> Functional Programming is programming with mathematical functions (aka pure functions). Exactly. To which the following must be added: Functions are mappings

> Functional Programming is programming with mathematical functions (aka pure functions). Exactly. To which the following must be added: Functions are mappings from values to values. It makes no sense to try to do functional programming in a language whose semantics does not provide a rich enough supply of values. > And an FP language is one that has features, but also a culture that encourage FP as the main paradigm for solving problems. Culture matters very little. What really matters is what the language's semantics allows.

willtim 9y ago
> Culture matters very little. What really matters is what the language's semantics allows. I disagree. Java's semantics permit defining pure functions, immutable values and persistent data structures, but the "culture" is biased towards idiomatic Java not FP. The languages syntax, defaults and core libraries can make it difficult to program in an FP style. The syntax, defaults and libraries will not change while the culture persists.
- catnaroek 9y ago
  > Java's semantics permit defining pure functions, immutable values Only by social convention. Not enforced by the language's semantics in any meaningful way. In fact, Java does not even allow the programmer to define custom values. All values are primitives or object identities. Note that so-called “value objects” will not fix anything. A fundamental property of functions is so-called “function extensionality”. Two functions “f, g : Foo -> Bar” are equal if and only if “f(x) = g(x)” for every “x \in Foo”. In particular, this means that there should be no equality testing operator for functions, because function equality is undecidable. --- OCaml at least has bona fide values. It allows you to implement procedures that evaluate interesting functions (i.e. value-to-value mappings), even if it doesn't typefully distinguish a special class of procedures that are syntactically guaranteed to evaluate functions. F# and Clojure are lost cases, though. As for Haskell's IO and IORef (or ML's ref), there is absolutely nothing wrong with the ability to implement procedures that do other things besides evaluating functions. The problem is when you lack the ability to express interesting functions, and the root cause is the lack of a sufficiently rich universe of values. --- Your mention of purity completely misses the point. The ability to do traditional imperative programming is a feature, not a bug! The problem here is the inability to do functional programming. The reasons for this are technical, not cultural.
  - willtim 9y ago
    > Only by social convention. Not enforced by the language's semantics Many FP languages do not enforce purity (OCaml, F#, Clojure). Even in Haskell, one could use IO and IORefs everywhere, the semantics fully permit writing "Java code" in Haskell. We need a culture and an understanding of what it means to write idiomatic Haskell. EDIT: responding to your edit: > The problem here is the inability to do functional programming. The reasons for this are technical, not cultural. Yes. But it's not just problems with semantics, it's also the syntax, defaults and available libraries. Culture feeds into all of this, especially as the language and ecosystem evolves. I'm arguing that it does matter.
    - catnaroek 9y ago
      I can't prove anything about programs other people will write, unless the language itself makes guarantees about the programs they can write. Culture doesn't help one iota.
      - willtim 9y ago
        You had better stick with Agda or Coq then ;)
        catnaroek 9y ago
        Nah, Standard ML will do just fine.
  - bad_user 9y ago
    > In fact, Java does not even allow the programmer to define custom values. All values are primitives or object identities. Immutable objects do not have identity and are values. And the distinction between primitives and objects in Java, for our discussion here, is irrelevant. That the language does not enforce purity in any way (besides `final` members and values) that's irrelevant. A lot of things in programming happen by convention. That Haskell can force purity via its laziness, that's a nice feature of the language, but not required for doing FP, just like how static types aren't required for doing FP either — Haskell devs would like to promote the notion that Haskell and derivatives are the only true languages for FP, but they've been preceded by LISP and ML. A lot of things in programming happen by convention. That's not a good argument, or an argument that can be used efficiently for language advocacy. OOP isn't supported explicitly by C either, yet people have built an entire GUI/window manager, along with apps, on top of GObject, which in many ways is more OOP than C++ ;-)
- mercer 9y ago
  I feel you're contradicting yourself a bit. Most of my work involved javascript, and me being enamoured by functional programming, I tried applying it as much as I could. And yet it was only when I used a language that was designed for it that I realized how often I used various 'escape hatches', and when I learned the 'meat' of functional programming. It's possible that I was unusually lazy about it all, but I doubt that. I really was a huge fan of functional programming. But if the language 1) gets in the way (this was pre-arrow functions) and 2) makes it easy to take non-functional shortcuts, it's just too easy to resist. So, as you also say, the 'culture' is biased to non-FP programming. it's hard to go against that without at least some experience with (slightly) stricter FP languages.

willtim 9y ago

> Culture matters very little. What really matters is what the language's semantics allows. I disagree. Java's semantics permit defining pure functions, immutable values and persistent data structures, but the "culture" is biased towards idiomatic Java not FP. The languages syntax, defaults and core libraries can make it difficult to program in an FP style. The syntax, defaults and libraries will not change while the culture persists.

catnaroek 9y ago
> Java's semantics permit defining pure functions, immutable values Only by social convention. Not enforced by the language's semantics in any meaningful way. In fact, Java does not even allow the programmer to define custom values. All values are primitives or object identities. Note that so-called “value objects” will not fix anything. A fundamental property of functions is so-called “function extensionality”. Two functions “f, g : Foo -> Bar” are equal if and only if “f(x) = g(x)” for every “x \in Foo”. In particular, this means that there should be no equality testing operator for functions, because function equality is undecidable. --- OCaml at least has bona fide values. It allows you to implement procedures that evaluate interesting functions (i.e. value-to-value mappings), even if it doesn't typefully distinguish a special class of procedures that are syntactically guaranteed to evaluate functions. F# and Clojure are lost cases, though. As for Haskell's IO and IORef (or ML's ref), there is absolutely nothing wrong with the ability to implement procedures that do other things besides evaluating functions. The problem is when you lack the ability to express interesting functions, and the root cause is the lack of a sufficiently rich universe of values. --- Your mention of purity completely misses the point. The ability to do traditional imperative programming is a feature, not a bug! The problem here is the inability to do functional programming. The reasons for this are technical, not cultural.
- willtim 9y ago
  > Only by social convention. Not enforced by the language's semantics Many FP languages do not enforce purity (OCaml, F#, Clojure). Even in Haskell, one could use IO and IORefs everywhere, the semantics fully permit writing "Java code" in Haskell. We need a culture and an understanding of what it means to write idiomatic Haskell. EDIT: responding to your edit: > The problem here is the inability to do functional programming. The reasons for this are technical, not cultural. Yes. But it's not just problems with semantics, it's also the syntax, defaults and available libraries. Culture feeds into all of this, especially as the language and ecosystem evolves. I'm arguing that it does matter.
  - catnaroek 9y ago
    I can't prove anything about programs other people will write, unless the language itself makes guarantees about the programs they can write. Culture doesn't help one iota.
    - willtim 9y ago
      You had better stick with Agda or Coq then ;)
      - catnaroek 9y ago
        Nah, Standard ML will do just fine.
- bad_user 9y ago
  > In fact, Java does not even allow the programmer to define custom values. All values are primitives or object identities. Immutable objects do not have identity and are values. And the distinction between primitives and objects in Java, for our discussion here, is irrelevant. That the language does not enforce purity in any way (besides `final` members and values) that's irrelevant. A lot of things in programming happen by convention. That Haskell can force purity via its laziness, that's a nice feature of the language, but not required for doing FP, just like how static types aren't required for doing FP either — Haskell devs would like to promote the notion that Haskell and derivatives are the only true languages for FP, but they've been preceded by LISP and ML. A lot of things in programming happen by convention. That's not a good argument, or an argument that can be used efficiently for language advocacy. OOP isn't supported explicitly by C either, yet people have built an entire GUI/window manager, along with apps, on top of GObject, which in many ways is more OOP than C++ ;-)
mercer 9y ago
I feel you're contradicting yourself a bit. Most of my work involved javascript, and me being enamoured by functional programming, I tried applying it as much as I could. And yet it was only when I used a language that was designed for it that I realized how often I used various 'escape hatches', and when I learned the 'meat' of functional programming. It's possible that I was unusually lazy about it all, but I doubt that. I really was a huge fan of functional programming. But if the language 1) gets in the way (this was pre-arrow functions) and 2) makes it easy to take non-functional shortcuts, it's just too easy to resist. So, as you also say, the 'culture' is biased to non-FP programming. it's hard to go against that without at least some experience with (slightly) stricter FP languages.