Generating the Buzz

Many languages have trumped Java technically, but they still failed. Betamax, too, was technically better than VHS. The biggest factor of the equation is social. Without a credible community, there can be no success. To a programmer, a language is an investment in a future, and even an identity. Call it marketing, or buzz, or even hype. If it's hip, or at least interesting, a language stands a fighting chance. If not, there's no chance at all. In some ways, Java helped pave the way for the next language:

  • Communities like TheServerSide and Slashdot provide a forum for new ideas to spread quickly through the Java and non-Java programming communities. It's much easier for smaller projects to create a big buzz.

  • The increased emphasis on open source software, partially driven by Java, makes it easier to wrestle control away from larger companies. Also, those same companies find open source technologies easier and less threatening to adopt.

  • Many Java standards like Web Services (and lightweight HTTP alternatives) make it much easier to interoperate between languages.

  • The JVM will run other languages. A new language on the JVM is a much easier sell than a new language in a new environment.

Still, the challenges of establishing a community are daunting. Microsoft has spent millions of dollars promoting the .NET environment, and the adoption on the server side is still nowhere near Java's adoption, though many of the features and capabilities are similar or superior to Java. Sun, for all of its success with the Java platform, has not been able to capitalize on it in the software realm. Adoption of Sun application servers and management software has been spotty at best. IBM lost the battle of the operating system because it couldn't market a technically superior OS/2.

Programmers are a schizophrenic lot. One moment, we're the ultimate skeptics, ditching the safety of the Microsoft Windows environment for unpredictable Linux systems on our desktops. The next, we're lemmings, adopting hideous architectures like EJB without the slightest bit of proof. You also have many different niches within the programming community. Java's been successful for enterprise developers, but hard-core hackers in the Perl and Python communities frown on Java. And Microsoft developers form cultures all their own, with subcultures in it that favor C++ or Visual Basic.

That means the winning formula will also change. At one point, a dominant personality like Steve Jobs may make the difference, and the next, like with the star-crossed NextStep platform, it's not enough. This is all to say that generating buzz is more art than science, and maybe more luck than art. Still, certain themes and trends ring true.

Open Source

Unless it's a disruptive technology, it's hard to imagine the next major programming language coming from a larger commercial vendor. There's just too much fear and distrust among the major players: Microsoft, IBM, and Sun. Instead, I think a credible alternative is much more likely to emerge from the open source community. The open source model provides a stage for thousands of projects, where they can succeed or fail based on their merits. Projects need to prove effective technologies and marketing amid a cynical, critical audience to succeed. There are several interesting test cases in the open source community now: Perl, PHP, Python, Ruby, and many others. You see far fewer commercial languages with any degree of momentum. The biggest, C#, is effectively a Java clone.

Open source software has something else going for it. Since open source projects usually have no formal support, the community must support the language. This environment tests the community dynamics for a language as well as the technology. Communities take on a personality, like snobbish, edgy, nurturing, or bickering. Larger languages like Java may have subcommunities with personalities all their own. When a language gets sudden attention, the personality of the community will either attract or repel new users. Fine-tuning community dynamics is a difficult proposition, because this personality may be hard to judge from the inside. A new language will need an attractive community to succeed, and the open source community seems like a natural place for that to form.


While open source frameworks usually lend a certain intellectual honesty to a project, commercial forces will have the deciding vote. A new language needs a supporting ecosystem to thrive, and that means someone has to write a check eventually. Simply put, you can't move away from Java without economic justification. To me, the leading potential economic catalyst is clearan overwhelming advantage in productivity.

When I stepped away from Java for the first time, I needed an economic mother bird to nudge me out of the nest. Java's just too safe and too comfortable otherwise. We're writing a Java application to help engineers configure equipment that measures safety systems in manufacturing plants. I recommended moving the application from Java to Ruby midstream because I found the difference in productivity between the environments too great to ignore. Further, when all was said and done, the new application was easier to maintain with fewer lines of code, it was fast enough, easier to tune, and easier to extend with security. I'd estimate that we're three to five times more productive in Ruby. Certainly, Ruby is not the only language that's more productive than Java, but it's an interesting test case. You'll see more in Chapter 7. Productivity will be the economic catalyst that begins to chip away from the Java base. Productivity will drive the emergence of the next great language.


When you look at early adoption for all major successful languages, one of the key issues is approachability. New languages need to grab new users quickly. You should be able to get started quickly, and solve a problem that's important to you immediately. C was approachable because it let hard-core systems programmers solve low-level problems in a high-level language, with much better performance and flexibility than other high-level languages. C++ was approachable because you could write C without modifications, and upgrade to C++ features as you wanted to include them in your programs. Java was approachable because it had a familiar syntax, a friendlier memory model, and a clear, consistent path to Internet solutions. Smalltalk was not approachable, because vendors charged too muchit was too expensive to play.

Though nothing simple has a C++-like syntax, I still think that many languages are approachable because of their friendly, productive syntax with a familiar object model. Python versus Ruby is a good example of differences in approachability. Ruby has one of the most highly productive web environments, and a community and philosophy focused on getting programmers off of the ground quickly and painlessly. You can install components easily, often with two or three words, using a feature called Gems that does the work for you, provided you have an Internet connection. Python, on the other hand, has a simple language and syntax, but the web libraries are nowhere near as approachable. When you start to learn one of them, you don't find the ready tutorials or community reaching out to help you. The Ruby on Rails people understand how to make Rails approachable.

The Killer App

Without some kind of catalyst, it's difficult to imagine how a successful community ever gets started. Applets let Java spread to many desktops quickly. Developers could embed dynamic content into their web pages in a matter of hours.

On the surface, it seems like a language must have a vibrant community to ever get rich enough to succeed on any scale, but the community usually won't come until the language is rich enough. A killer app to a developer is a solution that is so compelling that it transcends language. It alone can rapidly drive community growth. It's not the only way a language can succeed, but it's certainly the most likely way.

The killer app is a popular notion of a catalyst. A killer app solves an important problem in such a forceful way that users are compelled migrate. Think California gold rush. People often point to the Lotus 1-2-3 spreadsheet as the killer app that moved businesspeople to Microsoft Windows. Meanwhile, the killer app for OS/2 never came. For Java, you could easily argue that Netscape made it all possible by putting Java on the desktop of millions of potential developers. Applets, or the idea of deploying applications in a browser, also played a significant role, and it's that concept that morphed into servlets and server-side Java programming. The killer app is a seductive idea, because it encapsulates so many important concepts:

  • The catalyst, with economic justification, often takes the form of a killer app .

  • Once a solution is technically viable, a killer app enables a rapid growth to critical mass. It often solves a chicken and egg problem: you can't build a sufficiently robust language without community, and you can't build a community without a successful language.

  • The killer app often initiates the hype that's required to escape a niche. With the newly found hype, the language can explode from a small, focused niche to a more generally successful language.

Remember, a language alone is rarely enough. Right now, several interesting technologies could possibly grow into potential killer apps. Smalltalk's continuation servers, Ruby's metaprogramming environments, and PHP's many applications like bulletin boards may serve as potential killer apps. We'll look at some potential killer apps in Chapters 7 and 8.

Table 5-3 lists community-centric roles . Each of them will come into play when it's time to determine the next major language.

Table 5-3. Community-centric roles



Open source

Have a rich open source community.


Be much more productive than Java for the simplest commercial applications.


Have a tremendously popular application or framework that transcends programming languages.


Be easy for Java developers to learn.


Make it easy to solve simple problems.