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