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

"Guyth"

[smittyoneeach]

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?"

Re:"Guyth"

[smittyoneeach]

They won't rest until they've figure out how to run Haskell on a JVM.

Simple is good

[djbckr]

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.

Re:Simple is good

[pijokela]

I've been using scala for two years now and I think there is a simple trick to avoiding the problems you mention:

1. Many of the language features are best left to library designers so that application code is easy to understand. This is not a problem unless you make it one.
2. Carefully choose what libraries to use. Specifically avoid using all the esoteric stuff in github. Especially if the library is very "functional" and has lots of "operators". Just don't use them. Using Play and Akka and the stuff that typesafe uses I haven't really had too much trouble with migrations or code that is impossible to understand.

And, coming from 10 years of Java, I am loving Scala development. :-)

Re:Simple is good

[phantomfive]

Granted I'm not a language expert/theorist,

Most people who design languages aren't either. It's a big elephant, and most language designers only see one side. There are the functional guys (like the Haskell designers) who see that immutability reduces bugs, but they don't see the benefits of object oriented programming the way Bertrand Meyer does. But Bertrand Meyer doesn't understand the benefits of run-time type binding, the way Alan Kay does. Alan Kay has a good understanding of message passing, but is an eternal academic.

Most programming language innovations are syntactic sugar, merely changing the way we write things. It's rare that a new language idea comes along that actually makes a difference.

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.