Beyond Java

Anml4ixoye writes "I recently got sent a copy of Bruce Tate's newest book Beyond Java - A Glimpse at the Future of Programming Languages. Having read Bruce's Bitter Java and Better, Faster, Lighter Java, I was intrigued to see what he would have to say about moving beyond Java. In short: If you're a hard-core Java (or to a lesser extent, C#) developer who thinks Ruby is something that goes on a ring, Pythons will bite you, and Smalltalk is something you have to do at parties, you are in for a rude awakening." Read the rest of Cory's review. Beyond Java: A Glimpse at the Future of Programming Languages author Bruce A. Tate pages 185 publisher O'Reilly rating 9 reviewer Cory Foy ISBN 0-596-10094-9 summary Excellent book for Java developers who haven't been exploring what else is out there

Let's get down to it. For many people, Java pays the bills. For dealing with big problems, it is a wonderful language with a myriad of libraries for solving domain-specific problems. The author thinks that this focus on the larger applications is causing Java to alienate the developers who need solutions to small, real-world problems, like babysitting a database with a web site.

Bruce starts out in Chapter 1 discussing a disrupting experience he recently had when he discovered how much faster and more productive he and his team were when they switched mid-stream to Ruby on Rails. He gives some controversial numbers that discuss this improvement. This experience leads him to realize that maybe Java is dying - or at least fading in certain areas.

His next sections (Chapters 2 and 3) discusses the "Perfect Storm" that led Java to become the leader it is today. How it traded the OO purity of Smalltalk to woo C++ developers. And how the programming environment was calling out for a language like it.

But that landscape is changing, and Java is having a hard time keeping up. In chapter 4, he gives an example of servlets. Earlier servlet specs allowed you to get a Hello, World servlet, albeit ugly, up rather quickly. That same example now requires deployment descriptors, packaging into WAR files, configuration files, etc, etc. For Java developers, this is the norm, but for a developer new to Java, who wants to learn all that?

Chapter 5 is a discussion of what Bruce feels is the Rules of the Game, or what the next "Killer language" will need in order to beat out Java. This was a very good treatment, highlighting some of the good and bad of Java and languages as a whole. For example, he rates high that you will need some sort of Enterprise Integration, Internet Focus, and Interoperability. He also feels things like dynamic typing, rapid feedback loops and dynamic class models (making reflection more natural).

Most importantly, it needs a killer app to act as a catalyst to get people's mindsets changed. In Chapters 6, 7 and 8, he gives examples of some killer apps - Ruby on Rails and Smalltalk's Continuation servers (like Seaside). Chapter 6 is a kick-in-the-teeth intro to Ruby (which left me wanting to go out and pick up Dave Thomas' Programming Ruby book). Chapter 7 shows a sample Ruby on Rails application, and Chapter 8 gives a very interesting look into Continuation servers and the work being done by the Smalltalk community on it.

Finally, he closes the book with a list of Primary and Secondary contenders that could up and replace Java. Primaries include Ruby, Python, Groovy, and .NET (C# and VB.NET). Secondary contenders include Perl, Smalltalk, PHP and Lisp, which he summarizes as: "Perl's too loose and too messy, PHP is too close to the HTML, Lisp is not accessible, and Smalltalk wasn't Java". To which he adds, "...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".

Thankfully there is nothing in this book that would cause me to write a nasty note to Mr. Tate. In fact, if you haven't begun looking at other languages and are heavy in the Java world, I would highly recommend picking up a copy of the book. It's a fast, intriguing read with great insights and the chance to save yourself from looking around 4 years from now wondering what the heck happened, and why all of these developers can afford jewels and play with snakes while chatting among themselves."

You can purchase Beyond Java: A Glimpse at the Future of Programming Languages from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

D programming

[AeiwiMaster]

I think digitalmars D is the next big language.

See it here http://www.digitalmars.com/d/

Re:D programming

[AeiwiMaster]

Take a look at this Computer Language Shootout

C#

[blaster151]

I find C# to be far and away the most productive and efficient language I've ever worked with. This is, of course, due in large part to the robustness of the .NET class framework and the top-notch development environment. To me, it was a significant step up from Java (although I understand that that's a subjective statement). As someone who has been working professionally with C# for years, and who has found it to be a much faster way to deliver quality production code, I contend that C# is the true benchmark: Java has already been superceded.

Re:C#

[Anonymous Coward]

>> To me, it was a significant step up from Java

How so? Most of the useful C# bells and whistles were added to java 1.5.
The syntax is almost identical, yet it is lacking in OS independence.

I know mono is coming along, but its not nearly as polished as say, Sun's 1.5 implementation on linux.

There are also free(beer & speech) implemenations like jamvm, kaffe, and gcj along with the gnuclasspath API that are progressing nicely.

Ah. Dynamic typing. Again.

[jameson]

Well, if it's dynamic, it must be good, right?

    I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.

    Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").

    I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.

    Just my EUR 0.018.

-- Christoph

Java's regexp support is yucky

[wurp]

Compared to perl's regexp support, in which regular expressions are first class language features on the same level as strings, integers, arrays, etc., Java's regexp support is laughable.

I only use Perl for quick scripts, but compare the following:

Perl:

/Email\s*:\s*([^\s]*).*?Name\s*:\s*([^\s]*)/i;
($email, $name) = ($1, $2);

Java:

import java.util.regex.*; ...
Pattern emailAndName = Pattern.compile("Email\\s*:\\s*([^\\s]*).*?Name\\s *:\\s*([^\\s]*)", Pattern.CASE_INSENSITIVE);
Matcher matcher = emailAndName.matcher(text);
String email = matcher.group(1);
String name = matcher.group(2);

It is telling that I had to go look up the Java interface (I am a professional Java developer and have been for 8 years), while the Perl came naturally (I am pretty good with Perl, but I only use it for scripting support).

Java does NOT have built-in regular expression support, at least not at all in the same way that Perl does.

Re:Lisp

[Scarblac]

Hey, that's what I was going to post!

I used to work as a Java programmer, then on to Python and Perl. I've looked at RoR, and it's extremely impressive (basically, one guy defined web app best practices for the next decade, I think - not necessarily this particular implementation in Ruby, but the setup of the framework, emphasis on good defaults, sensible object model, well integrated testing, real easy use of Ajax, etc... very impressive)

But then I read Practical Common Lisp. And it rather opened my eyes. Turns out all these dynamic features of Python, Perl, Ruby etc are really just subsets of what's available in Lisp (like those Lisp people always insisted, but I never believed), and it's blazingly fast. It's compiled into machine code. I'm in love.

Right now, the useful Web libraries are just about there, but I don't think they are quite as featureful yet as what we're used to in the scripting languages. But I expect that to change dramatically in the coming year, as so many web programmers are checking out that book...

My first experience with C#

[Weaselmancer]

I program Java. Recently had to do a C# project.

My first thought - Hey! This is a whole lot like Java. Only took me a couple of hours to learn the syntax differences. I'm off and running!

Two hours later I hated it. If you'd like to know why, allow me to offer you the following observation/puzzle.

In C#/.NET, create a form. Put a text box on it, and a button. Have the button create a thread. Have the thread write "Hello world" in the text box.

Because I'm feeling generous, here is the Java code:

private class myThread extends Thread {
public void run() {
jTextPane1.setText("Hello from a thread");
}
}

private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
new myThread().start();
}

Good luck with the .NET code. I'll give you a hint though. It requires a delegate function, because C# .NET forms aren't thread safe. If you manipulate the text box from the thread without a delegate it dies. As a bonus, you get a really illuminating error when that happens:

[System.NotSupportedException] "An error message cannot be displayed because an optional resource assembly containing it cannot be found"

Wonderful language. Really.

Not very insightful

[Ian Bicking]

I have read parts of this book, and still need to write a review of my own since I got a review copy, and that's supposed to be the deal. If you are going to write a book "Beyond Java" you probably should have ventured beyond java a little yourself. I don't think the author did in a signficant way. It includes contributions by other people, but most of those people are primarily Java developers who have history with other systems or are flirting with them currently. This isn't sufficient to give you a feel for the lay of the land. This isn't enough to write a book.

If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.

Re:Ruby's Quite Nice, Really

[masklinn]

Seeing as Matz intend to stay in command of Ruby (as he's been since he created it) and has started a complete, faster, more efficient rewrite of Ruby for Ruby 2.0 (without even excluding possible backward-compatibility breakage for the sake of sanity and efficiency), without the errors of the past (e.g. without the mistakes he made raising Ruby from the beginning to the current 1.8.4) and potentially with a JIT at the end, Ruby doesn't intend to take the path Java did.

And neither does Python, obviously.

So my guess on where they'll be in 10 years: leading, or evolved into a language transcending them both, a better smalltalk, something even closer to Lisp power while keeping a sane, clean, readable, expressive syntax.

Re:(ot-ish) Perl is not too loose and messy

[Anonymous Coward]

Personally I'd just write it like this:

for (@files) {
      print "$_\n";
}

Possibly I might even declare a loop variable if there is any possibility of confusion. I like Perl, in fact it's one of my favorite languages, but I'm not into the golf thing...

Re:Show me the money!

[kfg]

. . .at the end of the day, you work on the systems your employer tells you to. . .

One, you have choice in where you work, unless you're one of Thoreau's wooden men. It is the function of an engineer to select the best tools and materials for the job and apply them appropriately. If that is not what you are doing, then you may well be a programmer, but you are certainly no engineer.

Two, what makes you think my jibe was aimed at the poster? He didn't write his job description.

KFG

Re:It's Too Much.

[pileated]

Bruce Eckel's "Departure of the Hyper-Enthusiasts" might be to your liking:

Re:Dynamic typing

[arevos]

I honestly prefer having types. I prefer people thinking ahead of time about what they are doing, rather than just using a generic object or variant type thing. It's like the databases we have at work where the identifiers are varchar but are for the most part filled with numbers.

That sounds more an example of weak dynamic typing, rather than strong dynamic typing, such as in Python or Ruby.

I think your whole argument could go the other way. That proponents of dynamic type checking probably having used anything else and just can't recognize the terribly costs that dynamic typing places on their system.

I'm a Java programmer professionally, so I use static typing all the time. However, I also doubt it's that beneficial. Static typing puts a limit on what you can do with a language. In an object orientated programming, it limits the OO model by having a solid distinction between classes and objects; classes are defined at compile time, objects at runtime. In a language such as Python or Ruby, classes are objects, so there is no such distinction. This in turn gives the programmer access to greater layers of abstraction, which can often be a very good thing.

java compared to scripting languages?

[walterbyrd]

I haven't done any real programming in a long time.

Is it sensible to compare java with purely scripting languages? I think python is a great language - as scripting languages go. But, I don't think I would try to write a substantial application in anything that doesn't enforce pre-declared variables.

Re:Application Programming

[bnenning]

Ruby? Man, it's an *interpreted* language!

The large majority of most code in a typical application is not CPU-bound. Deciding at the outset that you have to use C or a similar language for performance reasons is often a premature optimization.

Recently I've been learning my way around Mac OS X, with Objective-C and Cocoa. It's not perfect. But. . . For what it's designed for, for developing stand-alone GUI-based applications, I haven't seen anything dramatically better.

The Cocoa API is great, and ObjC is about as good as a language can be with the constraint of being compatible with C. But my next Cocoa app will use PyObjC. If performance becomes an issue I'll rewrite the critical portions in ObjC, but I don't expect to have to.

Re:Dynamic typing

[arevos]

Both languages can load classes dynamically - a good example would be Apache Derby which translates SQL queries into compiled java classes, which can then of course be jitted at some point.

Yeesss... It is possible to combine class loading and dynamic bytecode generation to achieve similar results. But this appears to me to be akin to using a sledgehammer to do a screwdriver's job.

Recently, I wanted to convert Pygame's event system into something more usable, by wrapping each event type in a python class. (Unfortunately, due to a lack of reflection in Pygame's C interface, I had to specify the methods in each class, myself).

def PygameEvent(name, methods):
    def __init__(self, event):
        for method in methods:
            setattr(self, method, getattr(event, method))
    return type(name, (), {'__init__' = __init__})

Given this four-line function, creating a new class is a one line job:

KeyDown = PygameEvent('KeyDown', ('unicode', 'mod', 'key'))

A ready-made wrapper for pygame.event.Event objects. I don't know of a fast way to do this in Java. Either I'd have to define a whole new class for each event type:

public class KeyDown extends Event
{
    private String unicode;
    private int mod;
    private char key;
 
    public KeyDown(pygame.Event event)
    {
        unicode = event.getParameter("unicode");
        mod = event.getParameter("mod");
        key = event.getParameter("key");
    }
 
    public String getUnicode()
    {
        return unicode;
    }
 
    public int getMod()
    {
        return mod;
    }
 
    public char getKey()
    {
        return key;
    }
}

Or I'd have to devise some more complicated JIT compiling alternative, which would take more time than going through the long process of creating all of the classes myself.

This, of course, is a trivial example. But there are other times when dynamic typing and class generation opens up avenues of design that aren't available otherwise.

Send it by E-Mail

[krischik]

How about sending "Hello World!" by E-Mail? In Java you just use the appropiate E-Mail class and the programm will only be about 3 lines larger. Those 3 lines will set FROM, TO and SUBJECT.

I am not a fan of Java - but I think comparting languages like this is plain stupid - because you are not comparing languages but the libraries.

printf is not C - it's a C library function.
OutputStreamWriter is not Java - is's a Java library class.

Shure the standart libraries. But they are library function which you can replace if you don't like them.

What you can't replace is:

unsigned int = -1;

or

char const y[] = "Hello World!";
char x[5];
for (int i = 0; y[i] != '\0'; i++)
    {
    x[i] = y[i];
    }

These are language features. Both show a common bug not detected by the compiler. A library can be replaced by a better one - a bug generating language feature will be with you all the time. No matter how much experience.

When I did C/C++ work I was hunting down bugs based in integer ranges, buffer overuns, dangeling or null pointers all the time.

Now I have an Ada assignment and those kind bugs are all gone. If it compiles it runs. I am a happier man now.

There is more to a programming language then the count of lines for "hello word".

Martin

PS: I did not use strcpy (which does the very same) because I want to show languages features.

PS2: Declaring a variable inside "for" has become valid for C99.

PS3: Hello World in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Basic

PS4: Integers in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Types /range

PS5: Arrays in Ada:
http://en.wikibooks.org/wiki/Ada_Programming/Types /array