5 ms·

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for examp

by _bxg1 8y ago

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is much bigger than Java itself. The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Clojure is one of the most popular and performant Lisps we currently have, and Scala is one of the closest things we'll get any time soon to a practical version of Haskell. Both of these projects got to avoid building their own garbage collectors, which is an enormous lowering of the effort barrier. And to top it all off, all of these languages' binaries are interoperable, which not only allows you to use different ones for different parts of the same system, but makes it much easier to gradually migrate your legacy codebase to a newer, better language. I don't know if I'd start a new project in Java-the-language, but it's far from a Cobol situation.

ilovecaching 8y ago
It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs. A lot of my reasoning was criticizing the JVM itself, not Java. VM languages add unnecessary complexity in the post container world where ephemerality and kernel APIs (containers) can give the same advantages, although I think Kotlin and Clojure and remarkably good languages.
- coldtea 8y ago
  >It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers). From 1960 to today it remains niche in its pure form, even the most popular language following it fully (e.g. Clojure or similar) is still a niche language. We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles. And that's what modern JS, Java, C#, Rust, etc (even C++) give us. And since FP is a style, it can be followed quite effectively in almost any language -- as long as it has some basic features, which, as you observed, Java has added.
  - ilovecaching 8y ago
    Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". There are many other styles of programming that are data oriented and are a better definition for Rust and some circles of Javascript than functional, but ergonomics of composition and partial application leads to something far short of FP. > We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles. Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone. > JS, Java, C#, Rust, etc (even C++) give us. Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.
    - iainmerrick 8y ago
      Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". No, I think they are using those terms correctly. In FP, “pure” means absolutely no side-effects. So if you add an FP-style library to an existing imperative language, that’s “impure”.
      - ilovecaching 8y ago
        That's not the context in which the word was used, but it's a fair point. I have worked professionally with Haskell, and while I am not good at it (my forte is Erlang which is what I would consider "close to functional"), other developers I have worked with were very good, and watching them code in non functional languages and listen to how they thought about solving problems is were I developed the idea that adding a few features doesn't make a language functional.
  - willtim 8y ago
    > And since FP is a style, it can be followed quite effectively in almost any language. It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised. It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.
- _bxg1 8y ago
  > It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs. I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).
vorg 8y ago
> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too. I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.
- _bxg1 8y ago
  I wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.
- spricket 8y ago
  No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH. Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy
  - zmmmmm 8y ago
    > doesn't share lost of the performance penalties of Groovy That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.
  - olavgg 8y ago
    Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension
    - 8y ago
boksiora 8y ago
thank you for this comment. it brings a lot of light on the ecosystem

by _bxg1 8y ago

ilovecaching 8y ago

It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs. A lot of my reasoning was criticizing the JVM itself, not Java. VM languages add unnecessary complexity in the post container world where ephemerality and kernel APIs (containers) can give the same advantages, although I think Kotlin and Clojure and remarkably good languages.

coldtea 8y ago
>It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers). From 1960 to today it remains niche in its pure form, even the most popular language following it fully (e.g. Clojure or similar) is still a niche language. We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles. And that's what modern JS, Java, C#, Rust, etc (even C++) give us. And since FP is a style, it can be followed quite effectively in almost any language -- as long as it has some basic features, which, as you observed, Java has added.
- ilovecaching 8y ago
  Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". There are many other styles of programming that are data oriented and are a better definition for Rust and some circles of Javascript than functional, but ergonomics of composition and partial application leads to something far short of FP. > We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles. Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone. > JS, Java, C#, Rust, etc (even C++) give us. Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.
  - iainmerrick 8y ago
    Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". No, I think they are using those terms correctly. In FP, “pure” means absolutely no side-effects. So if you add an FP-style library to an existing imperative language, that’s “impure”.
    - ilovecaching 8y ago
      That's not the context in which the word was used, but it's a fair point. I have worked professionally with Haskell, and while I am not good at it (my forte is Erlang which is what I would consider "close to functional"), other developers I have worked with were very good, and watching them code in non functional languages and listen to how they thought about solving problems is were I developed the idea that adding a few features doesn't make a language functional.
- willtim 8y ago
  > And since FP is a style, it can be followed quite effectively in almost any language. It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised. It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.
_bxg1 8y ago
> It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs. I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).

vorg 8y ago

> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too. I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.

_bxg1 8y ago
I wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.
spricket 8y ago
No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH. Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy
- zmmmmm 8y ago
  > doesn't share lost of the performance penalties of Groovy That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.
- olavgg 8y ago
  Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension
  - 8y ago

boksiora 8y ago

thank you for this comment. it brings a lot of light on the ecosystem