Scala Designer Martin Odersky On Next Steps 94
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.
"Guyth" (Score:3, Funny)
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: (Score:1)
Isn't step 3 basically "scala is old. let's make a new cool language instead."?
Re: (Score:3, Insightful)
Yeah, Lisp is nice. (Score:1)
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: (Score:3)
Re: (Score:1)
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.
Or you could just switch to Ocaml Java (Score:1)
Simple is good (Score:5, Insightful)
Re: (Score:2)
Re: (Score:1, Informative)
>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 difficul
Re: (Score:1)
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: (Score:1)
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 (Score:4, Interesting)
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: (Score:1)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:1)
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: (Score:2)
Re: (Score:2)
OCaml. JavaScript.
Re: (Score:1)
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 awar
Re: (Score:2)
C#? F#? It depends what blend of OO and functional you really want.
Re: (Score:2)
Simpler Java + closures==Groovy
Re: (Score:1)
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: (Score:1)
Would be nice to see Scala replace Java (Score:2, Informative)
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 == .equals()
- Comparing two Integer variables, you probably want
- 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 generi
Re:Would be nice to see Scala replace Java (Score:5, Informative)
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: (Score:2, Informative)
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: (Score:2)
. 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: (Score:2)
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: (Score:3)
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
Re: (Score:1)
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 (Score:1)
Re: (Score:2)
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 (Score:1)
Re: (Score:2)
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 becau
Re: Would be nice to see Scala replace Java (Score:1)
Re: (Score:2)
Question... what did you mean by "For any kind of object" then?
Re: Would be nice to see Scala replace Java (Score:1)
Re: (Score:2)
Re: (Score:1)
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: (Score:2)
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 cr
Re: (Score:1)
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: (Score:1)
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
Re: (Score:2)
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. Un
Re: (Score:2)
The core problem is that Java was never indented as a mainstream language, but for embedded programming.
s/never/not originally/
FTFY
Re: (Score:2)
"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: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:1)
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
I see a train wreck ahead! (Score:2, Interesting)
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 t
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:1)
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.
Scala is the Perl of compiled languages (Score:1)
Seriously, it's very easy to write code that you yourself can't even understand the next day.
Re: (Score:2)
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: (Score:2)
Python 3 is fine. It is not a beginner's language anymore though, which may or may not be a defect in itself.
Scalar is popular? (Score:3)
In The press, maybe. In actual use, it seems rather doubtful.
Re: (Score:1)
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 yo
Re: (Score:1)
Thanks for the link.
Re: (Score:1)
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, thi
Re: (Score:1)
Insightfully said, Anonymous Coward.
Re: (Score:1)
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: (Score:2)
The second definition is problematic, as, for example, Cobol programmers are still in demand.
Re: (Score:2)
"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.