4 ms·

The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programmin

by DCKing 12y ago

The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, and will never share FP's redeeming qualities. Lazy by default is a feature of Haskell, and is not a feature of (or necessary for) functional programming. Scala, OCaml, F# and Lisps are not lazy by default.

sigmaml 12y ago
> The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.
- seanmcdirmid 12y ago
  I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming. If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).
- DCKing 12y ago
  Hughes didn't disagree with what I said; I would contend that higher-order functions and laziness only improve modularity iff the language was referentially transparent in the first place. The assumption that the theoretical FP language he discusses is referentially transparent is found on page 2 of Hughes' paper. Java's lambdas only serve to reduce boilerplate; everything done with Java's lambdas was long possible using anonymous classes. Theoretically, they do nothing to present the advantages discussed by Hughes [1]. Hughes also didn't talk about laziness-by-default: his argument still holds if laziness is available somehow (which it is in many FP languages). [1]: Of course, lambdas might improve the style and expressivity of idiomatic Java enough to make up some ground.
mike_hearn 12y ago
You can make immutable objects in Java. The result is quite, quite unpleasant IMHO, but so are many other things in Java. You just create an object that has final fields and a constructor (or a builder if you have a more complex object). Now, nothing stops that immutable object containing a mutable object of course, but that's up to you ... Guava has immutable collections if you want them. Better language support for immutability would not go amiss though.

by DCKing 12y ago

sigmaml 12y ago

> The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.

seanmcdirmid 12y ago
I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming. If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).
DCKing 12y ago
Hughes didn't disagree with what I said; I would contend that higher-order functions and laziness only improve modularity iff the language was referentially transparent in the first place. The assumption that the theoretical FP language he discusses is referentially transparent is found on page 2 of Hughes' paper. Java's lambdas only serve to reduce boilerplate; everything done with Java's lambdas was long possible using anonymous classes. Theoretically, they do nothing to present the advantages discussed by Hughes [1]. Hughes also didn't talk about laziness-by-default: his argument still holds if laziness is available somehow (which it is in many FP languages). [1]: Of course, lambdas might improve the style and expressivity of idiomatic Java enough to make up some ground.

mike_hearn 12y ago

You can make immutable objects in Java. The result is quite, quite unpleasant IMHO, but so are many other things in Java. You just create an object that has final fields and a constructor (or a builder if you have a more complex object). Now, nothing stops that immutable object containing a mutable object of course, but that's up to you ... Guava has immutable collections if you want them. Better language support for immutability would not go amiss though.