Beyond Java
I read Beyond Java yesterday. In it, Bruce Tate makes an excellent case that conditions are ripe for exploring alternatives in places that were once strongholds for Java. Bruce also tends to favor some of the same technologies that I do. In all, I would strongly recommend this book as it poses all the right questions.
Despite the fact that I happen to agree with the answers that this book puts forward, I feel that Bruce weakens his case by prematurely dismissing alternatives.
Alternatives
PHP is mentioned in passing a few times, and summarily dismissed. One of the biggest objections? Some function names have underscores between words, and others simply concatenate them. The truth is that this doesn’t matter. One niche that PHP has down cold is an ad-hoc collection of one page apps that baby-sit a relational database with a web based UI. My son’s school is a prime example. PHP also is a good match for places like Yahoo! who want to script together core logic that is written in C/C++. A better case would have been made if Bruce had focused on OO support in PHP (merely adequate), or on meta programming — something Bruce makes a strong case for — and is essentially absent in PHP.
Perl is dismissed as a write only language. No mention is made of Perl 6, which (if it ever ships ;-)) will have strong support for building domain specific languages — support that is far beyond what Ruby can offer today.
Python is mentioned in a nice way, and I do believe that the Bruce’s analysis is on target here: “The biggest hurdle for Python is its lack of compelling reasons to move away from Java. Python really needs a killer app.” Of course, this only applies if you are coming from Java.
Smalltalk is largely dismissed for the simple fact that it hasn’t taken the world by storm in 30 years, though nice things are said about seaside.
Ruby is positioned as the most likely candidate at this point in time in a race that is too early to call. Fair enough, though I think too much is made about the importance of a version that runs on the JVM. Frankly, I doubt Odeo cares. And if you have written a large web application in Java, you are likely using Spring, Hibernate, or (&deity; forbid) EJBs. If so, then I would think that the byte code you are using is the least of your problems. A much more pragmatic approach would be to integrate in a coarse grained manner through web services (note the use of lower-case), or in a fine grained matter through sharing a database. The biggest issue is likely to be the sharing of things like sessions.
Overall
Overall, I think this book poses the right questions, and I agree with the conclusions. In particular, I agree that in the next few years we are likely to see a shift from a small number of dominant languages/platforms to a plurality of solutions focusing on approachability, community, and metaprogramming.