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"

[davester666]

Isn't step 3 basically "scala is old. let's make a new cool language instead."?

Re:"Guyth"

[smittyoneeach]

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

Or you could just switch to Ocaml Java

[w1z7ard]

http://www.ocamljava.org/

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

[Karganeth]

>Granted I'm not a language expert/theorist, but most of us that code for a living aren't. What exactly do you mean by this?

Re:Simple is good

[Anonymous Coward]

I have the same problems as you with Scala. Add to that constantly changing libraries and it is a no go for me in projects.
Kotlin looks more interesting.

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

Re:Simple is good

[Anonymous Coward]

I second that!

Coming from 12 years of Java and using Scala for around 1.5 years and following exactly same guidelines and using Akka to do my PhD research,,, life is heaven with Scala.

Re:Simple is good

[plopez]

Simpler Java + closures==Groovy

Re:Simple is good

[phantomfive]

the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative.

Professor Odersky may well be a language expert (though IMO he lacks the in-the-trenches experience of a typical programmer), but with this sentence, being unaware that mixing OO and Functional is common, you showed you are decidedly not a language expert, and also that you hardly know anything about various programming languages.

It's ok, most people don't.

Re:Simple is good

[heironymous]

Groovy is not really very simple. But more importantly, it's not a simpler Java at all. Since Groovy is dynamic and Java is static, they are completely different languages that bear a superficial syntactic similarity.

Re:Simple is good

[heironymous]

phantomfive, You have responded with a bit of vitriol that surprises me.

Can you please cite other examples of mainstream statically typed languages that are both OO and Functional? I ask this not to insist that no others exist, but rather to further engage you, and try to understand where you are coming from.

Re:Simple is good

[phantomfive]

Lisp, for example

Re:Simple is good

[ljw1004]

OCaml. JavaScript.

Re:Simple is good

[corporate zombie]

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

First all the unicode operators of scalaz have names as well. Second, just what language is the functional library scalaz written in? I'll bet *that* would be a pretty good functional language to work with.

Re:Simple is good

[heironymous]

Thanks for replying, phantomfive. Obviously I did not express my question clearly enough.

Lisp is not statically typed, and it's therefore a very different sort of language than Scala. There are interesting dialects like Racket, which allows you to "turn on" some type checking, and like Qi, which I didn't previously think of as an OO language. At least, you have given me something to think about.

ljw1004, Javascript is not statically typed. But, your suggestion of OCaml is a thoughtful one. I am not aware of how well a feature like Type Classes fits into the language. My suspicion is that they are more cumbersome than in Haskell or Scala, but it's an interesting thing to explore.

Re:Simple is good

[In-HoYi]

I'm with you on this point. I generally won't find a team already using Scala. They are out there, but very rare. In most cases, you would be in a JVM shop, and have to convince your team mates that Scala is a good fit for such and such reasons. Well, language features like implicit casting and variables make it a very hard sell, to say the code that we are producing is maintainable. Because it surprises Java programmers see things suddenly works because you have imported a package.

Re:Simple is good

[Xest]

C#? F#? It depends what blend of OO and functional you really want.

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:Would be nice to see Scala replace Java

[phantomfive]

. I've had to fix a ton of Java bugs which happened because someone accidentally used '==' when they meant to use 'equals'.

How did that code even get committed? That sort of thing is easy enough to test.

Re:Would be nice to see Scala replace Java

[bradley13]

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

Re:Would be nice to see Scala replace Java

[bradley13]

See my answer above. This is true only when doing very basic programming. As soon as you start working abstractly, creating code that works with arbitrary classes, life is no longer so simple.

Re: Would be nice to see Scala replace Java

[peppepz]

No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and it "works" with compiler-generated structures in the same way as comparing C strings with == instead of strcmp() may happen to "work", or comparing C arrays using > may happen to "work". The difference between a value and a reference is a very basic concept of programming, and in the case of Java it's explained very early in learning courses. If anything, languages that allow complexity-hiding features such as the overloading of == are much better puzzler-generators than the simple, elegant, plain Java. Which didn't even have autoboxing originally.

Re:Would be nice to see Scala replace Java

[gweihir]

Good example. The core problem is that Java was never indented as a mainstream language, but for embedded programming. In embedded systems, trade-offs like the ones you describe make sense and programmers for embedded systems understand them. In a general-purpose language, they are insane and a reason that Java should never have become popular. The whole inheritance model is deeply broken as well and basically prevents general teaching of the concepts and ideas, because Java is a jumble of special cases. Unfortunately, people are generally stupid and generally do not look at problems and merits of a "new" technology before becoming infatuated with it. Java is almost exclusively used in places where it has no business being used.

Re:Would be nice to see Scala replace Java

[heironymous]

I think you misunderstood what bradley13 wrote. Java pre-constructs the low valued Integer objects, so that == and .equals will always return the same answer. But for larger values, they don't. This is entirely independent of autoboxing.

Re:Would be nice to see Scala replace Java

[heironymous]

Perhaps, but why should there even be an == operator for objects? This is not a flippant question, but a deep language design question. It may be the case that Java's decision to expose == introduced too much opportunity to get things wrong. It's possible to imagine a more robust language without such an operator. Just as it is possible to imagine one without null, which would surely be better.

Re:Would be nice to see Scala replace Java

[heironymous]

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.

You are correct. I believe that the Pizza language, which became Java generics in the Tiger release, was designed by Martin Odersky. Type erasure in Tiger was deemed necessary for backwards compatibility with Java 1.4 code.

And consequently, Scala has type erasure for interoperability with Java. IIRC, James Gosling wanted many features like generics in Java, but couldn't get them into the language without slipping Java's release date. It's sad that a modern language like Scala still suffers from this twenty year old decision.

However, Scala also has Manifests, which address some of the weaknesses imposed by type erasure. It's good to shake the dust from our sandals.

Re:Would be nice to see Scala replace Java

[heironymous]

I am certainly an advocate of lifelong developer training and code reviews. But consider this. If a language permits these sorts of == vs equals errors, then perhaps that's a defect in the language design itself.

Re: Would be nice to see Scala replace Java

[flargleblarg]

No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and ...

Oh my god. Excuse me, but you are so very wrong. Yes, it DOES work and is a GOOD THING to compare references sometimes. For example, if you are implementing your own general hash-based collection class, you will find that your lookup code runs significantly faster if you first compare object references for equality before comparing the object's hash followed by comparing the objects themselves for equality. That is to say: (1) First compare object references using ==. If equal, you're done immediately because your key matches, and you can go fetch the object associated with the key. If not equal, proceed to next step. (2) Next, compare object hashes using ==. If not equal, you have a mismatch and you look at the next key/value pair, if present in the bucket or linear addressing cycle; if equal, proceed to next step. (3) Finally, assuming you get this far, compare contents of objects. If equal, then you have a key match; if not equal, you have a mistmach and you either continue for the next key or fail with no object found.

So you see, sometimes is makes perfectly good sense to compare object pointers. Comparing references instead of values is NOT logically wrong — as long as you use the comparison as an early-out test before performing the more expensive actual comparison of value. Hope that clears things up.

Re:Would be nice to see Scala replace Java

[flargleblarg]

The core problem is that Java was never indented as a mainstream language, but for embedded programming.

s/never/not originally/

FTFY

Re: Would be nice to see Scala replace Java

[peppepz]

Please read the post I was replying to, it was claiming that checking for object value equality using == sometimes works. That's what doesn't work, and rightfully so. Sorry if it wasn't clear, but unfortunately I'm using the mobile site and I can't find the "quote parent" option.

Re: Would be nice to see Scala replace Java

[peppepz]

It's needed, among other things, to write basic code such as if (source == cancelButton) { ... }

Re: Would be nice to see Scala replace Java

[flargleblarg]

Ok, cool... Ya, after I posted that and re-read it, I thought to myself, "I wonder if he was referring only to Integer, in which case I'm going to feel like an a-hole for being so harsh." Apologies if I came across as harsh.

Question... what did you mean by "For any kind of object" then?

Re:Would be nice to see Scala replace Java

[pjt33]

I'm not quite sure whether your question is "Why allow reference comparisons?" or "Why use == for reference comparisons?" If it's the former: if you look at equals(Object o) implementations, a lot of them begin with if (this == o) return true; It can be a major performance boost in some situations.

Re:Would be nice to see Scala replace Java

[gweihir]

"Never" as in "Not before the design was mostly fixed". This makes my statement correct. Of course intentions can be changed without changing the design, but that is meaningless.

Re: Would be nice to see Scala replace Java

[peppepz]

That there is no inconsistence in Java between classes for which supposedly you can get away with == and classes which require you to use equals(), as was suggested in the post I was replying to.

Re:Would be nice to see Scala replace Java

[Xest]

How is it a defect? The fact is that there are different types of equality in a classic OO language (value equality, type equality, reference equality). You've got to be able to denote these somehow, and if someone stupidly uses the wrong concept that's a training issue. Using .equals instead of == if that's what you meant is no different to using the wrong operator elsewhere, it's like using -- instead of ++, or % instead of ^. It's an intentional and sensible language design decision.

It's impossible to create a language whereby user error is eliminated from the equation without eliminating the user from the equation. Yes you can argue that you should switch to languages where references, and values and types don't exist as explicit concepts but then you end up with something like Javascript where implicit variable conversion creates mountains more user error and where the lack of ability to explicitly define reference or value type means you get all sorts of horrendous bugs relating to variable capture that can only be fixed with an ugly verbose poorly readable hack to force creation of a new scope to capture a value.

Re: Would be nice to see Scala replace Java

[flargleblarg]

I'm pretty sure, though, that even any class that requires you to use equals(), you can still use == as a fast-precheck. That is, a==b implies a.equals(b) for all objects a,b in all classes. The converse, of course, is not the case: a.equals(b) does not imply a==b. And the inverse is not true: a!=b does not imply !a.equals(b). But the contra-positive is true: !a.equals(b) does imply a!=b.

Re:Why attack Java like this?

[Anonymous Coward]

It does seem like an attack on Java. We ended-up going with Python for our dynamic customer-edited business rules engine because of the confusion Scala has caused for developers that would have typically before just used Groovy. By attacking Java with this fragmentation attack, real damage is being done to Java. I understand disliking Java, but investing so much of your life to destroy it, and indirectly us, just doesn't make sense.

I see a train wreck ahead!

[Anonymous Coward]

"But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity"

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.

Re:I see a train wreck ahead!

[pijokela]

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.

One of the links actually lists the changes they are thinking of. To me they all make sense and they won't change the language too much while making the life of the compiler easier - and the result more predictable to humans.

Let me know when you get that binary compatibility between versions of Scala figured out.

Just a few months ago I saw a project at work that could not migrate to Java 8 because some of the libraries in the project do not work with Java 8 libs. The problem is that the lib in question wants to do bytecode enhancement and fails with the new lib format. Scala is more complex, no question about it, but I don't need aspects or bytecode enhancement or reflection and all that reduces complexity quite nicely.

Re:I see a train wreck ahead!

[heironymous]

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.

Actually, no. It's not about modifying the syntax. It's about bringing some very exciting ideas from research into Dependent Object Types into a mainstream language.

Re:I see a train wreck ahead!

[pijokela]

Yes, in scala there are binary incompatibilities between major versions.

My reply was that with Java 8 and byte code enhancement there are binary incompatibilities in Java too. You cannot just avoid Scala to avoid binary incompatibility problems.

Scala is the Perl of compiled languages

[Anonymous Coward]

Seriously, it's very easy to write code that you yourself can't even understand the next day.

Re:Scala is the Perl of compiled languages

[gweihir]

Too much language flexibility and an inexperienced programmer can do that. A good programmer does not have that issue. I have given Perl and C code to students on many occasions to extend or modify it and never had any complaints.

Re:Why attack Java like this?

[shoor]

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.

Scalar is popular?

[gweihir]

In The press, maybe. In actual use, it seems rather doubtful.

Re:Scalar is popular?

[heironymous]

It depends on what we mean by "popular". If popular means that more lines of Scala are being written than Java, then, no, Scala is not popular.

But if we mean that the Scala programmers are in demand, then yes, Scala is popular.

Re:Scalar is popular?

[gweihir]

The second definition is problematic, as, for example, Cobol programmers are still in demand.

Re:Scalar is popular?

[Xest]

"But if we mean that the Scala programmers are in demand, then yes, Scala is popular."

No it doesn't, because popularity sits on a spectrum, and the level of demand for Scala programmers is at least an order of magnitude lower than for Java, C#, C++, Python, Javascript, and PHP developers for example. Popular would imply Scala is high on the demand rankings, it's just not, not by any measure.

Re:"a fundamental rethink"

[gweihir]

Python 3 is fine. It is not a beginner's language anymore though, which may or may not be a defect in itself.

Yeah, Lisp is nice.

[heironymous]

Yes, dynamic languages like Clojure are nice, but so are static ones. I actually consider Scala a dialect of ML, much in the way that Ruby is a dialect of Smalltalk.

Re:Yeah, Lisp is nice.

[K. S. Kyosuke]

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.

Re:Yeah, Lisp is nice.

[heironymous]

You are correct of course, Anonymous Coward. Thinking of Ruby as a Smalltalk dialect is obviously more metaphorical than literal. And actually, Matz himself has remarked that he accepts the comparison of Ruby to Smalltalk as a compliment.

Re:Why attack Java like this?

[heironymous]

Java has changed many times, with careful thoughts to backwards compatibility at the source level. But it's a verbose beast, living in the uncanny valley between dynamic languages and languages with type inference. So, Java essentially has many of the hassles of static typing with few of the benefits.

There hasn't been as much Scala written as Java, and it may never catch up. But I'm sure that the Scalaists care about backwards compatibility, too. There's already too much Scala written for there not to be a "flap." But somehow I think even breaking changes in Scala will be tolerated if they make the language more pleasant. The research being done right now on dependent types is just too exciting.

Re:Scala is a joke

[heironymous]

No, I am quite certain that language designers respect Scala. Consider Peter Van Roy, for example, who is a leading expert on programming languages, and the co-author of a very influential book on programming paradigms. He highly recommends Scala.

Yes, compiler performance is an honest complaint from in-the-trenches Scala programmers, but that's a far cry from the "Scala is a joke" headline you use. If it were really a joke, then how could it continue to be used in the large scale applications of which you speak?

Re:Scala is a joke

[Anonymous Coward]

Yes, compiler performance is an honest complaint from in-the-trenches Scala programmers, but that's a far cry from the "Scala is a joke" headline you use. If it were really a joke, then how could it continue to be used in the large scale applications of which you speak?

I agree with you completely except your reasoning that using in big applications proves Scala. On the one hand you are right, and on the other, you can say the same thing about any programming language. You can write a huge scalable server in Qbasic if you really wanted to, but it does not mean you should.

Scala attracts/attracted people for a few reasons:

-Not Java, but kind of like Java with more sugar, still compiled, and some easy functional-style magic. Really by simply not being Java but on the JVM, this makes tons of people use it in the real world. Sometimes just comfort, other times to tick internal requirements.

-Easy to understand if you get Java and some bits of functional languages. Very easy if you're coming to the JVM from C#.

-Concurrent programming seemingly made easy, with some cool options thrown in like Actors

-Functional programming. I'd argue this is where the language fails miserably, but that's another discussion.

-Easy to make your own DSLs. Causes the write-only code quite often mentioned in other posts.

Re:Scala is a joke

[heironymous]

Insightfully said, Anonymous Coward.

Re:Scala is a joke

[heironymous]

Thanks for the link.