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.

Comments

Would be nice to see Scala replace Java

[bradley13]

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()
- But it is possible to have two different Integer objects with the same value - this is when you wand ==
- But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127

That's one example, but there are lots more. 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...

Re:Would be nice to see Scala replace Java

[peppepz]

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.

Re:Would be nice to see Scala replace Java

[0123456]

Comparing *any* object, you want to use equals(), there's no "probably".

Except small Integer objects are usually cached, so == works. Except if someone manually created a new one.

This is one of the most retarded things about Java. Certain types work with == and certain instances of certain types work with ==, and others don't. I've had to fix a ton of Java bugs which happened because someone accidentally used '==' when they meant to use 'equals'. It really is at the bash-your-head-on-the-table level of stupid design.

Re:Simple is good

[Anonymous Coward]

>What exactly do you mean by this?

That most of people who code for living are not a language experts or theorists. But still have opinions on language, simplicity, syntax etc. Isn't that pretty damn clear?

I think the grandparent was trying to be nice in the hope that the original parent had something more to add to the debate. If you want "simpler java with closures" them you would end up with Java 8 and you would still be in a programming nightmare. If you want to start seriously using functional programming then you need to have more support in the language than just closures. Use of higher order functions needs to be easy and idiomatic.

Probably the OP is suffering from second (major?) language difficulties. He's forgotten how much he had to look up when he learned Java, which is huge and messy, and anyway didn't notice it at the time, since it came incrementally. Now he's trying to program at the same level in Scala and has, of course, hit a bit of a barrier. The thing about a "language expert" is that they will have had to deal with many languages (otherwise they aren't actually experts) so they would be able to give actual valid criticism of scala.

Valid criticism of Scala: full functional programming requires ScalaZ which has nightmare stupid misfeatures like use of Unicode operators

Invalid criticism of scala: I had to spend an hour looking up some syntax (can be transformed to valid by explaining which syntax).

Anyway; Karganeth is completely right to ask. It may well be that my guess is wrong and the OP has something valid to add to the debate which he just hasn't expressed very well.