Beyond Java/Contenders

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Initial conversion from Docbook)
(Initial conversion from Docbook)

Revision as of 17:12, 17 March 2008

Beyond Java

It was my first Class IV river, and I approached the infamous Five Falls. In the typically tame Ouachita mountain range, the Cassatot—Indian for Skull Crusher—was serious. In all honesty, I wasn't ready for the river. Unseen gremlins sent massive jets and waves of water shooting through the waterfalls and toyed with me, smashing my boat against rocks, turning me around, and flipping me over at will. Yet, my guide seemed in complete harmony with every molecule of the river. He harnessed all the power the rapids threw at him, and danced his boat across the many chutes, waves, and even face of the waterfall known as the Washing Machine.

Throughout the run, every inch of my body hurt as I learned to push off my foot braces to integrate the rarely used leg muscles into every stroke, because on this particular river, I needed all the leverage I could get. At the takeout, exhausted, I slithered out of my boat. My guide hobbled out of his boat, and I couldn't speak. Both of his legs were amputated above his knees. I was stunned. He was able to do everything on the river without the added balance and power that two legs would have given him. Those few seconds completely changed my perception about what was possible in a kayak. More than any other, that moment shaped my paddling. Since I know how far I can come, I've always been looking for ways to use the boat, paddle, body, and river to do more work with less effort.

If nothing else, this book is about changing perceptions. Sure, the Java libraries have legs—libraries and community. But the community can be dysfunctional at times, and the culture is leading to increasingly complex libraries. The JCP seems to be getting in the way, valuing politics and committees more than good libraries hardened in the crucible of experience. There's something to be said for a fresh start on a stronger foundation.

So, don't let Java's built-in advantages always lead you to sell the alternatives short. They've come a long way. In this chapter, I'll touch on the major contenders and some also-rans.


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, but this book wouldn't be complete without at least mentioning some of the major alternatives. 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. I like short books, so there's not enough time to do a remotely comprehensive treatment. Even 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.


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.


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 for—a 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. There's not much to say about C# in a book called Beyond Java, because it's built to be similar to Java. 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.

Minor Contenders

Now, it's time to put on an asbestos suit and my +4 plate mail. I debated whether to include any sections on Perl, Lisp, PHP, or Smalltalk. They're fantastic languages in their own right. I just don't think they're next.

If you're deeply religious about any of these languages, you can just read these one-sentence summaries, and skip to the next section: Perl's too loose and too messy, PHP is too close to the HTML, Lisp is not accessible, and Smalltalk wasn't Java.

If you already feel slighted and you must read on—if you're a language cultist and I've mentioned your pet language in also-rans, or worse, didn't mention your pet language at all—go ahead and fire up your Gmail client and your thesaurus, and drop me a nasty note. Ted Neward reviewed this book, so I can take a few more euphemisms for the word sucks. Just keep this in mind: I'm not saying that your language isn't good, or popular. I'm just saying 10 years from now, we probably won't look back at any of these languages as the Java killer.


PHP is an open source scripting language that's been gathering momentum since the early 2000s. It's a markup language that's designed to be embedded into HTML. It's very easy to quickly develop simple web applications in PHP, but those applications typically have little back-end structure. For these reasons, it's not really targeting the same niche as Java applications, though it's sometimes been pressed into service in much the same way. Here is "Hello, World" in PHP:

        <title>Hello, World</title>
        <?php echo '<p>Hello World</p>'; ?>

Web programmers recognize this as an HTML scripting language. The code is processed on the server side, so pure HTML can be sent down to the client. It actually handles this kind of scripting pretty well, but it's purely a tag language. PHP's problem is the structure behind the view. It's possible to use PHP for layers behind the view, but it's awkward and cumbersome in that role.

PHP is going to make some serious noise as a pure web-based scripting language, though. In one of the strangest moves in 2005, IBM announced support for PHP. This move undoubtedly targeted the small and medium-size businesses that tend to embrace PHP. IBM can now theoretically sell them software and services to round out their implementations. PHP seems to be a natural language for those Visual Basic users who don't want to make the move to .NET. Like Visual Basic, it will be pressed into service in places where it doesn't fit as developers search for simplicity in the wrong places.

With the most basic Google skills, you can find dozens of papers that attempt to compare Java and PHP. You'll tend to find two types of comments. The PHP camp says that Java isn't productive enough, and the Java camp says that PHP isn't structured enough. I tend to agree with both of them. The primary danger with PHP for small applications is that they can grow into big PHP applications, and you're left without the structure that will let you easily maintain and extend your web applications.


Perl is a very popular language for programmers who look for raw first-cut efficiency. Perl was quite popular for shell scripts, before simpler alternatives were available. In terms of productivity, Perl has many of the characteristics of other highly productive languages. It's very expressive, terse, and dynamically typed. It gives you freedom to do what you want to do, and has a rapid feedback loop. Paul Graham calls it a great language for "hacking," or rapid experimental programming. Much of the Internet is powered by CGI Perl scripts.

Perl does have a downside. When you look at overall productivity of a language, you've also got to take things like maintenance and readability into account. Perl tends to rate very poorly among experts on a readability scale. As with Java, much of Perl's problem is cultural. Some Perl programmers would rather chop off their little finger than type four extra characters, whether the characters improve readability or not. After all, programs that were hard to write should be hard to read. Other Perl problems relate to the language itself. Perl's object orientation is obviously bolted on, and Perl has a secret handshake of sorts, in the form of many cryptic syntactic shortcuts that only the mother of Perl could love. A whole lot of us at one time or another have had some sort of love/hate relationship with Perl. It's interesting to talk about, but it's pretty much the antithesis of Java, and it's likely not going to make a dent.


Smalltalk is a beautiful language invented way before its time. Smalltalk and Lisp are probably the two languages that share the most with Ruby. Smart developers used Smalltalk to build successful object-oriented applications long before Java was even a twinkle in Gossling's eye. And not-so-smart developers used Smalltalk to build some of the ugliest object-oriented code ever written. In truth, for the most part, in the mid- and late 1970s, we just didn't have the wisdom or the processing power for OOP yet, and we didn't have features like just-in-time compilers.

In Chapter 8, you saw the elegance of the Smalltalk language. It's object-oriented through and through, and the syntax is remarkably consistent. Smalltalk's syntax probably seemed strange to the masses of programmers who grew up coding COBOL, BASIC, Pascal, C, or C++. Most of the businesses I know of that actually tried Smalltalk were able to get their applications out in time, they just never were able to integrate those applications with the rest of the world.

Smalltalk never was able to lure C and C++ developers away, because it was too alien and had the perception of being too slow. As the small Smalltalk community waited for objects to emerge, Java's founders aggressively grabbed the C++ community by the throat, forced it to come along with C++ syntax and usage models, and offered solutions to solve the most pressing problems the C developers encountered. As we showed, Java was effectively a compromise between perfect OO and the C++ community. Later, IBM made a move to buy OTI, a maker of Smalltalk virtual machines. In one last push for Smalltalk, IBM built a common virtual machine into an IDE called Visual Age with the hopes that the common JVM could lend credibility to Smalltalk. It was too little, too late. We were too content in our newfound freedom, safely and freshly away from all things C++, in the arms of Java.

It's hard to imagine Smalltalk rising up from 30 years of obscurity to dominate. It's probably not going to happen. Still, you can find a small but active community of Smalltalk developers. Disney built Squeak, a Smalltalk dialect and implementation focusing on multimedia. A handful of other dialects are also still around.

In the end, Smalltalk may yet make an impact on development, but as the proving ground for ideas like continuation servers. You'll find evidence of Smalltalk's object model and syntax everywhere. Most notably, Ruby liberally borrows code blocks and idioms like returning self. I think continuation servers will ultimately play a role in web development. They just make too much sense, are too natural, and are too compelling. Smalltalk is where all the continuation research is happening.


Lisp is an extremely powerful language that excels in its strange but pure syntax, abstract modeling, and raw efficiency. In Lisp, everything is a list, including Lisp programs. Metaprogramming in Lisp feels natural, and is quite popular. Important ideas like aspect-oriented programming and continuation servers started in Lisp. Several dialects like Dylan and Scheme appear periodically, but none has achieved much success in the commercial mainstream, beyond a macro language for the Emacs. Still, start-ups often use Lisp because once you learn it, you can be incredibly productive. Some very successful programmers like Paul Graham (author of Hackers & Painters) believe Lisp is the most expressive programming language, and they could be right.

Lisp's community has always been made up of intelligent developers, and it's still popular among academics. In fact, some of the best programming universities, like MIT, emphasize Lisp early, to get students to quickly think in the abstract, and to expose them to functional techniques.

Maybe all languages will once again return to Lisp, but I don't think that Lisp itself is the ultimate answer. It's just too alien, and it takes too much time and effort to learn.

Functional Languages

It's probably a bit too early to be talking about functional languages , because we seem to be moving toward object-oriented languages instead. Still, functional programming provides a higher abstraction and very good productivity. It's possible that some functional language could explode, with the right killer app.

Haskell and Erlang are two of a family of programming languages called functional languages. Functions are the focus of functional languages. I use the word function in the pure mathematical sense:

  • Functions have no side effects. This oddity takes some getting used to for most procedural programmers, but also has significant benefits.
  • Functions return values.
  • You can use the return value of a function anywhere you can use the returned type.

You can do functional programming in languages like Ruby and Lisp, but for research or purity, often it's better to use a purer language. Here's a Haskell example, which computes the factorial of a number:

    fact 0 = 1
    fact n = n * fact (n - 1)

Then, as expected, you can compute the value like this:

    fact 10

Here's a Fibonacci sequence (where each number is the sum of the previous two):

    fib 0 = 0
    fib 1 = 1
    fib n = fib (n-1) + fib (n-2)

Functional languages let you work at a higher level of abstraction. Haskell has good traction in research and academic communities, and seems to be gaining a small, vibrant commercial community. It's easy to teach, and as such, it could provide a doorway into functional programming, much like Pascal provided a doorway to procedural languages.

You can see the power of functional programming in the Erlang language. Developed at Ericsson, Erlang's main focus is concurrency. Erlang lets you easily create and use threads, and communicate between them. Erlang also improves distributed computing, because the location of threads is transparent—a thread might be in the same process as another, or on a different machine. It's productive, dynamically typed, garbage collected, and very small. There's been a recent spike of interest in Erlang for applications that need excellent support for concurrency and distribution. It's used in production at some high-profile sites. At this point, Erlang is still in its infancy as a general-purpose language. Users tend to use it in conjunction with C (for better performance), and it doesn't have any real user interface library. Still, Erlang is powerful in its niche, and it could make an impact in the intermediate future, directly or as a derivative.

The Next Big Thing

Of course, the whole premise of this book is arrogant beyond belief. I'm making an incredible number of assumptions and drawing some aggressive conclusions based on little more than a couple of dozen interviews, a keen sense of intuition, and a few massive piles of circumstantial evidence.

Java may need nothing more than a little overhaul. Maybe the problem is in the massively complex libraries, and a few rewrites with some tweaks of the language would extend Java's leadership for 10 more years. Maybe the community's culture doesn't help define our libraries. The driving vendors may do an about-face and focus more on simplifying the 80% path instead of building yet another XML-obsessed framework. The JCP could suddenly start supporting the best existing frameworks based on experience instead of standardizing a good idea that was born in a committee.

Maybe Dion Almaer is right, and the big companies that drive this industry are not remotely interested in moving away from Java, and we'll all be saddled with Java for the foreseeable future.

Maybe Jason Hunter is right, and the next big thing won't be a programming language at all. Maybe Java's all we'll ever need, and we'll use that foundation to move up the abstraction ladder. Maybe Glenn and David are both right and there won't be one next big thing, but lots of next little things, and both metaprogramming and continuations will play a significant role.

I don't know the ultimate answers, so I've leaned on my mentors and peers. The interviews in this book are the opinions of some of the people I respect the most. It's been an honor to share these few pages with them. I'm not ready to say that Java's dead, or that Ruby is next, or that continuation servers will reign supreme. I just know:

  • I'm hurting right now, and my customers are, too. It's getting harder and harder to teach my customers to satisfy themselves with Java.
  • Certain things, like baby-sitting a relational database with a web-based UI, should be easier in Java, after nearly 10 years of effort, but they're still cumbersome.
  • The same people that dozed in conversations about other languages two years ago seem to be paying attention now. My "Beyond Java" talks, at Java conferences, are continually packed.

As for me, my eyes are wide open. I've seen what the alternatives can do. In particular, Ruby on Rails lets me build reliable code fast, and put it in front of my customer with more confidence and frequency. I didn't actively seek an alternative—on the contrary, with four Java books out and a reputation in the Java space, I've got every reason to maintain the status quo. I did find that some of the alternatives are compelling, and make for a smooth transition.

A Charge to You

If you're a Java developer and this message is troubling you, that's natural. You've got good reasons to feel threatened with this challenge of your world view. You may feel even more unsettled when someone challenges the foundation of your livelihood. I'd encourage you to put this book down and do some research of your own.

Look around. When James Duncan Davidson did, he found a language that responded to his needs for low-level user interface development. Stuart Halloway found a language that let his start-up move at the speed of his ideas. Dave Thomas found the foundation for an increasingly important publishing series. Glenn Vanderburg found languages friendlier to his beloved metaprogramming techniques.

If you decide to expand your horizons beyond Java, you may find that I'm right, and some of the alternatives I've explored here, or even some I didn't, unleash you. You'll be surfing the next wave that propels us forward.

If I'm wrong, Java will still be there for you; heck, even COBOL is still there for you. But to you, it won't be the same Java. Other languages will expand your horizons to other approaches, just as a wave of Java developers will bring our unique view of the world with us. If you spend some time in Smalltalk, you'll probably use Java's reflection more, you'll look for more opportunities to invert control by simulating code blocks, and you may well tone down your use of XML. (OK, I may have pushed things too far with that one.) If you explore continuation servers, you may look for a way to simulate that programming style in Java. If you explore Rails, you'll likely learn to pay more attention to defaults and convention. Hibernate, Spring, Struts, servlets, collections, and the JDO could all use these techniques.

Pick up your eyes by learning a language. Expand your mind to something a little more powerful, and a lot more dynamic. Warp your perspective to functional programming or continuations. Annoy your friends with a contrarian's view. Tell them that you don't think the world's flat. There's a whole universe out there, beyond Java.

Personal tools