5.2. Enterprise Integration In some ways, C redefined enterprise integration, by allowing strong database connectivity across an open API (ODBC for Microsoft applications) and providing transaction monitors like Tuxedo and Encina. C was disruptiveit introduced enterprise programming beyond mainframes. Java continued this legacy with frameworks for transactions, rich database integration, messaging, and many other forms of plumbing code called middleware. I don't think the next major applications language will initially have to have th e full enterprise capabilities of C or Java to succeed. Visual Basic certainly achieved tremendous success without these capabilities by leveraging the services provided by other frameworks written in lower-level languages like C. We've already determined that the next language should interoperate with other Java programs, hopefully within the same virtual machine. It should also interoperate through a coarse-grained service layer. That said, some enterprise capabilities will be very important. 5.2.1. Database Integration Minimally, a new language should access relational databases in a natural, productive way. I don't think any particular application style is importantyou can see wildly successful environments with different strategies: Microsoft builds a framework that leverages the power of SQL , row sets, and relational databases. The center of the Microsoft universe, from a data perspective, is the relational database. The strategy can scale very well and is surprisingly productive. Java, instead, seems to be moving toward ORM. The center of Java's data universe is an object-oriented, persistent model. Other Java applications leverage JDBC with helper frameworks quite successfully. Ruby on Rails takes an intermediate approach. Rails wraps a database table with objects that discover the structure of the database dynamically. All strategies have strengths and weaknesses, and each could serve as an effective foundation for a new language. I do think that emerging languages, and the core frameworks they need, should try to follow these rules: Embrace the relational database While a language may integrate with alternatives, the relational database should be a first-class citizen. Too much focus on object-oriented databases proved to be a problem for adoption for some Smalltalk frameworks. Object- oriented databases are an elegant solution that ignores the current political realities. Don't force structure on the relational database At some level, a language must make it easy to use existing relational schemas, as they exist. Forcing a surrogate unique identifier rather than a composite primary key also ignores existing realities. Perform, and scale High database performance is the single most important indicator of good application performance. 5.2.2. Transactions and Security Enterprise developers need the ability to define a business transaction. It doesn't matter how fast you can build incorrect applications. If Joe Bob loses $50 in an Internet transaction because Sally Sue crashed the server by tripping on a power cord, the framework is not going to make it in the enterprise. Security is also important, though you could probably argue over how important it could possibly be with the gaping holes in operating system security today. Java has set a bar that's going to be pretty hard to clear in this area. The next big language will need the ability to integrate with existing enterprise security frameworks, at least the Internet-based schemes and standardized ones like LDAP. Table 5-2 summarizes the enterprise features a new language will need. Table 5-2. Enterprise requirements for a new language Rule Description Database access API Provide a clean, productive API for database access. Relational databases Focus on relational databases first. Database performance Database interactions should be very fast. Transactions Enable application transaction demarcation. Language security Provide a clean foundation for language security. Application security Let developers secure their applications. Security integration Let developers integrate enterprise security, especially for Internet applications. Like the Java features, having these basic enterprise features does not guarantee success. They just let you play the game. 5.3. 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 se rvers 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. 5.3.1. 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 a mong 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 at tractive community to succeed, and the open source community seems like a natural place for that to form. 5.3.2. Economics 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. Recall that as I write this book, I am calling the shots for a start- up. 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 time s 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. 5.3.3. Approachability 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 mo difications, 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 w ith 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. 5.3.4. 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 mill ions 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 Rule Description Open source Have a rich open source community. Productivity Be much more productive than Java for the simplest commercial applications. Catalyst Have a tremendously popular application or framework that transcends programming languages. Familiarity Be easy for Java developers to learn. Simplicity Make it easy to solve simple problems. . language should access relational databases in a natural, productive way. I don't think any particular application style is importantyou can see wildly successful environments with different. 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,