Stephan Schmidt makes several points in Scala Is Unfit For Serious Development . Some are even valid. Unfortunately, the valid points are buried in over-generalizations and attacks on the attitudes of the developers and community.
It's unfit because the developers and the community are unwilling.
At the end of his little diatribe he thanks 2 members of the community for helping him with his problems. Sounds pretty willing to me.
1. The developers are interested in language research and writing papers, not in making a language for real development
So far from true. Yes they write papers. But real development is very much a goal of Scala. If it weren't then Java interoperability would be ditched yesterday. Java interop is a giant albatross around Scala's theoretical neck. Some examples of how Java interop fights Scala: null sucks, the jvm doesn't do general tail calls, structural types are hacked in using reflection, and traits/mixins require a rube-goldberg copy mechanism. Java interop is only a practical concern for real programmers who want to get stuff down now with existing libraries.
2. The version hell that is 2.8 - calling this version 2.8.0 is deceptive. As Python (3000) or Ruby (2.0) this should have been a major version called 3.0
Some truth. Ruby made nasty breaking changes in 1.9.1 and Python isn't immune to them. None-the-less, it really should be called Scala 3.0 to communicate the extent of the changes.
3. The developers do not care about binary compatibility, deprecated, soft migration or API compatibility. Things are changed on a whim - from one RC to the next, and they change major parts of the language/libraries in point releases.
There is a significant technical challenge to maintain binary compatibility given the fact that the JVM has no multiple-inheritance mechanism. But that shouldn't be confused with a lack of caring. Martin Odersky has promised that the next major release will focus on solving the binary compatibility issue once and for all. Deprecation - could have been done better. Definitely. Then again, Schmidt is playing with beta software where API INcompatibility are pretty much guaranteed.
4. They remove and add classes just as they see fit.
A repeat of point 3.
5. The community loves cutting edge. Instead of fixing bugs they upgrade to all new released RCs - so have you. It's called cutting edge for a reason: You'll cut yourself. And it's called bleeding edge because you will bleed.
An overgeneralization. "The community" is apparently represented by the library causing Schmidt his problem. Other developers seem to be more careful. lift, for instance, has been very careful about its migration policy and just released version 2.0 against the stable version of Scala.
Conclusion
Scala's binary compatibility sucks due to a real technical challenge interoperating efficiently with the JVM. The 2.8 series is really 3.0. Deprecation could be done better. One library that Schmidt used decided to fix a bug and compile against a beta version of Scala. Schmidt jumped into the beta version. A small bit of versioning hell ensued. From this Schmidt concluded that the Scala development team do not care and that Scala is unfit for development.
In the meantime, back in reality, the small Scala development team is continuing to move forward with a great language. The community continues to put out awesome libraries. Businesses like Novell, Twitter, and FourSquare continue to make bets on Scala.
Is Scala flawed. Hell yes. But if you think it's a great language then contribute. Help make it and its ecosystem better. Help the developers of libraries maintain bug fixes on stable branches, or help test for breaking changes and push for a deprecation model, or contribute constructively to the binary compatibility challenge. Don't take potshots against the developers from the sidelines.
James,
ReplyDeleteWhy litter an otherwise unemotional facts based post with the rather sophomoric last-name only reference to him?
Do you expect people to call you "Iry" as a matter of course?
Oops, editing fail, had his full name as the first reference but hacked that sentence out and replaced it with a later one.
ReplyDeleteFixed.
ReplyDeleteI ditched Scala a while ago in favor of Clojure. I had a bit of this versioning hell as well and true I went for 2.8 but mostly because the 2.7 collections were a walking wreck of design and 2.8 was marginally sane.
ReplyDeleteContrasting with Clojure, despite adding several new language features from 1.0 to the soon-to-be-released 1.2, code is still compatible from version to version. I can't help but think this is in part due to the fact that Rick Hickey is far more concerned with the production use of Clojure than Ordersky et. al. are.
You have a couple of it's instead of its in there.
ReplyDeletere: Rick Hickey is far more concerned with the production use of Clojure than Ordersky et. al. are.
ReplyDeletethat's a blank statement, do you think?
Clojure's situation is different because it's not statically typed. Of course it's not having the same problems!
One small quibble:
ReplyDeleteWhen it comes to point 1, you are conflating Java interop and using the JVM as a platform. Most of your points are not based on things Scala does to have better Java interop, it is because Scala is running on top of the JVM - and the reasons for that are several. Many of those include having to avoid writing the infrastructure (like a JIT, GC and so on) and focusing on developing the language. Of course, having interop with Java is not irrelevant either, but don't conflate the two.
@foo,
ReplyDeletePost in hast, repent at leisure. Fixed.
@Ola,
I don't think I have conflated the two.
null - purely Java interop. Statically typed languages can use Maybe/Option types.
tail calls - you can do tail calls on the JVM, it just means you don't use the Java calling convention and hurts interrop. See SISC
mixins by copying - allows classes that are results of mixins to be callable from java. The alternative is to use a kind of C++ ish layer of extra indirection on all calls, but Java wouldn't understand it.
structural types via reflection - the alternative is to use wrappers, but then calling a method that took a structural type would be painful from Java
@foo
ReplyDeleteYes it is a blanket statement, and you're right it ought to be hedged and all that, but I think at least part of Odersky et. al.'s goal is to write papers about programming languages. Its an academic endeavor to some extent. Hickey on the other hand hasn't written a book or article about the language. Also, to the best of my knowledge, Ordersky doesn't use Scala to write production code. Hickey does.
James, I don't agree. You can definitely attribute the features in that way - but my guess is that isn't the full story, or even the main motivation. In fact, it seems most of these decisions could be attributed to having a performant implementation.
ReplyDeletenull - you won't need to handle, I concede that
tail calls - unacceptable speed to fix on the JVM for a language in Scala's category
mixins by copying - extra level of indirection would be to slow too
reflected structural types - reflection or bytecode weaving to implement wrappers: the recent paper from Odersky and co seem to imply they think reflection gives more flexibility and power, and also gives a substantially simpler implementation, even though the weaving wrapper approach could give better performance in some circumstances.
@Anonim
ReplyDeleteFrom Martin Odersky:
“Scala’s developers are interested in language research and writing papers, not in making a language for real development.” That one you got totally wrong. 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."
http://codemonkeyism.com/scala-unfit-development/
Good article! (Except where it uses the word "Conlclusion".)
ReplyDeleteErik,
ReplyDeleteNever happened! ;)