Notes on Chapters 1-3 of 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, Alex Leach, Brad Miller, Angeline Namai, Mark Nettling (*).

No Comments from: Dimitar Tasev (x), Dave Ventresca (x).

I found the section in the first chapter about continuation servers to be interesting.I am glad that state saving for web application has found a simple solution, and it is upsetting (now that I understand continuations) that Java has not implemented continuations as part of the language. It seems like a natural solution to an otherwise tedious, complicated problem.

While I agree with the author on the negative aspects of C++, I think the author fails to point out that in application development not for the web, C++ is the standard language to use (I speak more specifically of computer gaming industry). There must be some reason that C/C++ are still the top languages used in the development of these applications. For this reason, I want to know what sets C++ above other object oriented languages for these projects, or if the industry is just not lagging behind technologically (and if so, for what reasons).

The author's reasoning is poor for why "Myth 1: Java's Leadership Is Unassailable" is a myth. He only proves that other good things have come to an end, and that Java has competitors. It seems a more appropriate proof would be to cite where Java fails as a language that could be remedied by a new programming language (for example, previous readings have suggested more of a merge between Lisp and Java to combine the benefits of both languages). Though, when the following myths are dispelled, that seems to provide a better reasoning, so I suppose it is more of a writing construction issue.

According to Tate, the key feature of Java is the virtual machine. He mentions that the JVM enables portability and automated garbage collection. However, can't we also obtain these benefits in languages that do not include virtual machines? I have a vague idea what a virtual machine is, i.e. some kind of software that creates an environment between the computer framework and the end user (Wikipedia), but I think I am having a hard time understanding the power of the JVM.

Portability is difficult without a VM. Garbage collection does not require a VM, but a garbage-collecting VM can make your life easier. The third key aspect of the Java VM is sandboxing. Sandboxing is very difficult without a VM or a well-designed OS.

Also, on page 48, Tate claims that "you can often express more with Java in fewer lines of code than you can in C++," and this strikes me as an echo of Graham's "I line of LISP = 20 lines of C" in The Revenge of the Nerds. I find it interesting that Tate, like Graham, emphasizes authoring time over execution time when deciding whether one language is better than another.

Except in a few applications, it's pretty clear that programmer time trumps running time, because few applications make full use of the processor (and faster processors are cheap). Most studies of programmer efficiency suggest that lines/day is remarkably consistent across languages. (That last commentw as anecdotal: I can't give you citations.)

I didn't understand why the author decided to mention DLL Hell in chapter 2. As far as I could tell, chapter 2 was talking about c++ and different aspects of it, but I was having trouble figuring out where DLL hell fit into that. Another general thing I noticed is that chapter 3 talked about how hip Java is, but the last paragraph notes that Java traded what was productive and hip for something that is tedious and slow. Why does the author seem to turn around completely?

I found it interesting how the author atributed the sucess of Java as much or more to its atracting the C++ comunity then anyting else. I was also intrigued by the number of times that he snuck in jabs about Java's static typeing. One other thing was how Java's evolution has led it to become more powerfull and massive, requireing a steeper learning curve, and makeing it harder to create small applications. Finally I was also interested in how the creation of the servlet kind of catupulted Java from successful language to supreme language.

Author gives almost no mention of LISP. Granted he's mosly just talked about Java at this point, but give our recent focus, this seems like a big hole.

You'll see some notes about LISP in the last chapter.

What are Hibernate and Spring?

Java toolkits.

The author seems to support writability first and foremost (dynamic typing, time saving efficiency re big concerns).

I agree that the learning curve of Java has become very steep, for even the most basic programs. Sure, it is a powerful language once you know it, but the learning process has become almost too much.

Believe it or not, but he'd claim that the amount of Java you learn at Grinnell has a shallow learning curve. The steepness is all the toolkits that lots of people use.

I was interested by the political side of the development of Java such as how Java will be limited because it is the major language and therefore has a much harder time implementing any radical changes.

It seems to me that the author has been dealing with Java as a multipuporse language, and while that is what many people use it for, it seems to be that Java is great of server side programs and other Internet-related apps, but after that, it's usefulness decreases.

If Ruby or Smalltalk can make programming much more easier and effective than Java in terms of metaprogramming, continuation servers, and API complexity and other features, then why don't we learn those languages in Grinnell?

Because there's only so much time in your career. Scheme also supports metaprogramming and continuation servers, but some folks (including Tate) don't really seem to grok functional programming. We are discussing whether or not to switch the object-oriented language for the program, and if you have input, that would be great.

A lot of the experts such as Davidson, O'Reilly (author), Hatcher all favor Ruby. Are there any negative aspects of Ruby because they all seem to make it out to be some kind of miracle language. Is the strong community of Java the only thing that's stopping the revolution of these other languages?

Intertia is a powerful thing. And, although I hate to say it, most programmers aren't all that smart. Learning a new language, particularly one with a weird syntax or model, can be hard. (I don't think Java would have succeeded without C++'s initial work in promoting object-oriented programming.)

Can you explain how the Common Gateway Interface (CGI) works in languages like Perl?

Sure.

The reading offered many suggestions for the successor to Java. First, Tate explained that it was Java's C++-like syntax that drew many developers away from C++. A new language should attempt to preserve a syntax similar to Java or C++, thereby lowering the syntactical learning curve. Tate's list of Java myths highlights the fact that the next big language need not attempt to be the best but be good and more importantly popular. Maintaining an easy learning curve and drawing open source programmers are two important recommendations which emerge from Tate's book. The latter of these presents a catch-22: to attract users to a language it must have a community but to build a community requires users. Perhaps this catch-22 is solved by improving the language to the extent that it draws in those who are looking for a "better" language and do not wish to stick with the status-quo.