6 ms·

> You can absolutely write fairly nice functional code in Java already You mean it has Lambdas? Yes that's a start, but there's a lot more it needs to claim go

> You can absolutely write fairly nice functional code in Java already You mean it has Lambdas? Yes that's a start, but there's a lot more it needs to claim good FP support. Programming with lambdas is not sufficient to do "functional programming", which is really about composing pure functions (everything else follows from this, e.g. immutable data). Java's roadmap does look promising though.

Ma8ee 4y ago
You get quite far with the "final" keyword.
- PaulHoule 4y ago
  Actually it’s the other way around. There are very good persistent collection libraries for Java but if you are going to ‘update’ then you can’t store them in a final field since you get a new collection object. On the other hand the only thing final about final List<Whatever> that is the identity of the list. I also think Either and Optional are cancers. Type erasure takes some of the fun away from Either. Before you had Optional you had one problem, you might have a null. With Optional you have two problems, you can get a null AND you can get an empty. I worked at a place that used Scala and the engineering manager would talk your ear off like an Amway scam person about how much better monads were for error handling than Exceptions. I started working on non-Scala stuff but once they put me on the Scala side I found out that error handling was just missing in most places even though they allegedly did code reviews. It was definitely a frying pan to fire situation relative to Exceptions. (The time before that whenI coded in Scala I found that people would spend 3 days writing something concurrent with Actors that only used 2 out of 8 cores and was rife with error conditions that could be done in 20 minutes with an Executor in Java.) In a a parallel universe where LISP was the dominant language, people would be writing essays about how great COBOL and Cold Fusion and PHP are, about what a genius Noam Chomsky was, how recursive descent parsers are a force multiplier, etc.
  - grumpyprole 4y ago
    > With Optional you have two problems, you can get a null AND you can get an empty. That's not really the fault of the Optional. That's Java adding null as value to every type. Java also allows lists of nulls, mappings to null etc. An optional is just a container that stores one item at most. I do agree that it makes optionals less useful in Java. In Haskell and OCaml they are used essentially instead of null.
    - PaulHoule 4y ago
      I'd grant that. I'd say the authentic-to-Java approach to the problem is to static import something like a "map" function var result = map(x,x=>x.y) which is equivalent to var result = isNull(x) ? null : x.y where isNull is static imported from Objects. An approach which is authentic to some other languages is to consistently used a list with 0 or 1 members instead of optionals.
    - ryanianian 4y ago
      Static analysis can catch a `null` being used in a place that wants an Optional. With Optional being fully pervasive in a codebase the `null` concept could effectively be eliminated.
  - switchbak 4y ago
    "The time before that whenI coded in Scala I found that people would spend 3 days writing something concurrent with Actors that only used 2 out of 8 cores and was rife with error conditions that could be done in 20 minutes with an Executor in Java" Sounds like you were working with some folks that were just learning the language/idioms (which is admittedly a big hurdle). I haven't used actors in a very long time. Simple future composition and reactive streams get you very far, at an absolute fraction of the code size and complexity of the equivalent vanilla Java approach (ie: not using Rx).
    - Skgqie1 4y ago
      That sounds very close to a "No True Scotsman" type fallacy. I've done a fair bit of consulting in the past working with Scala, and my experience closely matches the one described in the grandparent post - the issues happened with veterans more than newbies in my experience (Although that's a function of mostly working with veterans and few newbies)
oaiey 4y ago
Pure Functions is indeed a factor, but not the only one. Other irrelevant factors are pattern matching, tail call recursion, recursion instead of loops, etc. FP is about treating data differently and dealing with side effects differently. Pure Functions are an implementation strategy of FP, not the core differentiator. And that data/side effect difference, you can easily handle in Java, C# and other OO languages if you just overcome the culture of OO-only thinking. And despite I think the article is not perfect (who says, that a function cannot have a class/interface wrapper (aka strategy)), there is an element of truth in the spirit of the headline.
- grumpyprole 4y ago
  > Pure Functions are an implementation strategy of FP, not the core differentiator. "Functional Programming" is not a well-defined term. But I would argue that if you are not using pure functions then you have more of a hybrid imperative/functional language, which is fine, especially if you are careful with how you structure your effects. Modern FP languages use monads (Haskell) and/or algebraic effects (Eff) to enable pure functions to describe effects. The pure function is what enables mathematical reasoning and safe function composition.
  - kaba0 4y ago
    What about the Lispian way of FP, e.g. Clojure? It is noting like the Haskellian one, yet they are also on the same spectrum.
    - grumpyprole 4y ago
      Clojure encourages pure functions and immutable data, so definitely a "functional first" language. But it's not a "purely functional" language.
      - kaba0 4y ago
        I don’t think there is a boolean pureness flag, rather a spectrum. Haskell can also introduce arbitrary side effects in any code with some unsafe escape hatches, but sure, the common case doesn’t employ that, so it is a bit more pure than Clojure.

Ma8ee 4y ago

You get quite far with the "final" keyword.

PaulHoule 4y ago
Actually it’s the other way around. There are very good persistent collection libraries for Java but if you are going to ‘update’ then you can’t store them in a final field since you get a new collection object. On the other hand the only thing final about final List<Whatever> that is the identity of the list. I also think Either and Optional are cancers. Type erasure takes some of the fun away from Either. Before you had Optional you had one problem, you might have a null. With Optional you have two problems, you can get a null AND you can get an empty. I worked at a place that used Scala and the engineering manager would talk your ear off like an Amway scam person about how much better monads were for error handling than Exceptions. I started working on non-Scala stuff but once they put me on the Scala side I found out that error handling was just missing in most places even though they allegedly did code reviews. It was definitely a frying pan to fire situation relative to Exceptions. (The time before that whenI coded in Scala I found that people would spend 3 days writing something concurrent with Actors that only used 2 out of 8 cores and was rife with error conditions that could be done in 20 minutes with an Executor in Java.) In a a parallel universe where LISP was the dominant language, people would be writing essays about how great COBOL and Cold Fusion and PHP are, about what a genius Noam Chomsky was, how recursive descent parsers are a force multiplier, etc.
- grumpyprole 4y ago
  > With Optional you have two problems, you can get a null AND you can get an empty. That's not really the fault of the Optional. That's Java adding null as value to every type. Java also allows lists of nulls, mappings to null etc. An optional is just a container that stores one item at most. I do agree that it makes optionals less useful in Java. In Haskell and OCaml they are used essentially instead of null.
  - PaulHoule 4y ago
    I'd grant that. I'd say the authentic-to-Java approach to the problem is to static import something like a "map" function var result = map(x,x=>x.y) which is equivalent to var result = isNull(x) ? null : x.y where isNull is static imported from Objects. An approach which is authentic to some other languages is to consistently used a list with 0 or 1 members instead of optionals.
  - ryanianian 4y ago
    Static analysis can catch a `null` being used in a place that wants an Optional. With Optional being fully pervasive in a codebase the `null` concept could effectively be eliminated.
- switchbak 4y ago
  "The time before that whenI coded in Scala I found that people would spend 3 days writing something concurrent with Actors that only used 2 out of 8 cores and was rife with error conditions that could be done in 20 minutes with an Executor in Java" Sounds like you were working with some folks that were just learning the language/idioms (which is admittedly a big hurdle). I haven't used actors in a very long time. Simple future composition and reactive streams get you very far, at an absolute fraction of the code size and complexity of the equivalent vanilla Java approach (ie: not using Rx).
  - Skgqie1 4y ago
    That sounds very close to a "No True Scotsman" type fallacy. I've done a fair bit of consulting in the past working with Scala, and my experience closely matches the one described in the grandparent post - the issues happened with veterans more than newbies in my experience (Although that's a function of mostly working with veterans and few newbies)

oaiey 4y ago

Pure Functions is indeed a factor, but not the only one. Other irrelevant factors are pattern matching, tail call recursion, recursion instead of loops, etc. FP is about treating data differently and dealing with side effects differently. Pure Functions are an implementation strategy of FP, not the core differentiator. And that data/side effect difference, you can easily handle in Java, C# and other OO languages if you just overcome the culture of OO-only thinking. And despite I think the article is not perfect (who says, that a function cannot have a class/interface wrapper (aka strategy)), there is an element of truth in the spirit of the headline.

grumpyprole 4y ago
> Pure Functions are an implementation strategy of FP, not the core differentiator. "Functional Programming" is not a well-defined term. But I would argue that if you are not using pure functions then you have more of a hybrid imperative/functional language, which is fine, especially if you are careful with how you structure your effects. Modern FP languages use monads (Haskell) and/or algebraic effects (Eff) to enable pure functions to describe effects. The pure function is what enables mathematical reasoning and safe function composition.
- kaba0 4y ago
  What about the Lispian way of FP, e.g. Clojure? It is noting like the Haskellian one, yet they are also on the same spectrum.
  - grumpyprole 4y ago
    Clojure encourages pure functions and immutable data, so definitely a "functional first" language. But it's not a "purely functional" language.
    - kaba0 4y ago
      I don’t think there is a boolean pureness flag, rather a spectrum. Haskell can also introduce arbitrary side effects in any code with some unsafe escape hatches, but sure, the common case doesn’t employ that, so it is a bit more pure than Clojure.