Summary
As developers consider Scala for enterprise software projects, the manner in which the language evolves becomes an important question. In a recent blog post, Jevgeni Kabanov discusses the need for a well-defined process in moving Scala forward.
Advertisement
Sun established the Java Community Process (JCP) in 1998 to serve a consensus-building body that determines the future of the Java platform, language, and APIs. Although often criticized, the JCP has fulfilled this role remarkably well, producing over 320 broadly accepted and implemented specifications. The existence of the JCP helped convince large enterprises to invest in Java projects, since Java's future no longer depended on technical directions set by a single company.
Other languages and technologies choose a different path for their progress. Perl creator Larry Wall or Python's Guido van Rossum, for example, act as benevolent dictators who have the final say about new features for their respective languages. Although the large communities formed around those languages provide significant input, the original language creators decide the future direction of their languages.
The Scala language originated as a research project, headed by the language's creator, Martin Odersky, at the Lausanne Polytechnique University. Indeed, Scala evolved mainly as a result of its instigator's sense of balancing research with the practical realities developers face on large software projects.
In a recent blog post, Where is Scala heading?, Jevgeni Kabanov ponders the degree to which this model will work as Scala is increasingly employed by enterprise developers:
Both Haskell and Scala are designed and implemented by brilliant scientists, who are the benevolent dictators when it comes to choosing the language features. In the Haskell case it's the Simon Marlow and Simon Peyton-Jones behind the GHC compiler along with a very active community with a lot of outstanding members. In the Scala case it's Martin Odersky and the LAMP.
Such a setup means that the language leaders are highly aware of the decades of computer science research and can pick the best and innovate on top of it. This is great, because you get substance instead of the buzzwords. However this also means that they are driven by success in research community.
What is the problem with that? Well, Martin is the professor at LAMP, which today means he has to teach and produce papers. However, to publish papers one must be constantly innovative, since CS conferences do not readily publish just case studies and tech reports. Since his main focus seems to be Scala it means that the language is constantly evolving to accommodate the innovation needed to get published.
The drive for innovation by itself is wonderful. However a programming language is a relatively fragile thing, since it must fit into the imagination of potentially millions of people. But when it's constantly improving it is hard to fit it in. Just look how much trouble introducing Generics caused to Java programmers.
Kabanov does not suggest that Scala implement anything resembling the JCP, and merely brings up the points of Scala directions and governance to solicit opinions from the community.
How would you like to see Scala evolve? What sort of governance do you think would ensure Scala's broadest success?
It's too early too worry too much about governance.
I think the LAMP team has shown some strain lately, as Martin Odersky waits/recruits another crop of qualified grad students.
Scala needs to grows its committer list for the core compiler and library first. Then it can worry about governance. The BDFL model will work for now and the foreseeable future.
Not to be contentious, but I don't think the comparison between Haskell's genesis and Scala's is as close as the author makes it seem. I read a good paper recently entitled "A History of Haskell: Being Lazy with Class" (16 April 2007) written by Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. (http://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf) What I took away from it was Haskell being very much designed by committee. (I don't mean "design by committee" in any negative sense. Reading the paper made me search out books on Haskell with the goal of learning it even if I'll never use it in my daily job.)
Martin Odersky seems to make many more of the design decisions personally and I'm happy for it at this stage of Scala's life. At some point, stability will come and I trust his experience in software development to know when that "magic date" must come. To aid him, good feedback from those using Scala beyond small "hello world" like applications is crucial.
The larger threat to Scala is it's compatibility with Java. What I've taken away from several exchanges on the Scala mailing list is that working around some of Java's design choices makes for compromises Martin would rather not make.
> The larger threat to Scala is it's compatibility with > Java. What I've taken away from several exchanges on the > Scala mailing list is that working around some of Java's > design choices makes for compromises Martin would rather > not make.
I think Martin's recent comments may give pause to some people thinking about using Scala in a commercial environment with dependencies on Java infrastructure.
It will get much more interesting as Java evolves. For example, if Java gets closures that represent an unacceptable compromise to Martin...or if Martin thinks they are great, makes Scala require Java 7 to run (I actually think doing that would be a good idea, but eventually that kind of thing would really piss people off).
> I think Martin's recent comments may give pause to some > people thinking about using Scala in a commercial > environment with dependencies on Java infrastructure.
People would be wise to do so. Right now low profile projects are probably the best test bed for Scala.
> It will get much more interesting as Java evolves. For > example, if Java gets closures that represent an > unacceptable compromise to Martin...or if Martin thinks > they are great, makes Scala require Java 7 to run (I > actually think doing that would be a good idea, but > eventually that kind of thing would really piss people > off).
It seems like Martin and his team have found exposed primitive types to be a source of code gymnastics. I don't know Scala "under the covers" but I would think moving away from Java library-by-library would relieve some stress. In the short term, it's impossible without losing half the Scala community.
Right now I'm just trying to learn Scala (and functional concepts) by translating an old class project from C into Scala. (Some of Scala's features are probably going to allow a much nicer design.) Any changes his team makes right now cause me little pain, so I'm probably a little more cavalier with a "do what you want to do Martin" attitude.
I don't see why Martin would push Scala as a research vehicle to the detriment of its stability, as suggested in the article.
From his public comments I gather he is aiming for the practical application of certain concepts. I gather he has developed a few pure research vehicles and if he wanted another I don't think it would look anything like Scala.
As for the long revision history of the specification: surely this reflects a normal, in-the-open development process, not wanton exploitation of the language as a research platform.
Personally, I hope to use Scala 2.7+ for commercial projects where I have the flexibility. I sense that backward incompatibilities will be manageable from here on, notwithstanding the Java 1.4 compatibility glitch in the 2.7 RC's.
But wholesale acceptance of Scala by the more conservative sections of the software world seems premature. I hope the language and user base grows organically (like python has over the years) and that Martin continues as benevolent dictator for now.
Previous Topic
