Scala isn't perfect, but it's a great language to have on the JVM.
However, the lack of API and ABI compatibility is a really big failure. I can't believe that they're shipping what is supposed to be stable software and we can't rely on our code to continue running, much less building.
We had to do a fair bit of work to fix our projects' 2.8 compatibility issues, and it's causing us all sorts of grief in terms of having to do lock-step upgrades of all libraries from 2.7 to 2.8.
My understanding is that this release is partly intended to fix some of the earlier design mistakes before it gains too much popularity. They wanted to do this now rather than later to prevent a python3 scenario.
Would you rather Java? Where everything is shit because of backwards compatibility?
They've put a hell of a lot of work into making everything as compatible as possible with 2.7. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.
> Would you rather Java? Where everything is shit because of backwards compatibility?
... or Perl5 for that matter. Python has continuously broken backwards compatibility in their APIs between releases and that has allowed it to shed much technical debt.
It's annoying for developers, but it's better for the language and the ecosystem to keep evolving. Scala is taking the correct route here.
Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric?
Where everything is shit because of backwards compatibility?
Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly.
Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it.
They've put a hell of a lot of work into making everything as compatible as possible with 2.7
But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits.
If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step.
At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.
Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).
That's an excellent response, and I'd mostly agree with you.
I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose.
Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.
The compatibility issue have to do with how Scala's traits have to be implemented on the jvm. If it was possible for an interface to have method bodies or abstract classes be multiply inherited in java bytecode the problem would be much less. Instead the bodies have to be compiled into the implementing concrete classes which leads to most of the problems.
Someone needs to write an intro to scala that assumes no prior java experience. I know Ruby, C, C++ and others on a *nix quite well, but I have no clue about anything Java-related. This is a problem when I'm trying to figure out how to deploy a self-contained scala application.
The link basically recommends that you learn Java first :).
For better or for worse, Scala relies a ton on Java, and no one has created Scala-specific tools to simplify some of these things you can already do with existing Java tools.
If you want to create a self-contained jar, the following URL has people discussing how to do this with SBT and Maven: http://www.scala-lang.org/node/6750. I wouldn't wish the curse of Maven on anyone, let alone someone who hasn't been force-fed it by the Java community for a while, so I'd recommend trying to learn sbt and then port the solution posted in the above link to your own sbt project. I really wish the solution were simpler, but Java tools have always focused more on server-side web deployment and have always been weaker in the area of client-side deployment.
* I wouldn't wish the curse of Maven on anyone, let alone someone who hasn't been force-fed it by the Java community for a while, so I'd recommend trying to learn sbt and then port the solution posted in the above link to your own sbt project. I really wish the solution were simpler, but Java tools have always focused more on server-side web deployment and have always been weaker in the area of client-side deployment.*
I've only ever used maven for Scala projects, but I've come across this sentiment a few times -- it always strikes me as odd, given that I have very few significant maven complaints.
It has all sorts of great tools for automatically fetching dependencies, and doing "the right thing" via some fairly simple conventions. It's really easy to wire up something like tomcat:run to run a war in-place -- or your own custom self-contained code.
I also really like being able to have a local maven repository where we can store our own build products (and declare dependencies against them); server software like Artifactory makes this very nice: http://www.jfrog.org/products.php
Maven isn't wonderful, but build tools never are. I don't understand why you would hate it. Why do you hate it?
I agree with most of what you said. I like the idea of Maven's dependency management and repositories. It's also nice to have a lot of plugins to take care of common build system use cases for you. I just happen to hate the rest of it. Fortunately, I can get the best of both worlds. Buildr, Gradle, Ivy, and sbt can all work with maven repositories. So I can take the best of Maven, a.k.a, the one and only really good thing about it, and use it with better build tools!
Now, as to why I hate maven, these several-year-old posts explain it better than I do.
Really, it boils down to the fact that I believe that the philosophy of the Maven creators about build systems is fundamentally flawed. They say "when you want to script you know you're doing something wrong". I say, I'm a mature programmer, so give me a mature tool that enables me to get my job done.
Case in point. For a simple side project I was using JAXB to create an xsd from java classes. JAXB wanted me to maintain a flat text file listing all of the classes I wanted included in the xsd. I knew for a fact that every single java file inside a particular directory (recursively, of course) needed to be included in that xsd.
If I were using Maven, I would properly just resign myself to the fact that there is no JAXB Maven plugin to do what I want. I would therefore just manually update the file every time I added, deleted, or renamed a java class in this directory, which turned out to be very frequently during development. I certainly wouldn't feel it would be worth the herculean effort of writing a maven plugin and figuring out how to wire the file dependencies together so that the required tasks only run when needed.
Fortunately, I was using buildr, and 50 or so lines of scripting code later I had a perfectly efficient and automated solution to my problem. Now this was for a simple side project. Imagine a real product created by a real company. Do you really think that company won't ever have any custom build needs that go beyond the provided maven plugins?
Why waste your time with a limiting, clunky, slow, XML-based build system when you can use one that is designed better from the core and therefore easier to use, more flexible, more maintainable, and, best of all, faster because developers can afford to spend more time to wire things together efficiently?
Does anyone know if there are any plans to update Odersky's "Programming in Scala" book? I'm intending to buy it in order to learn Scala, but if there's a second edition pending I'd rather hold off.
Alternatively, if someone knows a better community that could field this question, I'd really appreciate being pointed in that direction. One thing I've not really grokked about Scala is where to go to ask such things!
AFAIK, there are no plans to update "Programming in Scala". But most (if not all) code examples from PinS should work with Scala 2.8.
The scala-user mailing list (http://listes.epfl.ch/doc_en.cgi?liste=scala-user) is the best place to ask (and get answers for) newbie Scala questions. Using the "scala" tag on StackOverflow also produces good results.
Good question. If no one answers here, try asking on StackOverflow. They've had some discussions on that book, but none recent enough to answer your question.
In fact I am about to take a leave from university and found a startup to do commercial Scala support. I am taking some of the key Scala developers with me.
However, the lack of API and ABI compatibility is a really big failure. I can't believe that they're shipping what is supposed to be stable software and we can't rely on our code to continue running, much less building.
We had to do a fair bit of work to fix our projects' 2.8 compatibility issues, and it's causing us all sorts of grief in terms of having to do lock-step upgrades of all libraries from 2.7 to 2.8.
reply