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"

[Anonymous Coward]

But what's the fun in that? This way the new generation of language designers can kid themselves they do have something new and exciting to add.

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.

How about linking the word interview

[Anonymous Coward]

I had to check two wrong links to actually find the article. I guess my bad for wanting to rtfa.

Or you could just switch to Ocaml Java

[w1z7ard]

http://www.ocamljava.org/

Re:Or you could just switch to Ocaml Java

[Anonymous Coward]

http://www.ocamljava.org/

OK, let's try it.

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

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

Re:Simple is good

[Anonymous Coward]

One word: Kotlin. It's a better scala.

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

[heironymous]

Well said. Of course, Professor Odersky *is* a language expert/theorist, and Scala already makes a real difference. Its successors may well continue to do so.

What's so fascinating about Scala is that the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative. There's an orthogonality of Scala language features (something Stroustrup strove for in C++) that allows for some real surprises. For example, Implicits make Type Classes possible very elegantly. Scoped type classes turn out to be an emergent language feature, which didn't have to be baked into the compiler.

Re:Simple is good

[Anonymous Coward]

What's so fascinating about Scala is that the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative.

Like, say, Ruby did? 15 years ago? Fascinating.

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

[Anonymous Coward]

Like, say, Ruby did? 15 years ago? Fascinating.

On that definition Perl did it 20 years ago; functions have been first class objects there for years. Scala is doing lots more; there's a bunch of things around the type system which are really interesting. The fundamental of this is that OO programming implicitly assumes that there's "an object" which models something. This implies changing state. Functional programming assumes that no state changes and that variables are immutable. Calling a function from an object is easy. What's neat / difficult / interesting is how you handle object oriented / mutable things from inside a pretty purely functional / statically typed / immutable world.

Ruby has little new and valuable to say in this area. Scala does.

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

[Anonymous Coward]

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

"Nightmare stupid misfeatures"?
I think that's a pretty naive criticism of the language, to be honest with you.

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

[Anonymous Coward]

First all the unicode operators of scalaz have names as well.

Before I continue, I should note that ScalaZ is not a part of the core language and isn't really recommended by Odersky himself (I don't think he's against it either, it's just not where he would start from).

The problem with the operators is not that I might have to use them. The problem is that someone else can use them. Once you open up the Unicode can of worms there are many different characters which may look the same. At the simple level this is confusing - ScalaZ uses a symbol very like the + symbol for a different reason - but that's just the beginning. If a malicious programmer is trying to sneak something by then they can make code that looks like it does one thing but in fact has a completely different operator.

Second, just what language is the functional library scalaz written in? I'll b'et *that* would be a pretty good functional language to work with.

The subset of Scala which does not allow Unicode identifiers or operators is a good language. That is true. Even the whole of Scala, where you haven't actually used Unicode is pretty good. Allowing Unicode operators which look similar to other characters , even after requiring a library include, and not giving serious compiler warnings about it, is a misfeature. Not nearly as bad as trigraphs (C++), boilerplate (Java / C#), lack of default array bounds checking (C), almost unavoidable run time errors (Java / Python), making old code invalid (Scheme) and having millions of personal variants (Lisp) unmonkey patching and random changes to the meaninig of your code (Ruby) let alone many hundreds of other thing from older abandoned languages, however it's still a misfeature. Every language has misfeatures and it's good to acknowledge what they are.

Re:Simple is good

[Anonymous Coward]

There's something odd here. The grandparent asked for statically typed languages which combine OO with functional pyrogramming. The answers here mention lisp and JavaScript both of which are dynamically typed. The OP is right about what seems to be ignorant vitriol. It's probably misplaced hatred transferred over from Java via the JVM but it's almost like the Microsoft trolls woke up and were afraid. Sensible answers might include Ocaml, which doesn't do dynamic dispatch and so really isn't even attempting to deal with the Java problems that Scala deals with and F# which came later, is very much limited to use in Microsoft related systems and anyway fails to deal with a number of important type cases Scala deals with well.

A more interesting set of criticism and explanation around Scala can be found in this discussion of Ocaml vs Scala on Reddit.

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

[Anonymous Coward]

It's just too bad Sun abandoned Self and went with Java instead. Or that Smalltalk didn't have it's act together. I've heard Eiffel was a real solid OOP language, but it seems to have remained niche.

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

[Anonymous Coward]

Pretty much every developer I know is sensible enough to only use == when comparing primitives or comparing against null. It's pretty much Java 101.

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

[Anonymous Coward]

Java+Scala remind me of the differences between C and C++. (People such as Linus T. would disagree) but C++ does add significant value and safety over plain C. But this comes with a cost of extra complexity, sometimes less performance etc. Overall I find Scala more pleasant to use than Java, but I sometimes get frustrated with the libraries. Just because you can overload operators doesn't mean you should go crazy with it. I also loathe the frequent use of obscure "DSL" style code.

Re:Would be nice to see Scala replace Java

[Anonymous Coward]

== does exactly what it's supposed to do, those two objects are equal. == on primitive values compares the value of those values and == on objects always compare the objects' addresses. .equals() can't be used on primitives because primitives don't have functions. .equals() on objects does whatever that object wants it to do.

If you're getting a lot of == vs equals errors you should hire better programmers. You also need a better manager, someone trained in software engineering compared to computer science. The manager should notice or be notified that this class of bugs is happening often. Then the manager calls a meeting and/or sends out a notice explaining the difference, reminding everyone to double check which one they're using because it's causing a bunch of costly bugs, and adds it to the list of things to pay extra attention to when doing code reviews.

If it's not cost effective to increase your developer's training in Java so they don't make such mistakes, then the bugs must not be that important.

I'd rather have =, ==, and .equals() than JavaScript's =, ==, and === or C++ where any operator could mean anything.

Re:Would be nice to see Scala replace Java

[Anonymous Coward]

Then create your own Integer class that delegates everything to the real integer class.

You shouldn't go into Java's behind the scenes caching in a *beginners* course. You only need to teach use == on primitives and .equals() on objects.

Re:Would be nice to see Scala replace Java

[Anonymous Coward]

Java strings are immutable like most of the higher-level languages. They all do this with strings as the potential savings are huge. The framework developer was a bad developer or didn't understand the language he was using. Despite what all the "I can teach myself any language in a day" people claim, a language isn't only the syntax.

Frankly, I'm starting to question your teaching ability. This isn't a "bash-your-head-on-the-table level of stupid design" it's an informed "we're-doing-this-for-these-sepcific-reasons-and-benchmark-results" design choice.

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

[Anonymous Coward]

Java pre-constructs the low valued Integer objects, so that == and .equals will always return the same answer.

They only evaluate the same way if you get the integer values with Integer.valueOf(N).
If you create them with new Integer(N) or similar, the == evaluation will always return false.
If you use valueOf() in different class loaders, or use serialization, == will also return false, even for those cached small values.
So it's not a good idea to rely on this, and one always should use equals with Integer objects.

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.

It is good

[nihadricci]

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

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!

[Anonymous Coward]

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.

Actually the binary incompatibility between libraries predate Java 8. Every time Scala goes through a major revision (2.9 -> 2.10 -> 2.11) there are binary incompatibilities between compiled libraries which require a recompile or, depending on the API, code modification.

Re:I see a train wreck ahead!

[Anonymous Coward]

You mean like the many dialects of C and C++ before sanity prevailed and they agreed to a standard?

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.

Re:I see a train wreck ahead!

[Anonymous Coward]

I haven't experienced any lib problems with Java 8 on my end and we gone through the original release, patch 5, and now patch 20.

Regardless, you are comparing a single case with Java with a repeat offender Scala.

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.

"a fundamental rethink"

[Anonymous Coward]

Please study Perl 6 and Python 3 before you start "a fundamental rethink" of a useful language.

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.

Re:Why attack Java like this?

[Anonymous Coward]

Python has fractured between 2.x users and 3.x users. I haven't used Java much in the past few years, but I really hope it doesn't make the same mistakes. A programming language doesn't need every feature, especially at the cost of breaking backwards compatibility.

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.

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.

[Anonymous Coward]

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.

Statically typed Lisp isn't just concievable, it's been concieved many times. And none of them really ended up making serious sense. Worth reading all the links from this Stack Exchange question. By the time you static type Lisp it seems it isn't much like the original.

Scala's type system does a whole load more than any of these Lisps seem to have done though.

Re:Yeah, Lisp is nice.

[Anonymous Coward]

You also seem to not understand Smalltalk then. Ruby is hardly a dialect of Smalltalk, more like a hybrid of something very Perl and PHP inspired. Something like Newspeak would be much better.

Ruby has a few similarities with Smalltalk but it stops there. By eliminating Smalltalk's true object oriented nature, simplicity, and the language expressed almost purely in itself, Ruby is far from Smalltalk.

The best example of the differences and bad design of ruby in comparison to Smalltalk can easily be seen in the Gemstone Ruby implementation. The same code on the Ruby side of things is so much uglier, dirtier, and less elegant. Part of where Smalltalk shines is that it is so simple that purity runs throughout, whereas Ruby is full of ugly hacks, bad designs (original string implementations, closures, functions as objects, and optionally concept of proper VM for instance), and looks more to Perl rather than Smalltalk. Traditionally, Smalltalk is also an environment, not just a language. Separating Smalltalk from the VM is doable (ex: Redline Smalltalk on the JVM) but leaves behind some of the joys and power of working in a pure, object-oriented, almost 100% self-contained environment.

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.

Scala is a joke

[Anonymous Coward]

When other language designers discuss language design, Scala gets laughed at, usually for the performance of the compiler, which is so slow that a couple alternative compile servers and sophisticated incremental systems have emerged to reduce the time. People that write large scale Scala application speak of how many minutes and gigabytes of memory it takes to "warm up" their build servers.

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]

Peter is an academic with exactly 0 successful programming languages to his name.

When Rob Pike, Bjarne Stroustrup, Andrei Alexandrescu, Niko Matsakis and others talk about languages and someone cites Scala as a fine example of a rudderless accretion of programming fads, no one objects. They giggle instead.

I'll take these guys over your programming philosopher every time.

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.

What?

[Anonymous Coward]

Are you joking?

Rob Pike? The Rob Pike who designed Go, a language stuck in the 80's in terms of type theory? The Stroustrup who "designed" the abomination that is C++ which language pervades industry almost solely because of inertia? I don't believe Andrei has designed any successful language, though he's certainly contributed to the design of D(*). Matsakis doesn't have any track record of language design as far as I can tell, though I'll certainly grant that Rust could end up a "better" language than Scala. ("Better" is subjective anyway.)