Hacker News Reader

Comment by platz | Hacker News Reader

A fairly low quality article, imho.

The points listed could almost as easily apply to Java or C#

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.

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

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

I don't think that JEP is part of JDK18 yet.

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.

> 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.

The whole idea of OOP is you have mutable data coupled with the methods that mutate it.

You can do immutable data structures with OOP. The problem is that you can also do mutation.

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.

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-...

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.

> 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.

"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://www.youtube.com/watch?v=-J8YyfrSwTk

Reply on news.ycombinator.com