The Primary Contenders

So far, I've taken an in-depth look at one language and two application development models. I just don't have the time or will to do a comprehensive treatment of languages, I'll take a longer look at what I see as the major alternatives. Then, I'll mention a few alternatives that I see as less likely.

I've got a few things working against me. If I were inclined to do so, my practical experience is limited to some Ruby , a little Smalltalk, and a few lines of Lisp in college. I'm just one Java developer, who's prejudging the overall landscape based on my limited experience. In my favor are my broad and diverse network, an excellent set of reviewers, good access to corporate opinions at major vendors and customers, and a strong track record of predicting successful technologies.

Instead of picking a winner, I'd just like to lay out the factors in favor of a language, and those against. In such a short treatment of this problem, I'm not going to be able to do any remotely complete treatments of any given language, but based on Java's history and this community, I should be able to give you a good sense of what's important.

Steve Yegge: Python, Ruby, and Groovy

Language expert and creator of Wyvern

Steve Yegge, a graduate of the University of Washington, spent five years as an Assembly-language programmer at Geoworks and more than six years as a software development manager at Steve somehow managed to find time to design, implement, and maintain a massive multiplayer game called Wyvern (, with a half-million lines of Java and Python code.

What do you think of Ruby and Python?

SY: They're both amazingly expressive, easy to learn, and easy to read. They're good languages, and they have a lot in common. Many people have pointed out that they appear to be converging, feature-wise.

They also have similar problems. Performance is a big oneboth of them are too slow, and need compilers and/or VMs. They both also have legacy design decisions they're trying to fix. Ruby 's trying to back out of some of its Perl-isms, and Python's still fixing its warts.

What holds you back in Python and Ruby?

SY: Python is wonderfully expressive, but it's also quite prescriptive. Developers hate being told how to do things. For example, there's no reasonable way to do an if/then/else on a single line. Each one of those little things is a rock in your shoe.

For both languages, my biggest concern is concurrency support . After you see what Erlang and Gambit Scheme can do, you quickly conclude that the next big language has to have something like it. But the world's not going to wait around for a perfect solution. We're at a tipping point, and sometime in the next year or two, I think one language will rally enough support to be a phenomenon as big as C++, Perl, and Java were, perfect or not. My money's on Ruby at the moment.

Will Groovy be the next great language?

SY: I don't think so. I was hoping it'd be cool, since among the 10 or 15 halfway-decent JVM languages out there, Groovy seems to have the most hype, and that's important. Technically, it's lacking.

At first glance, Groovy appears to be doing a lot of cool things and making good design decisions. Sadly, it doesn't survive the second glance. The language is a sort of kitchen sink for features, with no coherent vision emerging. The design is more focused on shortcuts than on general expressiveness. There are some good features, but not enough of them.

Except for the marketing, Groovy's execution has been particularly bad. It's still among the slowest JVM languages, and every beta has had obvious showstopper bugs. There's no real documentation, and the language only just got a parser generator after two years. It feels amateurish.


Of all the languages generating a buzz in the Java space, Ruby comes up the most frequently. The Java community invests passion in equal parts venom and bliss into the raging Java versus Ruby on Rails debate. This fervor interests me because Ruby, and Rails, get plenty of exposure within the Java community where more mature object-oriented languages like Python and Smalltalk do not. Exposure can translate to more exposure and more users. Developed in 1995, Ruby is relatively mature in calendar years, but it gained popularity first in Japan, and the worldwide community is just now starting to grow. Among the most promising contenders, Ruby has the interesting combination of being relatively mature and simultaneously undiscovered by the Java masses.

In favor

While Ruby doesn't have the support of something like Java, it does have pretty good commercial backing in Japan. It's got a healthy community, and awareness in the Java community. It's also got a good virtual machine. But the beauty of Ruby is primarily in the language. Ruby also tends to solve a few important problems very well:

  • Ruby makes metaprogramming feel natural. Reflection is easy, and you can move and change methods quickly. Ruby's modules let you mix in important capabilities without changing any source code.

  • Rails, the flagship Ruby framework, makes it easy to build web sites based on relational databases. In the past decade, no other application has been more important.

  • Web-based development with other innovative approaches is easy. Ruby has at least three exploratory projects related to continuation servers.

Ruby is extremely dynamic and extensible. You can literally hook into Ruby everywhere. You can replace the methods of a whole class or a single instance at runtime. Ruby developers often introduce methods that themselves introduce other methods and behavior. The net effect is a single hook that lets you add significant capabilities to a class or instance with very little syntax.

In my opinion, metaprogramming in some form will increasingly define modern programming. That's already happening in Java, with persistence engines like Hibernate, programming hooks like interceptors, programming models like aspect-oriented programming, and language extensions like annotations. To do metaprogramming effectively, you need to be able to extend a language to fit seamlessly within a domain. Languages that make this easy will move faster than languages that don't. Java limits the ways that you can extend a class, it makes you work hard to do reflection, and it makes you use unnatural techniques like byte code enhancement, code generation, and dynamic proxies. On the other hand, Ruby handles metaprogramming with ease. For example, the Rails framework, Active Record, defines belongs_to and has_many methods describing database relationships. Each method adds additional Ruby behavior and attributes to the decorated class. At the most basic level, the Ruby language itself uses metaprogramming to describe attributes. attr_accessor :name is shorthand for this:

    def name=(value)

    def name

You get a syntax with less repetition, and the language developers did not have to work very hard to give it to you. Of course, Java also does metaprogramming. It just doesn't do it very well.

Ruby interests me for several other reasons, too. Ruby is a chameleon with enough theoretical headroom to grow beyond Rails with ease, and a simple enough syntax to excite beginners and educators. Ruby will let you do functional programming, or play with continuations. You can write full web-based applications, or slip into scripting for rudimentary text processing. Ruby gives you a language that's theoretically pure, and practical.

Ruby might not have the extensive libraries of Java, but it's closing the gap rapidly. It's also worth mentioning that Ruby is doing so with a fraction of the developers, because Ruby is just so productive. As Java moves more and more toward metaprogramming, this productivity gap will increase.


The biggest strike against Ruby right now is the lack of a strong project that lets Ruby run on the JVM. The JRuby project's vision is greater than a simple port to the JVM. So far, the project has had several stops and starts. It's not far enough along to, for example, run Ruby on Rails. Most in the Ruby community don't see the political importance of a language that runs on the JVM, but interest and participation in the project may be picking up. JRuby seeks to let you use Java classes using Ruby idioms. For example, you'll be able to use Ruby code blocks with Java collections. If Microsoft is able to woo the Ruby founders over to .NET's CLR, or if the JRuby project starts picking up momentum, you'll see one of the biggest strikes against Ruby go away. Still, the lack of a credible version that runs on a widely deployed virtual machine, be it Microsoft or Java, is a major strike against Ruby. To be fair, the JRuby project in the months just before publication has made incredible strides. It now passes over 90% of the test cases for the basic Ruby platform. When it reaches Version 1.0 and can run Ruby on Rails suitably, Ruby will become a much stronger contender. Any language that embraces and extends Java will be in a much stronger political position.

Also, Ruby does not have the excellent commercial backing of some of the other alternatives. For example, Google uses Python extensively. Though Ruby is gaining traction in Japan, and also at places like, it's still a relative unknown. You can't yet hire Ruby programmers in numbers, and your training options are limited. If the Rails project hits a critical mass, that will change in a hurry.

A Word About Lisp

Lisp addicts might wonder why their beloved language is not higher on my list. In fact, Lisp has many of the characteristic of Ruby, with superior metaprogramming, a more extensive language, a good functional model, readable macros, and a clean and consistent interface. Lisp has never had the all-important marketing visionary, a catalyst, or the approachability of Ruby. It's also got history and a reputation to overcome. Ruby also has some other telling advantages: better regular expressions, parallel assignments (x, y = y+1, x+1), effective modules, better encapsulation (like private or protected methods), and standardized threads. True, many of these things have been done in Lisp, but Ruby provides a clean, standard solution in the language.


Major factors, including a comparative lack of libraries and the absence of a credible JVM implementation, argue against Ruby, but it's still a primary contender because of a possible catalyst in Rails, economic justification in productivity, and the database and web libraries that make it practical for a good set of problems in the enterprise. The language is theoretically pure and strong enough to last. You can integrate Java applications through web services and communication protocols, or C applications through a native interface. It has a virtual machine, and dialects for all major operating systems. If something challenges Java soon, I think Ruby is the most likely candidate.


If ever you are looking for a test case for the requirement of a catalyst, look no further than Python. It has just about everything we're looking fora good metamodel, a clean and readable syntax, dynamic typing, flexibility, and power. Python is also pretty natural for Java programmers. Here's a Python example from

    def invert(table):
        index = { }                # empty dictionary
        for key in table.keys( ):
            value = table[key]
            if not index.has_key(value):
                index[value] = [ ] # empty list
        return index

You'll notice a couple of striking things about Python right off the bat. First, unlike Java, you don't have to have a full class definition. Python is equally at home as a procedural language or an object-oriented one. Second, you don't see any syntax to end a block of code because whitespace matters. Indentation determines code grouping. Like many great programming languages, Python holds appeal for both beginners and advanced programmers. There's much to like.

In favor

Python has many of the same advantages as Ruby. It's dynamically typed, object-oriented, concise, and friendlier to applications than Java. It's easy to read, very consistent, and free. You can find interesting free libraries to do everything from web development to ORM. Python has the advantages of a productive applications language, and relatively numerous libraries. You can run it on Java's virtual machine in an environment called Jython.

Python has an extensive vibrant community. You can find support, hire developers, and get consulting. The open source libraries are numerous, but nowhere near the extent of Java's. Though overall growth has been sporadic, Python has gained limited traction in spots, in flagship accounts like Google.


While Python has a few good web development frameworks, it doesn't yet have a Java-killer like Rails. I'm already seeing a few Rails clones emerge, like Subway (, but none of them has the marketing punch behind Ruby on Rails. In fact, the primary strike against Python is the lack of a catalyst of any kind. The Python community is full of technical vision, but the marketing vision has so far been lacking.

Several influential Python bloggers have recognized the Ruby buzz in the Java community, and they make the point that Python doesn't yet have that compelling framework that might convert a Java developer. Java consultant Stuart Halloway moved to Python for better productivity, but he believes the Python community does not actively court the Java community. Many of them believe that Java is irrelevant.

A few minor technical details hold back Python. Some don't like the idea that whitespace is significant. That turns off some Java developers who like to condense repetitive Java constructs, such as default constructors or accessors, like this:

    public String getName( ) {return name;}
    public void setName(String name) {;}

Overzealous enforcement of anything leads to problems with programmers, and whitespace is no different. When you dogmatically enforce whitespace, you also limit your expressiveness. For example, you might type:

    if ( character =  = eol ) { ); count ++; }

because it expresses a single coherent thought as a sentence. Whitespace alone isn't the problem; it's the dogmatic enforcement of endless subjects like this one that rub some developers the wrong way. The overriding Python philosophy says there should be one obvious way to do something, and the language designers often go to great lengths to maintain those conventions, sometimes sacrificing flexibility to do so. The hope is that consistency will override any disadvantages. In the past, these kinds of attitudes have limited the flexibility of a language. Unless the language designers have perfect imagination, it's often best to let a language evolve in several different ways at once. The Python leadership does have a reputation as being somewhat frosty and dogmatic on these types of issues.

You can do metaprogramming in Python, with method or function pointers and using reflection, as well as other techniques. Those that have experience in both Python and Ruby seem to think that metaprogramming is more natural in Ruby. You can work with objects or not, which is a double-edged sword. Some (like the founder of Ruby) say Python might not be object-oriented enough.


Python has most of the tangible benefits you'd expect in a dynamic language, but it lacks the intangibles. New languages either pop when they're discovered, or they don't pop at all. Python never popped at all. Python is a nonentity in the Java community. That's a shame, because Jython makes it a viable political option when languages like Ruby aren't even considered. Python proponents looking to displace Java can argue that using Python amounts to a different syntax and some different libraries, and the rest of the infrastructure remains unchanged, but the often negative Java sentiment within the Python community works against Jython. Most Python developers don't understand that Java, too, is a powerful language, based on its extensive community, which leads to more libraries and massive commercial support.

With the emergence of some kind of killer app, Python could well emerge as a Java killer. Without it, Java developers think they already know what they need to know about Python, so there's no real reason to give it a second look.


Groovy is a new dynamic scripting language. It's built to run in the JVM. It's backed with the JCP with a JSR. It's still young, and it seems to be having problems getting to a solid, stable release.

Groovy is particularly interesting because it has none of the fundamental problems with marketing and acceptance in the Java community that the other languages have. Groovy's problem has been the execution: the speed and the implementation. So far, Groovy has lacked the sound, technical underpinnings of the other languages in this chapter, as well as a visionary to both innovate and see inventions through to a sound, stable conclusion.

In favor

I want to like Groovy. I really do. It has the marketing support, hype, and attention in the Java community. It runs in the virtual machine, ties in well to the Java language, and has political backing from Sun. James Strachan, a hero of sorts within the Java community, is the primary father, bringing an instant fanfare and credibility to the project. With a formal JSR, it's usually easier to introduce Groovy into a company as a scripting language than some other dynamic language. The syntax, though inconsistent, is terse, and the Groovy JSR supports many of the important features that dynamic languages should, at least in letter.


The problem is that Groovy is just so hard to like. To this point, Groovy has been quirky, unpredictable, and full of bugs. Many features, introduced in very early versions of Groovy, remain uncompleted, and early shortcuts led to an unsound grammar. Early versions of Groovy used a hand-generated parser rather than a parser generator, such as ANTLR. After the syntax was belatedly retrofitted to ANTLR, the syntax was set in many ways, and the grammar was unwieldy.

Today, the fledgling language continues to struggle. People leading the project seem to be more interested with introducing new ideas than finishing old ones. Blogger Mike Spille was a Groovy insider who worked on the language, and later abandoned it due to significant problems with the language, technical vision, and stability. He pointed out major holes in the language and syntax around closures (a kind of code block) here: You can also see a later heated debate between two of the early Groovy contributors on here:

It seems like each major beta release breaks existing Groovy applications. Worse, the first major Groovy specification request broke existing applications. That's not good. Many of the core Groovy developers also seem to be leaving the original JSR team.


With a formal JSR backing it, Groovy is politically in a good place to succeed. After all, you could argue that EJB succeeded based on the reputations of the supporters, despite significant technical limitations. Groovy has some energy and hype, but a few false starts seem to be stalling the momentum. I'll undoubtedly get flamed for saying so, but right now, Groovy is much too young and too unstable to deserve serious consideration for any production application, let alone standardization.

That Groovy is buggy and unstable as a beta doesn't trouble me so much, though you'd expect core language features and syntax to be set very early, but basic features like closures don't work. I'm most concerned with the overall process. The community process standardized the Groovy language before it was mature, or even stabilized. To move forward in a productive way, Groovy must first solidify the major feature set, then recover some lost momentum, and then prove itself in some commercial niche before it will be considered as a significant candidate to replace Java anywhere. Until then, it's merely an experiment. I hope it succeeds, but I don't think it will. It simply has too far to go.


.NET is the only nonprogramming language that I've mentioned as a credible successor to Java. .NET is Microsoft's latest development platform, deserving special mention because it has a massive library, and a language-agnostic engine called the Common Language Runtime (CLR) that sits on top. If Microsoft makes .NET successful, and truly language-neutral, it could serve as a launching pad of sorts for many languages. Right now, like the JVM, the CLR has some technical issues to overcome before it can fully support dynamic languages like Ruby, but Microsoft is committed to doing so.

Language options

At some level, the programming libraries underneath .NET are far more important than the language. Their usage models frequently dictate application structure, often more than the choice of programming language. Still, Microsoft offers several programming languages, targeted at vastly different communities.

Visual Basic for .NET

Microsoft has a real problem on its hands with Visual Basic programmers. It seems many of those hundreds of thousands of active developers just don't like .NET, and they're looking for alternatives. The .NET framework changed the programming model for Visual Basic. So far, most of them either are actively deciding to pursue alternatives, or are passively waiting to upgrade. Either way, Microsoft loses. As a result, it looks like Visual Basic is in trouble.

In public, Java and .NET developers don't mix, but each community often reluctantly admits the strengths of the other. While married to a platform, Java developers have often stolen secretive longing looks at Visual Basic's productivity and user interface development framework. Visual Basic users secretly returned the flirtations, admiring Java's structure, if not productivity. I'm making an educated guess that Microsoft thought it could sneak in some more structure, believing that the BASIC syntax would trump the unfamiliar frameworks underneath. They were wrong.

Microsoft is making some moves toward satisfying the Visual Basic community. Some plans seem to favor a Visual Basic classic edition, which looks and acts more like the Visual Basic of old. To me, that move smacks of new Coke and Coca-Cola Classic, a public relations disaster.


C# (pronounced see sharp) is a programming language that fills the role of Java for the .NET platform. You'll see a few minor exceptions, like reliance on unchecked exceptions rather than checked exceptions, and some syntactic sugar. Many of the recent changes in Java, like annotations and autoboxing, were introduced to keep up with .NET. For the most part, though, those looking to trade in Java and simultaneously lose their problems will find a whole new stack of problems, with a similar size and shape. C# is merely Java's evil twin.

Still, Microsoft seems willing to separate old versions of C# to a new language, under development, called C Omega . This language would potentially make some significant strides forward, and possibly even break compatibility with C#. Such a language could potentially offer the features of much more dynamic languages, with the commercial backing of Microsoft, and the CLR as a portable virtual machine. It bears watching. Still, it's proprietary, and many won't give it a serious try for that reason alone.

Other languages on the CLR

What's intriguing about .NET is not the Microsoft languages. It's the promise of open source languages on the CLR. Right now, since most of Microsoft's energy is undoubtedly focused on Visual Basic, C++, and C#, you're not going to see a library that's built to take advantage of important concepts like code blocks and continuations. Still, Microsoft actively courts insiders in the Ruby and Python communities, so you could see credible implementations of those languages soon.

A weakness and a strength

.NET and the CLR have one major problem: Microsoft. Sometimes its weight and muscle work in your favor, and sometimes they don't. It's not likely that the CLR will ever run as well on other platforms as it does on, say, Linux. With Microsoft's heavily proprietary stance and a complete lack of portability, it's tough to see the Java community embracing .NET. You may be surprised that I don't think Microsoft's posture will remain so pervasively proprietary, especially on the server side.

I've said before that market leaders want to be proprietary. All others need open standards to compete. Microsoft is simultaneously the market leader for client-side operating systems, and lumped in with everyone else (or with Internet and Enterprise development). Proprietary frameworks make sense on the client, where Microsoft has had a near-monopoly for a long time now. They make a little less sense on the server side, where they've been unable to crack the market for medium and large systems. In time, I believe that Microsoft will recognize this reality and jump on the open source software bandwagon. I'm not the only one who thinks so. I sit on the expert panel of NoFluffJustStuff, one of the most successful and influential Java conferences outside of JavaOne. Stuart Halloway, one of the most respected Java consultants in areas such as metaprogramming and reflection, feels strongly that Microsoft will be the biggest open source vendor in the world, and Dave Thomas seems to agree.

If Microsoft does happen to move toward open source software in a credible way, and the Java community recognizes this, Microsoft will open the door to Java on the CLR, and more importantly, to the languages beyond.