O''''Reilly Network For Information About''''s Book part 16 docx

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.