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.
But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity.
"Guyth. Let uth dump all the thyntaxth exthept the parens, and put the left one before the thymbol name."
"Hey, man: what's with the sudden lisp?"
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.
This isn't even taking into consideration the forking of syntax between Typesafe's Scala and Typelevel's Scala.
I find it amusing when other JVM languages bash Java's baggage while they are young, but then they too get old and find out they created a bunch of baggage themselves. Let me know when you get that binary compatibility between versions of Scala figured out.
Isn't Python supposed to have suffered from a big revision change? My first thought, when I read about Dr Odersky making revisions is that he would be running into the same problem that Python did. Maybe Scala isn't as widely adopted yet as Pascal was, and he thinks he should fix it now before there would be too big of a flap over it. (Actually, if they're changing Java as I gather they are from the interview, wouldn't that also be a blowback for Java?)
I'm an old timer who has never used any of these new-fangled languages professionally (where new-fangled is anything newer then C), so I'm not trying to editorialize here, just wondering.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Exactly. It's been a while, but I remember tracking down one bug in a framework that managed other classes. The developer had assumed that all objects were, in fact, different objects. However, with Strings, Java used its cute little cache. In the framework this meant that two objects that should have been different had the same reference (== was true), which led to problems. The details escape me - it's been a while - but tracking this down was not trivial.
It's all well-and-good to say that you should only ever look at the object values and not care about the memory references. However, anyone writing any sort of framework-level code will, in fact, be working with object references. With your own classes, of course, it's no problem. But Java's simple classes (Integer and String certainly, not sure about others) violate the semantics of object management. Worse, it is inconsistent, since it depends on the specific value of the objects (which the language itself should never look at).
As the parent post so aptly put it: this is "the bash-your-head-on-the-table level of stupid design".
Enjoy life! This is not a dress rehearsal.
In The press, maybe. In actual use, it seems rather doubtful.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Technically, with Lisp being a metalanguage and more of an idea than a single artifact (unless we're talking about Common Lisp), building a statically typed language on top of it isn't exactly inconceivable.
Ezekiel 23:20