Summary
I've seen the next big JVM language, and it's called Scala.
Advertisement
Ever since I started working with Java, I had the same nag - the whole idea behind the JVM, packaging, et cetera is sound, but for a mid-90's programming language I would have wished that the designers put more burden on themselves and less on the user. Compilers at that time were doing funky stuff in terms of optimization (I remember the first time I analyzed the output of the MIPS C compiler), so there were plenty of compute cycles available to take work from the developer by making the compiler smart.
For the first really big project I did in Java, we quickly decided that we needed some aid and added JPython into the mix. Code generation in JPython was a breeze compared to doing cumbersome string manipulation in Java, but we left it at that because performance simply was not good enough. Ever since, I've been looking for something to complement or even replace Java, but so far the languages were either dynamically typed (and thus slow on the JVM), or very esoteric. Neither was, to me, a good option (I always seem to end up with projects that have high performance requirements ;-)).
Enter Scala. It's been a long time since I was so enthusiastic about a programming language (and this from a guy who had "learn a new language every year" as a motto for a very long time). It's not dynamic, but it's got the next best or even better thing: type inference. Basically, it's a language where the compiler takes all the burden of annotating variables, functions, etcetera away from the developer - usually it is smart enough to deduct this stuff by itself, which makes code just as concise as code in your favorite dynamically typed language, but with all the good stuff that static typing brings you: precise code completion in the IDE, robust refactoring, and not having to write unit tests that basically do type checking.
Furthermore, Scala is not just an OO language, it also supports the functional paradigm. One of the major annoyances in Java (especially when used to Smalltalk) is that you cannot simply pass around bits of code as first class citizens, and where you can the syntax usually makes stuff so unreadable that reverting to an imperative style usually is the better solution. Scala lets you pick and choose between OO and functional in a way that I, at least, never have seen in a language that has all the promises to go mainstream.
So why do I think Scala can go mainstream, then? It is a brilliantly designed language, and it is very accessible to Java developers (who can basically start out by doing pretty much what they're used to do but with way less typing). It has a very thorough book that explains the language (available somewhere here on the site ;-)), and it has IDE integrations in the three major IDEs. Also, by virtue of being statically typed, it will compile for most cases to straight Java byte code, so expect your programs to be pretty fast even for very demanding environments. Seems there's hardly any downside, then, just pluses...
This article basically is a promise to vote with my feet - the coming year, I'll hack Scala for my open source work, my side projects, and whatnot (hopefully my daytime job will follow), and I'll report back whether me as a seasoned Scala developer still has the same enthusiasm as me as a seasoned, errr..., Scala book reader.
Yup - you read me right. All this stuff above is mostly theoretical. Even though I've programmed (for food) in countless languages and I think I'm a pretty good judge about what will work and what won't, my judgment about any pudding is usually deferred until I ate it. Basically what I'm doing here is boring you with non-information about perceived benefits, sticking my neck out in public for a language that I just feel to be great (and just what I've been looking for since, say, 1997). So far, my "Hello, world" level work seems to support my expectations.
Wath this space for my confrontations with reality...
I do not quite understand why people expect a "next big language" for the JVM? Does anyone believe that the industry will side-step the huge technology stacks that have be built around and for Java within the last 10 years?
I remember a conversation of Java programmers and advocates a few months ago when Sun announced 3 JSR upgrades for JSF, JSP and JCA that started with the words "Are you still get it? It becomes ever more likely one selects the wrong tools...".
Many people attempted to side-step this problem and selected Rails. This was a few years ago. What has happened since then that changed the big picture? Another statically typed language that is more expressive but also more complex than Java?
> I do not quite understand why people expect a "next big > language" for the JVM? Does anyone believe that the > industry will side-step the huge technology stacks that > have be built around and for Java within the last 10 > years?
Isn't that the point of Scala targeting the VM and being able to work with Java libraries? A number of compromises have been made in order to maintain good compatibility with Java.
Kay, the whole idea is that you don't ignore everything that's written in Java. For example, my first "hello, world" was a servlet (and a simple main program to start an embedded Jetty to run it), and one of the experiments on top of my list is to create code that works with GigaSpaces. Scala even supports Java annotations, which means that you can integrate Scala code into most modern frameworks (that assume POJOs + annotations - for the POJO bit you sometimes need to do a bit of work to make Scala objects Beans-compliant IIRC, but it's definitely feasible).
> Another statically typed language that is more expressive > but also more complex than Java?
In my own experience, Java's lack of support for closures and functions as first-class objects makes my programs much more complex than they would otherwise be (which causes bugs, sometimes complicated ones). Maybe you think closures and functions as objects are "more complex," but I'm sure many would agree that the absence of those kinds of features is really what makes Java much more complex.
For Scala to become mainstream it at the very least has to have clear advantages. Along the lines of the step going from procedural to hybrid pocedural/OO, we could now move on from procedural/OO to functional/procedural/OO. This is more of a paradigm shift, and I wonder how many mainstream programmers are willing to wrap their heads around highly recursive function definitions, which I guess is where the true power lies. Consiceness constructs are nice but maybe not enough to warrent it to be the next BIG thing. Me myself am halfway through the programming Scala book and do like what I see. Now back to reading...
> > Another statically typed language that is more > expressive > > but also more complex than Java? > > In my own experience, Java's lack of support for closures > and functions as first-class objects makes my programs > much more complex than they would otherwise be (which > causes bugs, sometimes complicated ones). Maybe you think > closures and functions as objects are "more complex," but > I'm sure many would agree that the absence of those kinds > of features is really what makes Java much more complex.
I think what you are saying is that Java code is much more complex. Scala is a more complex language than Java but Java code can be more complex than equivalent Scala code. I think few can argue with that.
I expect that Kay is really pointing to some of the other features of Scala. Closures and function objects are something I very much desire in Java but that's just the tip of the iceberg in terms of the features that Scala has that Java does not.
My take on complex languages (where I assume that the complexity actually adds features, i'm not talking about C++ here ;-)) is that they give you a choice, whereas a simplistic language like Java doesn't.
For example, in Scala, most developers will actually start using functional features and probably pattern matching. For some problems, passing code as first-class objects is just the more natural approach, and most of the really good languages support this (starting with Smalltalk).
However, some of the power tools seem to be very much geared towards library developers who can basically wrap their libraries into DSLs if they want to (note the "if they want to" bit). Maybe their code will end up to be a bit denser and harder to follow, but when applied judiciously giving your users a natural API I think the trade-off is good.
Overall, I think Scala is a good mix of a simple and clean base language (we're all doing SCJP atm, I haven't made an exception for myself - it's interesting to do the lab work both in Java and Scala, typically saves you half the code) and great features that assist in conciseness, scalability, and API design.
Compare it to a couple of other "complex" languages I know, for example C++ has complexity to let the developer stay close to the hardware. If you're writing a kernel (has that ever been done with C++?), that's a valid design. For an application-level language, it's a horror. Ditto with Perl - the designer of Perl never actually did the hardest bit of design: making choices and leaving stuff out. So you have three ways to do the exact same thing. Nice if you're a lone sysadmin whipping up scripts, not so nice if you are in a larger team and can't read your colleague's idiom.
In this sense, Scala is the first "complex" language I've seen (for what that's worth, of course), that both provides a gently sloping ramp-up for beginners and all the tools and features that you want for the "advanced" stuff.
I'm a big fan of Scala. It cherry-picks a lot of important ideas from its functional programming heritage and delivers them in a context that's nicely integrated with the extant body of Java code.
My only real beef with it so far is the choice to include XML as a native part of the Scala vocabulary. It biases the language toward a more PHP-like UI-centric world view rather than letting it be a more general-purpose language.
It would have been nicer to see rich XML support layered on top of a slightly smaller core language subset. However, I think this wart is not sufficient to downcheck it in my book.
I'm especially excited about its intrinsic support for views. This is something that I've played with supporting in a number of different languages, both standard and custom and I think it is high time to see it show up in a widely-available general-purpose language.
> > Another statically typed language that is more > expressive > > but also more complex than Java? > > In my own experience, Java's lack of support for closures > and functions as first-class objects makes my programs > much more complex than they would otherwise be (which > causes bugs, sometimes complicated ones). Maybe you think > closures and functions as objects are "more complex," but > I'm sure many would agree that the absence of those kinds > of features is really what makes Java much more complex.
It depends on who the audience is. It takes a more sophisticated programmer to understand indirect execution.
It's true that closures, type variables and functions-as-objects can, in the hands of a skilled practitioner produce a program that's much simpler and more elegant than an equivalent Java program.
However, it takes that *skilled practitioner* to envision the problem in such a manner in the first place. What sets "easy" languages apart from "hard" or "complex" languages isn't particularly syntax. More often, it's the number of ideas contained in the language and the level of abstractness and sophistication of the ideas.
It's easy for a nonprogrammer / neophyte to embrace the idea of variables and the sequential execution of instructions. Concepts of looping and flow control are more complex but still relatively accessible. Notions of concurrently-threaded programs, deferred indirect execution and parametric types start to limit the audience to actual computer scientists.
It's worth remembering that when the Macintosh Toolkit and Windows 3.0 hit the mainstream, there was a serious wave that went through the software industry forcing programmers to take a step forward in sophistication to be able to deal with programs that were structured in terms of callback handlers instead of simple Main(){} - driven top-down programs.
Just for the record. I didn't try to be offensive towards Scala. The question was meant to be more seriously than a flame: what are people actually expecting from JVM languages other than Java? More JSR style documents, APIs, frameworks stacked upon existing ones?
I started to be engaged with Jython 2.5 just recently. I wanted to know what to make of the Javaverse after having been absent from it for almost the whole decade. In no way I dream about Jython becoming the "next big language" on the JVM. Instead I call Jython a "flea language" living on the huge body of Java and I'm interested in how the Javaverse "curves" in its presence. All that I expect is some sort of trivialization here and there which is induced by taking a radically different point of view. For me it is not about adding expressiveness or using Django on the JVM etc. but scripting in the sense of customization and trivialization.
Personally I don't want to escape the Javaverse like the Rails fans I mentioned. On the contrary. At a moment where everyone attempts to leave it with this "next big language" fantasy in their heads I'm interested in moving in.
> Just for the record. I didn't try to be offensive towards > Scala. The question was meant to be more seriously than a > flame: what are people actually expecting from JVM > languages other than Java? More JSR style documents, APIs, > frameworks stacked upon existing ones?
I can't speak for everyone but a 'new Java' for me would 1) hit the same niche as Java: structural, slowly changing 'foundational' code. The kind of stuff that everything else depends on to work and to be transparent. 2) Eliminates the major design flaws of Java. 3) Adds a few carefully chosen, powerful features (such as a closures.)
> I started to be engaged with Jython 2.5 just recently. I > wanted to know what to make of the Javaverse after having > been absent from it for almost the whole decade.
I've been in the Javaverse for the last 8 or so years and I'm a big fan of Jython. Ever since I started using it, I've felt that this was the future. Java for the foundation and frame, Jython (or other dynamic language) for the decorations.
> I've been in the Javaverse for the last 8 or so years and > I'm a big fan of Jython. Ever since I started using it, > I've felt that this was the future. Java for the > foundation and frame, Jython (or other dynamic language) > for the decorations.
When you are a Jython fan you might be interested in my recent work on Jython which brings forward the utilization of Java from Jython:
I won't diss Jython here - JPython was a big lifesaver back in the '90s when I worked on a huge Java project :) - but in the context of this thread, performance of any dynamic language on the JVM will seriously lack until Java 7's invokedynamic.
And, I must say, I'm quickly becoming a big fan of type inference engines - it seems they combine most of the benefits of dynamically typed languages (method dispatch speed, much better refactorings) with the absolute minimum of drawbacks (having to insert type declarations in quite a number of places).
My cursory look at Scala tells me that Scala may solve many of the concurrency issues that plague server-side development. Threads/concurrency are the "pointers" of programming today. If Scala can do this and maintain compatibility with existing Java sources, it has a very good chance in the marketplace.
Previous Topic
