Slashdot Mirror
Scala Designer Martin Odersky On Next Steps
rfernand79 writes Infoworld has an interview with Martin Odersky, designer of Scala, in which they discuss the future of this popular language. Three versions are discussed as being part of the Scala roadmap: The first one (2.12) focuses on better integration with Java 8, and making use of the latest improvements in the JVM. The second one (Aida) focuses on cleaning up the Scala libraries. But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity.
I really like Scala, but I only use a small subset of all the crazy (and what I consider a bunch of superfluous) language features. Simpler Java with Closures is what is should be. Granted I'm not a language expert/theorist, but most of us that code for a living aren't. Trying to read some of the more esoteric features of Scala leaves me with "I thought it was supposed to make my life easier". When I have to spend an hour looking up syntax to describe what the code is doing - well, that doesn't work for me.
Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:
- Comparing two "int" variables, you use == - Comparing two Integer variables, you probably want .equals()
Comparing *any* object, you want to use equals(), there's no "probably".
- But it is possible to have two different Integer objects with the same value - this is when you wand ==
No, you don't. Comparing two Integer objects, as any other object, with ==, will compare the two references to the object in order to determine if they point to the same object. The object contents won't be looked at. This is simple to learn and teach, and elegant as a design. I find no ugliness whatsoever in this.
- But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127
Although you didn't mention it, you are thinking about autoboxing. Java makes efficient use of memory and, by using == to test object identity instead of equals() you can detect this optimization. This can't influence any working code (because comparing the results of .equals() and == makes no logical sense) and certainly isn't confusing.
A more advanced example are the generics that disappear when the code is compiled. I understand the arguments for doing it this way, but I disagree with them - if you have generics, you ought to be able to query the types at run-time. There are lots and lots of highly questionable design decisions - basically, 20 years of backwards compatibility.
It's past time to clean house. Building a new language on top of the established JVM technology seems like a very good idea indeed. Perhaps Scala can fulfill this role...
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.