Programming Languages (CS302 2006S)

Notes on Beyond Java

Comments on:

Tate, Bruce A. (2005). Beyond Java: A Glimpse Into the Future of Programming Languages. Sebastapol, CA: O'Reilly.

Comments from: Peter Brown, Michael Claveria, Davis Hart, Angeline Namai, Mark Nettling,

No Comments from: Alex Leach (x), Brad Miller (x), Dimitar Tasev (x), Dave Ventresca (x).

Overall, an existing or old language will not be the next Java-killer. Tate makes this argument in regards to Lisp, but it seems applicable to any older language. The problem that he outlines - that the current dominant language is becoming cumbersome and still retains many of his original weaknesses - cannot be fixed by extending or reinventing an existing language. Developers, and I imagine language developers as well, stick by their guns when it comes to design decisions. As a result, they will be unwilling to abandon language features which may be seen as weaknesses to prospective users. Even if they do give in, there is always the possibility that we will end up with features bolted on, like Perl's obnoxious OO interface. Furthermore, marketing an old language and attracting a user base might be similarly difficult.

I am still not sold on the benefits of being able to manipulate classes and methods at runtime. Doing so sounds very confusing in terms of maintenance.

Sometimes you need to be able to patch a running system. I'm not sure that it's as prevelant as Tate claims, but then I'm in academe not industry.

Based on the last paragraph on p. 91, Tate clearly has a preference for dynamic languages. However, I cannot quite determine what he finds appealing about dynamism. I am not even sure I understand the definition of a dynamic language, although I believe dynamic typing is involved in some way. Do you mind going over other key features, and possibly, advantages of dynamic languages?

We can certainly go over those issues. As best I can tell, Tate likes two things that we might put under the rubric of dynamic: He likes dynamic typing, in which the types of objects are determined at run time, rather than compile time. (More precisely, he likes systems that infer the types of objects automatically, rather than relying on the programmer to describe types.) He also appears to like interpreted languages.

I was glad to finally see some mention of LISP and some of the other, more traditional languages which I know something about. I do agree with the author, however, that the chances of PHP, smalltalk, LISP and Perl being the "next big thing" are slim to none. They've all been around for long enough, that there are not likely to be radical new uses for the languages which spread their adoption. Instead, and I think this especially applies to some of the earlier readings on LISP, the helpful and best features of these languages will continue to be incorporated into new languages and even Java, so that on one hand languages are moving towards the old languages, but only in the sense that they are moving towards them all, creating a mix of the best features.

I'm kind of tired so most of my comments are more or less notes from the reading.

Why is it that when continuations are used, the same machine must serve the user for every subsequent request? What is a distributed continuation cache?

Because the thing that is passed to and from the client is the id of the continuation and not the continuation itself. The continuation must be grabbed from the server's runtime environment. That said, there are certainly workarounds, but they are complicated.

Steve Yegge said that Python and Ruby are slow. Does he mean slow in run/compile time and relative to languages like Java?

Since Python and Ruby are generally used with interpreters, I'm pretty sure that he means at run time.

This chapter of Beyond Java was slightly disappointing. It is good to know that the new Object-Oriented languages are the main contenders to Java, but I would like to see each discussed in more detail (other than the ones the author discussed before). I suppose I would want to know more about why they were created and what critical improvements the Object-Oriented programming they hold that either Java does not have or the Java cannot have.

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Wed May 10 09:03:11 2006.
The source to the document was last modified on Fri Mar 17 08:39:32 2006.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Check with Bobby

Samuel A. Rebelsky,