3 ms·
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 mishm
by 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 agoI 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 agoI don't think that JEP is part of JDK18 yet.