Comment by reality_czech | Hacker News Reader

Comment by reality_czech | Hacker News Reader

Parent Full thread

> The problem with traditional operator overloading is that you have to > memorize which symbol corresponds to which magic method name.

That's not even in the top 5 problems with operator overloading.

> How many years or decades will those "formalities" take? Java language > enhancements have a history of taking much longer than originally claimed.

Almost certainly a shorter amount of time than it would take to migrate our codebase away from Java. Oracle has actually been moving pretty fast with Java recently, for better or worse.

> [XML is...] Already moved into an optional library, being dropped entirely in > the next version.

And this illustrates another problem: Scala is constantly breaking backwards compatibility. Which is a real-world problem, unlike "I want the latest gee-whiz language feature."

> Put that together and you get a language where you never need the magical > frameworks that (real-world) Java needs.

Scala has plenty of "magical frameworks": scalaz, akka, shapeless, the list goes on.

Newer Java libraries like Jackson don't need a type registry (or at least, not one that have to manually set up.)

I won't try to defend J2EE or Hibernate, but also, I don't use them.

> That's not even in the top 5 problems with operator overloading.

What other problem is there? Some libraries define functions with stupid names and that's a problem, but it's a problem you have without operator overloading too.

> Almost certainly a shorter amount of time than it would take to migrate our codebase away from Java.

I rather doubt that; a typical codebase has a half-life of what, 5 years? Which is less time than many of the Java features you listed have been delayed for.

> And this illustrates another problem: Scala is constantly breaking backwards compatibility.

Hardly. One major compatibility break in the language's entire history, eight years ago; removal of XML literals will be part of the second, and is only happening after they've been a) universally agreed to be a bad idea and b) deprecated for four years and counting. Yes it's not quite the extreme levels of backwards compatibility that Java offers, but it compares favourably with most languages out there.

> Scala has plenty of "magical frameworks": scalaz, akka, shapeless, the list goes on.

Maybe some parts of akka (I don't use it), but certainly not scalaz or shapeless: they're libraries, not frameworks, and there's no magic (no reflection, annotations or anything like that, aside from the one macro I mentioned), just ordinary values and ordinary functions that you call in the ordinary way (even the macro behaves like one).

> Newer Java libraries like Jackson don't need a type registry (or at least, not one that have to manually set up.)

Jackson is the example I was thinking of actually, it absolutely does have a (magic, reflection-based) registry that controls how things get serialised. See e.g. https://github.com/FasterXML/jackson-datatype-joda#registeri... .

Reply on news.ycombinator.com