Fruit flies in the JVM

Fresh winds are whipping through the JVM development community, and they aren’t–apart from JavaFX–coming from Sun. The hype around multiple (“more than 200!”) languages running on the JVM has led an acceptance that running something other than Java, and something other than a simple scripting language, on the JVM, is not only a distinct possibility but also a competitive advantage allowing developers to expand their toolkits and skillsets horizontally rather than orthogonally. What I mean is that new languages, or new implementations of existing languages, on the JVM allow developers with an investment in JVM stacks to try new things out without leaving that stack behind.

It’s odd, but now I’m getting the feeling there are new languages popping up for the JVM on a monthly basis; this is mistaken, since in reality, getting a language to a stable enough state to be published seems to a take many months or even several years of hard development work. Still, we are seeing much more than just JVM-based implementations of Python and Ruby, and we’re seeing it happen more quickly than I think anyone would have expected. And they are announced without much fanfare and without much corporate backing or marketing muscle behind them; that’s a change, and a welcome one.

I think there are several core developments to the landscape that are enabling this:

  • It’s much easier to test against multiple OSs these days, what with dual/triple boot machines, live CDs, and virtualization; that means your language can be relevant on the 3-4 major OS platforms from day 1.
  • The infrastructure to host code, source control, and to document what you’re doing is now very, very cheap. With a little elbow grease you can promote your new product with a spit and polish that a few years ago would have only been possible if you had money in the bank. This is a big plus for developers who want to see the samples, APIs, and run the 5-minute build-a-blog test.
  • There’s more acceptance of new languages, and, I think, the arrival of production-ready implementations like JRuby and Groovy on the JVM offers hope that we have real alternatives in solving real problems, and that we no longer need to commit to one language and one stack in building out our applications.
  • The widespread use of RSS/Atom-based promotion, blogs, and online video draws much more attention, at low or no cost, to the work you’re promoting, and it happens much more quickly than before.
  • The consultants who used to make a killing on promoting Java are seeing their rates fall and need new markets to conquer. OK, that’s being mean, but these people are offering free promotion in very public forums–not just blogs but conference presentations and workshops.

What’s missing, I think, but not far off, is making IDE support for new languages a core component of a new language’s early code drop. The more people write language support plugins for the major JVM IDEs (Eclipse, NetBeans, IDEA), the more the IDE developers try to improve this support and build out their support libraries, and the more end-users see that these IDEs are no longer aimed merely at Java. I think that the IDE situation needs to improve some more; given the pace at which these plugins are being developed, it seems, from the outside, to remain a pretty time-consuming task to get full-featured language support in an IDE. Part of this depends on the complexity of the target language–for example, Scala has a reputation among those developing plugins for it to be pretty hairy, and in the time elapsed since Scala first started drawing more interest, we are still stuck with one complete plugin for Eclipse, and two plugins, for NetBeans and IDEA, that are not even in an alpha release yet. I do wonder if the task can’t be made easier, though. How, I’m not sure (I’ve never tried writing one), but if we can simplify the task and shorten the development cycle, we’ll enter into a really fertile period for language development, where releasing a language plugin, possibly for 3 IDEs at once, wil be considered commonplace rather than unusual.

Some “new” languages that just popped up on my radar are Mantra and JSqueak; there was also Talc and Fan a few months ago. Here’s a list of languages that I’m starting to keep an eye on–it’s a pretty limited list, given what’s actually out there. The links point to the home page for the project.

  • Scala: “Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java.” Scala needs no introduction, since it gained a lot of attention, especially in the last six months.
  • Fan: no one-liner for this one (maybe that’s a good thing). One of its strengths is portability across the JVM and CLR. The authors introduced the Fan language to the JVM Languages mailing list a few months back, and recently got some airtime from Cedric Beust and Stephen Colbourne.
  • Talc: “The language Talc is an interpreted scripting language for quick and easy programming. It is simple, straightforward, and aimed at aficionados of the C family, despite its Pascal-inspired declarations. Particularly notable features are static typing, mostly C-like syntax, and the all-important curly braces”. Check out the author’s (Elliott Hughes) blog; he recently posted an interesting comparison of Java bytecode generation libraries. I find Talc interesting in part because it’s aiming to be a language with a small “l”, aiming primarily at small scripting tasks.
  • Mantra: “Mantra (Hindi for “magical incantation”) is a new dynamically-typed programming language that is syntactically similar to Java but with the flexibility and ease of programming of Ruby or Python. Mantra is not an interpreted language. Source code is translated to Java and so Mantra programs integrate trivially with plain Java code.” Mantra is the brainchild of Terence Paar, the author of the increasingly popular Antlr parser generator.
  • CAL: “A lazily evaluated, strictly-typed language…with many similarities to Haskell”; see also their introduction on the JVM Languages mailing list
  • JSqueak: “JSqueak is a Squeak interpreter written in Java.” Squeak is a Smalltalk dialect. Very cool–the demo available from the homepage runs a Squeak development environment in your browser as an applet.
  • Clojure: “Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.”. There are some great screencasts and presentations introducing Clojure available as well.

A good place to hang out and hear from those writing languages for the JVM is the JVM Languages Google Group. If you haven’t been following it, check out the archives; many of the most active JVM languages developers have showed up there, and there are a number of threads describing the languages in some detail.

I would be remiss if I didn’t mention Sun’s role in promoting all this, and the success they’ve had doing so. Their hiring of two JRuby core developers, and their investment in supporting Ruby and JRuby in NetBeans, as well as GlassFish, have all seemed to pay off handsomely; JRuby seems to be a real contender to standard Ruby for rubynauts. We haven’t seen as much from the Jython developers (two of whom Sun also hired), at least in public announcements; but there’s reason for hope, as they seem to have Django running (to some degree), are closing in on Python 2.5 compatibility, and will have support for Python/Jython in NetBeans by the time NetBeans 6.5 is out later this year. Anyway, seems like a good strategic move by Sun.

I should probably mention JavaFX as well, but I think I’ll wait until the SDK comes out next month and we see how well it plays in the developer community. I’ve been following the compiler mailing list since it was established, as well as that of the new scenegraph API on which the language relies, but it’s really too early to say how it will play in Peoria. The early enthusiasts are, well, enthusiastic, but outside of some pretty simple demos on the web we don’t really have anything to see at this point, much less anything useful. But they have some smart people working on it, there are some cool ideas in the language, Chris Oliver has written some awesome demos, and in general, I’m hopeful.

I’m looking forward to more surprises.

This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.