6 ms·

> Culture matters very little. What really matters is what the language's semantics allows. I disagree. Java's semantics permit defining pure functions, immuta

> 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++ ;-)
  - catnaroek 9y ago
    > Immutable objects do not have identity and are values. Really? https://ideone.com/mmQJGr https://ideone.com/mmQJGr > And the distinction between primitives and objects in Java, for our discussion here, is irrelevant. All it takes to disabuse you of this notion is a little bit of reflection. > That Haskell can force purity via its laziness This is not true. Purity is enforced via the type system. > but not required for doing FP, just like how static types aren't required for doing FP either Completely agree here. > but they've been preceded by LISP and ML. ML is a functional language. Scheme already forces you to squint your eyes a lot. Lisp is not a functional language by any stretch of the term's meaning.
    - seanmcdirmid 9y ago
      Even if their encoding has identify, immutable value don’t need it. Languages like C# allow you to throw off identity altogether with pass/store by value structs.
      - catnaroek 9y ago
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.

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++ ;-)
- catnaroek 9y ago
  > Immutable objects do not have identity and are values. Really? https://ideone.com/mmQJGr https://ideone.com/mmQJGr > And the distinction between primitives and objects in Java, for our discussion here, is irrelevant. All it takes to disabuse you of this notion is a little bit of reflection. > That Haskell can force purity via its laziness This is not true. Purity is enforced via the type system. > but not required for doing FP, just like how static types aren't required for doing FP either Completely agree here. > but they've been preceded by LISP and ML. ML is a functional language. Scheme already forces you to squint your eyes a lot. Lisp is not a functional language by any stretch of the term's meaning.
  - seanmcdirmid 9y ago
    Even if their encoding has identify, immutable value don’t need it. Languages like C# allow you to throw off identity altogether with pass/store by value structs.
    - catnaroek 9y ago

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.