4 ms·

> Any FP developer should scream when seeing this It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell

> Any FP developer should scream when seeing this It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach, I don't see why we should listen to "any FP developer" criticisms. It's not that I have anything against FP - let's just admit that side-effect pure FP is a "futuretro" of today. A future that never was.

marginalia_nu 4y ago
I do think FP in Java is a bit of a mistake. Record types has done a lot more for the language than streams and lambdas. I initially liked the idea of adding functional paradigms to the language, when the dust has settled all it does is create a sort of nasty Cronenberg language with most the drawbacks of both paradigms and few of the benefits of either.
- thriftwy 4y ago
  I absolutely disagree. Lambdas has in many ways revolutionized Java and put it back on its feet. Java 8 has seen faster adoption than any other major Java version because of this. Compare it with Java 11 or indeed with absolute non-adoption of Java 14. Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support. Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so. The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).
  - bluejekyll 4y ago
    My issue with lambdas in Java is the complexity of types in defining interfaces that receive generic Functions as an argument. Really seems like a better definition could be used there, new language syntax possibly. On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.
    - joshlemer 4y ago
      Agreed. If the type of the lambda can be inferred, then they are great to work with. But if you want to define one upfront and use it later, having to spell out the type of it is almost prohibitively annoying (what do I need in this situation, is it a Function or a Consumer or Supplier or Bifunction or BiConsumer or BinaryOperator or Predicate or BiPredicate or IntUnaryOperator or ObjDoubleConsumer or LongToDoubleFunction or .........). Most of the time I'll just avoid it if I can. I think I"m the only one on my team who would ever create a local function rather than a private method, for instance. An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V>
      - marginalia_nu 4y ago
        > An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V> Record types does make that a lot easier. They aren't quite as ad-hoc as in other languages, but this: record Foo(int a, String b) {} is a lot less to type than static final class Foo { private final int a; private final String b; public final Foo(int a, String b) { this.a = a; this.b = b; } public int a() { return a; } public String b() { return b; } public int hashCode() { return Objects.hashCode(a, b); } public boolean equals(Object o) { if (o == null) return false; if (o == this) return true; if (o instanceof Foo f) { return a == f.a && Objects.equals(b, f.b); } return false; } public String toString() { return getClass().getSimpleName() + "[ a = " + a + ", " + "b = " + b + "]"; } }
  - kaba0 4y ago
    Modules system was a necessary evil: it’s Hyrum’s law with the back then slowed down development of the JVM — every observable behavior of the system was hardcoded against, so the JVM devs had to build a wall against the changing internals to have any chance of continuing the evolution of the platform. Libraries that use never-agreed upon functionality are the ones in the bad here.
    - thriftwy 4y ago
      > the ones in the bad here Never blame people who try to solve real problems with your stuff. Better get your ego out of their way.
  - samus 4y ago
    The modules system is not a blocker for migration at all. At this point, it is completely optional to enable it. What indeed caused breakage was the encapsulation effort that blocks unrestricted access to JVM internals, and that one was not even fully and forcibly turned on until Java 17.
    - thriftwy 4y ago
      Well it requires users of your code to put a half dozen extra JVM args just to get your code (such as Java-based database like Apache Ignite) to run. You can see how such features are not super popular to the extent of widespread non-adoption of Java 11 even 10 years after its release.
      - samus 4y ago
        Oracle offers extended support for JDK 8 until the end 2030, which is more than four years longer than for JDK 11. I'd say this is the more likely reason that Java 11 is not adopted more. Spending a few hours to fire up an application to figure out the right --add-opens call really does not seem like such a big imposition to me.
eckza 4y ago
> no industrial success Because FP is hard, and because it's easier to get 1000 Python monkeys to shit out half-baked garbage than it is to get 10 Haskell developers to agree on a set of blessed language extensions. But when you get it right, your shit stops chewing a hole in itself in prod, and you can sleep at night and leave Slack alerts off over the weekend. It's fine. Y'all can have your half-baked tire fires. "Industrial success" is a broken metric for "whether or not something is going to create real value for your product". We'll just keep shipping. And sleeping.
- democracy 4y ago
  The idea of our craft is to deliver value, not to find a new weird way to do the same thing. If dentists were programmers, the most expensive ones would be removing teeth via the rectum.
  - lelanthran 4y ago
    > The idea of our craft is to deliver value, not to find a new weird way to do the same thing. If dentists were programmers, the most expensive ones would be removing teeth via the rectum. What a nice quote this will make :-) PM me the name of who I should attribute this too.
- d-trieu 4y ago
  > We'll just keep shipping. And sleeping. When do you actually ship though?
- DFHippie 4y ago
  I just want to stop for a moment and admire some of your metaphor pileups: > monkeys to shit out half-baked garbage > your shit stops chewing a hole in itself > half-baked tire fires Awesome. Terrifying, but awesome.
- kaba0 4y ago
  What happens when your service scales and you get a performance bottleneck? Can you.. connect to a prod instance and look at the number of allocated instances? Can you do VM-event streams with barely any overhead continuously in prod? Will you actually be able to circumvent the performance bug? Don’t get me wrong, I like Haskell and it is a more than fine language. Nonetheless, it doesn’t have anywhere close to the tooling Java has, and lazyness/FP is quite unintuitive regarding performance. And pure FP in itself is not guaranteed to result in better results by any form of evidence we have today, and doesn’t defend against logic bugs in any shape or form over what Java can do. Also, it’s very unprofessional to look down on software engineers using different languages then you do..
TuringTest 4y ago
> It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach You kidding? The industrial success of the pure FP approach inspired by Haskell is that it has dragged all the other significant languages and frameworks to work in a more functional way, adding the constructs they lacked and popularizing the basic techniques.
- KptMarchewa 4y ago
  Not "industrial success" because there were none, but rather a validity of some of the ideas. Which were successful only when adopted by some other languages, like Scala (which has a lot of issues on it's own), Kotlin or Rust.
  - TuringTest 4y ago
    Influencing a whole language of other industry languages to be closer to your model, that's what I would call industrial success for a radical experimental language dedicated to inventing and exploiting a new programming paradigm. Different criteria, I suppose.

marginalia_nu 4y ago

I do think FP in Java is a bit of a mistake. Record types has done a lot more for the language than streams and lambdas. I initially liked the idea of adding functional paradigms to the language, when the dust has settled all it does is create a sort of nasty Cronenberg language with most the drawbacks of both paradigms and few of the benefits of either.

thriftwy 4y ago
I absolutely disagree. Lambdas has in many ways revolutionized Java and put it back on its feet. Java 8 has seen faster adoption than any other major Java version because of this. Compare it with Java 11 or indeed with absolute non-adoption of Java 14. Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support. Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so. The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).
- bluejekyll 4y ago
  My issue with lambdas in Java is the complexity of types in defining interfaces that receive generic Functions as an argument. Really seems like a better definition could be used there, new language syntax possibly. On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.
  - joshlemer 4y ago
    Agreed. If the type of the lambda can be inferred, then they are great to work with. But if you want to define one upfront and use it later, having to spell out the type of it is almost prohibitively annoying (what do I need in this situation, is it a Function or a Consumer or Supplier or Bifunction or BiConsumer or BinaryOperator or Predicate or BiPredicate or IntUnaryOperator or ObjDoubleConsumer or LongToDoubleFunction or .........). Most of the time I'll just avoid it if I can. I think I"m the only one on my team who would ever create a local function rather than a private method, for instance. An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V>
    - marginalia_nu 4y ago
      > An other thing is java's lack of tuples. All the time I'm reaching for some kind of ad-hoc grouping/touple but have to resort to using something from Apache or Spring or (perhaps abusing) Map.Entry<K,V> Record types does make that a lot easier. They aren't quite as ad-hoc as in other languages, but this: record Foo(int a, String b) {} is a lot less to type than static final class Foo { private final int a; private final String b; public final Foo(int a, String b) { this.a = a; this.b = b; } public int a() { return a; } public String b() { return b; } public int hashCode() { return Objects.hashCode(a, b); } public boolean equals(Object o) { if (o == null) return false; if (o == this) return true; if (o instanceof Foo f) { return a == f.a && Objects.equals(b, f.b); } return false; } public String toString() { return getClass().getSimpleName() + "[ a = " + a + ", " + "b = " + b + "]"; } }
- kaba0 4y ago
  Modules system was a necessary evil: it’s Hyrum’s law with the back then slowed down development of the JVM — every observable behavior of the system was hardcoded against, so the JVM devs had to build a wall against the changing internals to have any chance of continuing the evolution of the platform. Libraries that use never-agreed upon functionality are the ones in the bad here.
  - thriftwy 4y ago
    > the ones in the bad here Never blame people who try to solve real problems with your stuff. Better get your ego out of their way.
- samus 4y ago
  The modules system is not a blocker for migration at all. At this point, it is completely optional to enable it. What indeed caused breakage was the encapsulation effort that blocks unrestricted access to JVM internals, and that one was not even fully and forcibly turned on until Java 17.
  - thriftwy 4y ago
    Well it requires users of your code to put a half dozen extra JVM args just to get your code (such as Java-based database like Apache Ignite) to run. You can see how such features are not super popular to the extent of widespread non-adoption of Java 11 even 10 years after its release.
    - samus 4y ago
      Oracle offers extended support for JDK 8 until the end 2030, which is more than four years longer than for JDK 11. I'd say this is the more likely reason that Java 11 is not adopted more. Spending a few hours to fire up an application to figure out the right --add-opens call really does not seem like such a big imposition to me.

eckza 4y ago

> no industrial success Because FP is hard, and because it's easier to get 1000 Python monkeys to shit out half-baked garbage than it is to get 10 Haskell developers to agree on a set of blessed language extensions. But when you get it right, your shit stops chewing a hole in itself in prod, and you can sleep at night and leave Slack alerts off over the weekend. It's fine. Y'all can have your half-baked tire fires. "Industrial success" is a broken metric for "whether or not something is going to create real value for your product". We'll just keep shipping. And sleeping.

democracy 4y ago
The idea of our craft is to deliver value, not to find a new weird way to do the same thing. If dentists were programmers, the most expensive ones would be removing teeth via the rectum.
- lelanthran 4y ago
  > The idea of our craft is to deliver value, not to find a new weird way to do the same thing. If dentists were programmers, the most expensive ones would be removing teeth via the rectum. What a nice quote this will make :-) PM me the name of who I should attribute this too.
d-trieu 4y ago
> We'll just keep shipping. And sleeping. When do you actually ship though?
DFHippie 4y ago
I just want to stop for a moment and admire some of your metaphor pileups: > monkeys to shit out half-baked garbage > your shit stops chewing a hole in itself > half-baked tire fires Awesome. Terrifying, but awesome.
kaba0 4y ago
What happens when your service scales and you get a performance bottleneck? Can you.. connect to a prod instance and look at the number of allocated instances? Can you do VM-event streams with barely any overhead continuously in prod? Will you actually be able to circumvent the performance bug? Don’t get me wrong, I like Haskell and it is a more than fine language. Nonetheless, it doesn’t have anywhere close to the tooling Java has, and lazyness/FP is quite unintuitive regarding performance. And pure FP in itself is not guaranteed to result in better results by any form of evidence we have today, and doesn’t defend against logic bugs in any shape or form over what Java can do. Also, it’s very unprofessional to look down on software engineers using different languages then you do..

TuringTest 4y ago

> It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach You kidding? The industrial success of the pure FP approach inspired by Haskell is that it has dragged all the other significant languages and frameworks to work in a more functional way, adding the constructs they lacked and popularizing the basic techniques.

KptMarchewa 4y ago
Not "industrial success" because there were none, but rather a validity of some of the ideas. Which were successful only when adopted by some other languages, like Scala (which has a lot of issues on it's own), Kotlin or Rust.
- TuringTest 4y ago
  Influencing a whole language of other industry languages to be closer to your model, that's what I would call industrial success for a radical experimental language dedicated to inventing and exploiting a new programming paradigm. Different criteria, I suppose.