4 ms·

A fairly low quality article, imho. The points listed could almost as easily apply to Java or C#

by platz 5y ago

bachmeier 5y ago
> You don’t mutate by default. > makes illegal states unrepresentable Maybe recent versions of Java are different, but I don't recall either of those statements applying when I used Java.
- odyssey7 5y ago
  The whole idea of OOP is you have mutable data coupled with the methods that mutate it.
  - cryptonector 5y ago
    You can do immutable data structures with OOP. The problem is that you can also do mutation.
    - zdragnar 5y ago
      Compilers / runtimes for most OOP languages don't really put the same level of optimization into operations with immutable structures as they do with mutable ones, because the mutable paradigm is largely how the languages are (intended to be) used. There are exceptions, of course, but you are leaving a lot on the table when you try to shoehorn one into the other.
- twic 5y ago
  Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade. See item 13, "Favor immutability", in Effective Java, the bible of Java programming, published in 2001: https://www.pascal-man.com/navigation/faq-java-browser/java-concurrent/Effective_Java.pdf https://www.pascal-man.com/navigation/faq-java-browser/java-... I can't find a concrete citation for "makes illegal states unrepresentable" (does anyone know the history of this phrase?), but it was certainly part of conversations i was having in 2012.
  - bachmeier 5y ago
    > Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade. "You can do that" and "enforced by the compiler by default" are pretty different.
  - marshray 5y ago
    "Make illegal states unrepresentable" is usually attributed to Yaron Minsky of Jane Street. This video shows it at 28:02. https://blog.janestreet.com/effective-ml-video/ https://blog.janestreet.com/effective-ml-video/ https://www.youtube.com/watch?v=-J8YyfrSwTk https://www.youtube.com/watch?v=-J8YyfrSwTk
cryptonector 5y ago
The points listed cannot "as easily apply to Java", and, really, not to C# either. You really need a functional language to meet the "requirements" listed, which are -from TFA, almost at the top-: > Why? Three reasons: > Functions in the mathematical sense. > > No statements, no instructions, just expressions that don’t ever mutate. Everything returns something. You don’t mutate by default. > Type-driven programming. > > Start thinking generally, in broad concepts, about what kinds of info you’re dealing with – the inputs, the outputs, the steps – and then work down to implementation. Start in the center w/ a little implementation and work your way out. Haskell makes illegal states unrepresentable. > > You can't do the wrong thing with this data because this data can’t handle that, it just doesn’t accept that kind of thing.
dgb23 5y ago
Is this the "you can write this in X by implementing a compiler for Y"-joke? Or genuine? If so, I find it unfair. Even at the most fundamental level, the mishmash of statement/expression syntax in those languages makes it cumbersome at best to compose functions and expressions in the style of an FP language. And the more you venture into conceptual things like values and functions you're fighting those languages left and right to achieve the same _basic_ semantics. I'm neither pro nor contra static typing in general and I don't really know Haskell, but I think it would be obvious that Java and C# don't have the same sophistication, inference and expressiveness on the type level as Haskell. When they say "make illegal states unrepresentable" they don't mean "write a bunch of defensive runtime checks". Not to bash on Java/C#, they are powerful and very useful. But the type of specific benefits the article talks about are not a given or even practical in those.
- gavinray 5y ago
  I used to think that same thing I recently found a very smart fellow who has been writing translations of a small Scala "expression interpreter" with monads and what. But in Java. I kid you not. He wrote it in JDK 8 Java (pretty far from Scala) Then updated with JDK 15 features Java (getting closer) I made a rough pass at JDK17 Java using records and ADTs (sealed types) with pattern match "switch" and the net result is an almost verbatim translation. https://github.com/Randgalt/expressive-java/issues/1 https://github.com/Randgalt/expressive-java/issues/1 There is one ugly line which JDK18 will fix, "destructuring in pattern captures/match". See "Deconstruction Patterns" at bottom of page here: https://openjdk.java.net/jeps/405 https://openjdk.java.net/jeps/405
  - zactato 5y ago
    I don't think that JEP is part of JDK18 yet.

A fairly low quality article, imho. The points listed could almost as easily apply to Java or C#

by platz 5y ago

A fairly low quality article, imho. The points listed could almost as easily apply to Java or C#

> You don’t mutate by default. > makes illegal states unrepresentable Maybe recent versions of Java are different, but I don't recall either of those statements applying when I used Java.

odyssey7 5y ago
The whole idea of OOP is you have mutable data coupled with the methods that mutate it.
- cryptonector 5y ago
  You can do immutable data structures with OOP. The problem is that you can also do mutation.
  - zdragnar 5y ago
    Compilers / runtimes for most OOP languages don't really put the same level of optimization into operations with immutable structures as they do with mutable ones, because the mutable paradigm is largely how the languages are (intended to be) used. There are exceptions, of course, but you are leaving a lot on the table when you try to shoehorn one into the other.
twic 5y ago
Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade. See item 13, "Favor immutability", in Effective Java, the bible of Java programming, published in 2001: https://www.pascal-man.com/navigation/faq-java-browser/java-concurrent/Effective_Java.pdf https://www.pascal-man.com/navigation/faq-java-browser/java-... I can't find a concrete citation for "makes illegal states unrepresentable" (does anyone know the history of this phrase?), but it was certainly part of conversations i was having in 2012.
- bachmeier 5y ago
  > Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade. "You can do that" and "enforced by the compiler by default" are pretty different.
- marshray 5y ago
  "Make illegal states unrepresentable" is usually attributed to Yaron Minsky of Jane Street. This video shows it at 28:02. https://blog.janestreet.com/effective-ml-video/ https://blog.janestreet.com/effective-ml-video/ https://www.youtube.com/watch?v=-J8YyfrSwTk https://www.youtube.com/watch?v=-J8YyfrSwTk

cryptonector 5y ago

The points listed cannot "as easily apply to Java", and, really, not to C# either. You really need a functional language to meet the "requirements" listed, which are -from TFA, almost at the top-: > Why? Three reasons: > Functions in the mathematical sense. > > No statements, no instructions, just expressions that don’t ever mutate. Everything returns something. You don’t mutate by default. > Type-driven programming. > > Start thinking generally, in broad concepts, about what kinds of info you’re dealing with – the inputs, the outputs, the steps – and then work down to implementation. Start in the center w/ a little implementation and work your way out. Haskell makes illegal states unrepresentable. > > You can't do the wrong thing with this data because this data can’t handle that, it just doesn’t accept that kind of thing.

dgb23 5y ago

Is this the "you can write this in X by implementing a compiler for Y"-joke? Or genuine? If so, I find it unfair. Even at the most fundamental level, the mishmash of statement/expression syntax in those languages makes it cumbersome at best to compose functions and expressions in the style of an FP language. And the more you venture into conceptual things like values and functions you're fighting those languages left and right to achieve the same _basic_ semantics. I'm neither pro nor contra static typing in general and I don't really know Haskell, but I think it would be obvious that Java and C# don't have the same sophistication, inference and expressiveness on the type level as Haskell. When they say "make illegal states unrepresentable" they don't mean "write a bunch of defensive runtime checks". Not to bash on Java/C#, they are powerful and very useful. But the type of specific benefits the article talks about are not a given or even practical in those.

gavinray 5y ago
I used to think that same thing I recently found a very smart fellow who has been writing translations of a small Scala "expression interpreter" with monads and what. But in Java. I kid you not. He wrote it in JDK 8 Java (pretty far from Scala) Then updated with JDK 15 features Java (getting closer) I made a rough pass at JDK17 Java using records and ADTs (sealed types) with pattern match "switch" and the net result is an almost verbatim translation. https://github.com/Randgalt/expressive-java/issues/1 https://github.com/Randgalt/expressive-java/issues/1 There is one ugly line which JDK18 will fix, "destructuring in pattern captures/match". See "Deconstruction Patterns" at bottom of page here: https://openjdk.java.net/jeps/405 https://openjdk.java.net/jeps/405
- zactato 5y ago
  I don't think that JEP is part of JDK18 yet.