8.6. So What?
I'm pretty sure that continuation servers will prove to be important. I'm equally
sure that Seaside is not a killer app that will suddenly spring Smalltalk into the
mainstream. Smalltalk has 30 years of reputation to overcome. In this time,
Smalltalk has rarely been more than an academic language with small forays into
commercial development. The Smalltalk community is smart and has technical
vision, but I've not yet seen the marketing leadership that will break Smalltalk into
the mainstream. After 30 years, that's not likely to change.
Continuation servers do have some minor hurdles to overcome:
 So far, the servers require ugly, temporary URLs, because each continuation
must have a unique identifier. Users don't like uglier URLs. Like Amazon,
Seaside works around this limitation by providing a meaningful piece of the
URL, followed by the continuation ID.
 Continuation servers will not scale as well, because saving continuations is
stateful and expensive, though if you think about it, the problem is not quite
as bad as it could be. Most of the continuations in a server will have
common code for the framework. Only the last part of the call stack should
be different from one continuation to the next. Partial continuations should
provide a good performance boost.
 So far, the best servers are on academic languages. Lisp, Smalltalk, and
Ruby may be holding them back. And of course, continuation servers may
help break one of those languages closer to the mainstream.
Still, in the end, continuation servers will play a role, because they're a much more
natural and powerful abstraction, and they represent a much more natural way to
program. Systems continually get more processing power, and both short-term and
long-term storage get cheaper. Productivity eventually trumps all else. In the end,
continuation servers are fast enough. Higher abstractions make us more productive.
If you held a gun to my head and forced me to make a prediction, I'd guess that
continuation servers will evolve and break into the mainstream, but not on Java, or
a derivative like C#. Such a language would have to simulate continuations. The
concept is cleanest and purest when it is implemented on a more dynamic, higher-


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 Amazon.com. 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

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. 9.1.1. Ruby
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.
9.1.1.1. 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.

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 e
ducators. 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 m
ight 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.
9.1.1.2. Against
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,

the most likely candidate.
9.1.2. Python
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
python.org:
def invert(table):
index = { } # empty dictionary
for key in table.keys( ):
value = table[key]
if not index.has_key(value):
index[value] = [ ] # empty list
index[value].append(key)
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.
9.1.2.1. 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

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.
9.1.2.3. Overall
Python has most of the ta
ngible 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 J
ython 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.
9.1.3. Groovy
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

You
can also see a later heated debate between two of the early Groovy contributors on
TheServerSide.com 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.
9.1.3.3. Overall
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.
9.1.4. .NET
.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

) 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 b
e 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.
9.1.4.4. 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.
9.1.4.5. 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