Customer Reviews

Beyond Java

5 star:		(7)
4 star:		(13)
3 star:		(6)
2 star:		(3)
1 star:		(1)

 

 

There is a lot to like in this book, and a lot not to like. I'll talk about the negatives first and then discuss the positives.

The style of the book is extremely annoying. The author is a kayaker and a mountain biker, and he introduces each chapter with a kayaking/mountain biking story meant to serve as some kind of analogy to the programming topics he'll cover in the chapter. I found this unnecessary and distracting (I don't need sugar coating on my technical reading), and it felt like the real purpose of the stories was for the author to demonstrate how cool he is. In addition, the author uses the phrase "a perfect storm" over and over and over to describe the factors that led to Java's position of dominance in the programming world. I hated that expression even before I read the book; it has to be the most abused expression of the last few years.

Despite the fact that the book is ostensibly about programming languages, the author is by no means an expert on the subject. To his credit, he admits this freely, but he also makes numerous small and not-so-small mistakes when describing programming language features which may lead more knowledgeable readers to wonder if he's really qualified to write this book. For instance, in several places he describes the advantages of static typing as being mainly for early error detection, without also pointing out another big advantage of static typing: faster code (there are other advantages as well). In another place he makes the blatantly false statement that "Smalltalk is where all the continuation research is happening", ignoring the fact that Scheme (a Lisp dialect) has had continuations since 1986, and that there has been and continues to be active research on continuations in Scheme ever since. Then he says that "In Lisp, everything is a list." Wrong again. He also seems to assume that statically-typed programs will always be verbose, indicating that he is unfamiliar with statically-typed languages like Objective Caml which have type inference. The bottom line is that he often doesn't know what he's talking about when he compares the features of different programming languages.

The author's programming expertise appears to be primarily in the domain of small to medium-sized web applications. This is an important domain, but it's far from the only programming domain. So the book's subtitle "A Glimpse At the Future of Programming Languages" should really be "A Glimpse At the Future of Programming Languages for People Who Exclusively Write Small to Medium-Sized Web Applications and Nothing Else". If you want a broader picture, or are primarily interested in another domain, look elsewhere.

The author is clearly aiming the book at programmers who primarily program for money. Not that there's anything wrong with that, but given the author's expressed fondness for open source software (which I share) it might have been nice to acknowledge that some people also write programs for the joy of it in addition to (or in lieu of) the financial rewards.

Now that I've covered the bad, let's look at the good. The author seems to know his domain well, and he makes a good case that Java frameworks for writing web applications have gotten so baroque and tedious that they are simply miserable to use and lead to very slow development cycles. This might be just the fault of the frameworks and not the language, but the author makes a good case that specific language features (or the lack thereof) are what make Java so clumsy for writing web applications. He contrasts Java primarily with the Ruby language, and specifically with the Ruby on Rails web framework, and shows that several features of Ruby make for a much more productive programmer experience. For instance, Ruby's ability to express configuration information inside the language obviates the need for much of the XML that clutters up Java web applications. The author spends a lot of time discussing Ruby's metaprogramming capabilities and how they make it possible to write much more concise code with much less repetition. An example is a class which reads from a database and populates itself on-the-fly with methods to access specific database fields. (Small gripe: the term "metaprogramming" has a variety of semi-related meanings, all coming down to the notion of code being automatically generated instead of being written by hand, but the way that e.g. Lisp or Scheme macros or C++ templates represent metaprogramming is very different from Ruby's metaprogramming, and the author doesn't discuss that.)

The most interesting chapter by far is the chapter on continuation servers. The author gives a clear (though short) description of continuations, which is no mean feat given that they are one of the most difficult-to-explain concepts in the entire universe of programming languages. More importantly, he discusses how they turn out to be extremely useful in web servers, allowing web-based programs to be written in a much more natural and concise style than is possible without them. He uses the Smalltalk language as an example, because there is a continuation server written in Smalltalk. (Another gripe: while I'm happy to see him acknowledge that Smalltalk is a good language, I might have liked it better if he also mentioned that the Scheme dialect of Lisp also has continuations (as I mentioned above), and that there is also a web server in PLT Scheme that is also continuation-based).

The take-home message of the book is that writing small to medium-sized web apps in Java is rapidly becoming more trouble than it's worth, that more dynamic languages like Ruby have features that make it much easier, and that therefore there is a good chance that these languages will take over much of the programmer mindshare. I agree with all of these points, and think that today's Java web programmers are well advised to look at other programming languages. However, I also feel on general principles that all programmers would do well to learn another programming language every year or two, so for me this book just reinforces my pre-existing view.

On the other hand, the author mentions, but doesn't emphasize the fact that the JVM has many capabilities which far outstrip those available in Ruby or Python or indeed most other languages. He does point out that many advanced features of Java frameworks are only useful for very large scale web
applications (the domain that J2EE targets explicitly), and are unnecessary for the majority of (smaller scale) web applications. He leaves open the extremely important question of whether frameworks like Ruby on Rails will scale well to larger applications, or to smaller applications when they need to grow larger, though he seems to believe that they will (if not now, then later when the language and its implementation or implementations mature).

In summary, I think this book is a decent read with a lot of food for thought, if you can handle the irritating style, the mistakes and the omissions. This book is far from the last word on this subject (the reader should be aware that there are lots of interesting computer languages that are not even mentioned in this book, with Objective Caml and E being two obvious candidates), but it's interesting nonetheless.

While probably not the best analogy (on my part), the author's message seems to be similar to the book, The Innovator's Dilemma, that is on the required reading list for MBA students. The "Java Developer's" dilemma: How do you take time away from your comfort zone and what is paying the bills to focus on what isn't ready to pay the bills (the "disruptive" technology/language). I.e., there are more employers looking for Java experience than for, say, Ruby experience. So, when do you make that jump, what language should you jump to, or better yet, how do you prepare yourself to get ready to make that jump without getting left behind.

This last statement is what I took away from the first half of the book. The author gives his opinions and suggestions as to how to prepare yourself for that jump. For that, I think this book should probably be required reading for software developers in general, not just Java developers. I know a handful of ex-mainframe developers that wish they had taken time to learn something other than COBOL. :)

As noted in the other reviews, the book also discusses things such as Java's pros and cons, as well as what the characteristics of the "next big language" are likely to be. While interesting, this aspect of the book was ancillary to the underlying message I took away from the book. What I took away from the book was; when Java is replaced as the programming language of choice, are you going to be ready?

Overall a persuasive argument. If you believe Java is on the way out, this book contains your talking points. If you believe Java is king and your job is safe, this book contains the arguments you will most likely have to fend off.

Bruce Tate's Beyond Java is not up to O'Reilly standards. It's poorly organized, repetitive, and error-ridden. As of the present writing (Jan. 2, 2006), the online example code promised in the front of the book is not available on the O'Reilly web site. A long list of errata is available there, however, but it's incomplete.

Expect much frustration in trying to type in the main Ruby on Rails example and getting it to run successfully. And expect much hair-tearing at all the repetition and the author's attempt to be artsy by beginning each chapter by comparing white-water kayaking to the perils of picking a new programming language.

This would have made a good book or special journal issue at one-quarter it's present size, with better editing, and with better testing of the example code -- and deep-sixing the tedious kayak stories.

I was hoping that Bruce will have more insightful comparison of upcoming languages and will compare Java's shortcomings against them. Instead, he covered only major shortcomings of Java that most people already know such as not purely object oriented, edit-compile-test cycle or how massive it has become. Though, he talks about Python, Ruby, Smalltalk, Lisp, but it is very clear from beginning that the only language that he likes is Ruby and does not provide enough details on other languages. I myself have been learning Ruby over a year and have been trying Ruby on Rails lately and I like it a lot and I agree that productivity on Ruby is much higher than Java. It's just that I was hoping to learn a bit about other new languages and how they tackle different issues especially that make domain driven modeling a bit easier similar to "Naked objects" features. I for one doing Java programming since '96 and having gone through all Java->CORBA-Servlets->EJB-Spring cycle am looking for alternatives. Certainly, Ruby comes to mind and it is going to have support for VM and AOP support in 2.0, but I am still not convinced that it is the answer. Overall, I wished the author had researched a bit more about other interesting ways people are solving these problems.

This book was a quick and enjoyable read. I think the premise is right on: Java is too complex and has become a hindrance to productivity.

I liked the conversational style of the book. The author makes some good arguments against Java, and provides alternatives. He attempts to make a strong case for Ruby. After reading the book, I will definitely give Ruby a look.

I have several problems with the book:

#1 It is highly repetitive. This is more noticeable because the book and its chapters are very short, so it can be read in one sitting. It doesn't feel like any research went into the book (aside from personal interviews) so the scope is only what the author is most familiar with (ie. he mentions Hibernate/Spring/Tapestry over and over again. He brings up static typing impeding productivity many times over the course of the book...obviously a personal gripe of his.)

#2 It is not an objective analysis. After reading the book, I believe the author to be a Ruby evangelist. In particular, I didn't appreciate a section where the author shows an example of how Ruby outperforms Java. He clarifies by saying the evidence is unscientific (the Java implementation was not tuned for performance.) Well if that is the case, then it doesn't belong in a technical book (from O'Reilly no less.)

The author suggests the possibility of fixing Java, but it strikes me as an obligatory mention. Beyond Java is this author's (well informed) opinion, no more no less. It did not convince me to throw out the Java baby with the bathwater. Nonetheless, it provided some interesting food for thought.

The author has stretched his magazine article sized thoughts into a book. There is considerable redundancy and weakly supported opinions about the need to move beyond Java. I don't recommend this book to non-Java programmers or any managers. The author is unable to conclude with any actionable advice or timeframes. I do respect the author for posing some forward looking opinions.

I did find one bit of thought provoking advice. He has made me question my opinions about "continuation server" web apps. That section was well worth the read.

Bruce is a well known Java expert, most of his books are pretty good and very easy to follow.
He is always good at making difficult things easier - easier to understand and easier to implement.

In this book, he interviewed a bunch of 'language experts', most of them complained how difficult/cumbersome/awkward Java is. It's really worth reading.

I want to add more points to their opinions:
1. The current JAVA for web programming is too bad.
For say, in the popular Struts framework, you need a 'view' which is a JSP page, a 'form bean' java class just to hold all values that you need to show in the JSP page, an 'Action Form' which respond to the user actions on the page, and a 'model' class to hold the data. Finally don't forget at least 2 XML files to link them all together and specify the relation in Strut's xml config file.

To me, if we have to do web programming like this for another 10 years, that will really be a shame to all developers.

2. Don't get me wrong, Java is not a bad thing. Java is MUCH more stable and has MUCH more support than any languages.
You can almost easily find any solutions even with source code.
I wrote a lot JAVA, PERL, PHP programs. If the task is small (less than 3000 lines of scripts), scripts can do the job very easily.

The things I don't like for many script languagues are:

For PHP: no package, no scope, so you have no way to say sys.getOS(); and you can not force it to check variable declaration. Too bad if you made a typo or case mismatch.
All PHP extensions are static linked, and it has very poor support for mutithreads. We use to have 30 servers running Apache1.3+PHP4.3, each of them can not handle too many clients even the load is not high because each client will need one PHP process which is about 20M.

For Python: I really don't like __main__ __init__ stuff, they look like dirty hacks rather than well designed features.
The white space and non-C looking syntax make me really confused sometime.
Python was the slowest scripting language before.

For Ruby:
In Ruby, a + b and a +b have different meaning, I just can't get it. Ruby will give you a warning because it thinks a +b means a(+b), a is a function to call a positive numeric variable!

For Perl:
The OOP part is horrible. Actually I like Perl a lot. It's perfect for sys admins and DBAs but just so messy for developers
But PERL has something really neat:
a. PERL's getOpts and getOpts_long are the best. They are much better than Java's Jakarta Common CLI

b. PERL's SOAP::Lite is so powerful and so easy to use. 3 lines code to get you a functional SOAP server. I build a grid log searching tool using PERL CGI,SOAP::Lite and SUN Grid Engine just in one afternoon. It will take at least one week if I have to write JAVA and use AXIS.

c. PERL's 'tie' solution for Berkely-DB is the easiest on the earth. Please check the official 'SleepyCat Java Edition' then you know how difficult to write in JAVA. (I'm not saying it's poor, what I mean is that it's just way too much comlexity for day to day jobs)

Actually Groovy is a pretty good script language,
the only thing I don't like is its warnings. In PERL/PHP/PYTHON, all warnings are relevant and helpful but in Groovy, it sometimes just directly print Java complains to Groovy interpreter which has no meaning to the developer.

SUN is gonna to include Java-Script and Bean-Shell in next Java( version 6.0) and include Groovy in version 7.0.

I'd really like to see SUN's 'official' support for these languages.
There should be a Groovy framework soon and I think that might be more attractive to us.

In Bruce Tate's 'Beyond Java', the author writes a book that takes a look at where Java has been, gone, and why it may or may not be the "hot" programming language any more (I don't know if it has been for some time).

Focusing on Java's pitfalls and weaknesses, Tate provides a detailed analysis of what makes Java good, bad, and ugly. He relies on the opinions on many stalwarts in the field, and it's a nice look at what Java did right and what it has not.

My #1 issue with this book is that the subtitle says that it's a look at the future of programming languages, but it seems like so little time and words are accomplishing this goal. The entire book it's a discussion about Java and probably about 10-15% of it talks about Ruby and the pros of this new programming language. Ruby is discussed in some detail, but the general feeling is that this language is very specialized with a limited fan base. The book gives the impression that Ruby is very good and easy to use without having to write much code, and I can't complain there. When it comes to an analysis of other programming languages, there really isn't any. .NET with C# and VB are touched upon VERY briefly, as well as Python, Smalltalk, etc. but it's not the in-depth discussion that I would have expected.

For people that use Java a lot and want to learn more about the pros and cons of the language it's a nice read, albeit a quick one. For people that truly want to get a feel for the future of programming, this book doesn't deliver as marketed. Not only is it very short (180 pages of content), I don't care for the writing style. Nearly every chapter the author continually talks about his kayaking adventures. I realize this is a light intro for every chapter that is supposed to make the reader communicate with Mr. Tate on a personal level, but after a couple of chapters I got sick of it and wished more time had been spent on discussing other technologies instead.

For Java buffs it's a nice read, for everyone else I'm neutral on a recommendation.

***

First I have to laugh. Because this is one of those books where the author is either trying to get people mad, just to see their reactions, or they really know what's going on and are the first to say so, and therefore be burned at the stake. Or they are just don't have a clue. I think after a number of reviews have come in for this book, I think you will find all of them cover the above three.

First, this book makes me think and makes me want to look further into Ruby on Rails and continuation servers. They sound interesting. Second, some of the things Bruce says in this book seem to contradict themselves when it comes to him sounding off at Java's shortcomings.

First he says he doesn't like the "verbosity" of generics (Java 5.0), then he talks about having to use Iterators and the code you have to write to loop through Collections (Java 1.4). Meaning that for his argument, he'll use Java with version 1.4, and in another he'll use Java 5.0 But only to "prove" his argument. He jumps back and forth. I can do that in any language, use a fault in a much older version to use in an argument about the version today.

I think some of his "pluses" for using Ruby is because he hasn't used a dynamic typed language before, and not seeing the trade-offs and other maintenance problems that come with dynamic typing. We'll have to see.

I also respect Bruce, because I really enjoyed his Better Faster Lighter Java book.

Buy this book for the entertainment value from either side, the I want to beat him up, to I completely agree with him 100%. Either way you will have fun reading it.

This book is rather different from most O'Reilly books, since its purpose is not to teach a particular language or technology or even programming technique. It's essentially an extended position paper, and one might argue, an advocacy paper as well. This book is entirely the author's personal opinion, written at a particular moment in time in the evolution of web-based programming. O'Reilly has given him this platform because he is a noted Java expert with several other popular, high-powered Java books to his credit, and for that reason, it's worth reading what he has to say. But he admits that much of what he writes is merely speculation, as he looks ahead to the "next big thing" in programming. This is a VERY contemporary book -- in 2006, it is of great interest. In 2007, it will probably be almost completely irrelevant as we'll already have a pretty good idea of how close or how off-base the author is, and 2-3 years from now there will be no reason to read this book at all except perhaps out of historical interest.

So, what is the author's premise? Essentially, that Java is getting too old and crufty for the next generation of web development and that all the hip, cutting-edge developers and start-ups are looking elsewhere. That sounds like the sort of rant you could find posted on hundreds of blogs, and normally would be nothing more than flame-bait, but this book is not a rant. It's very carefully thought out, and the author presents some compelling arguments. And, considering that Tate is a "big name" in the Java community, and has recruited many other big names to provide their own input in this book, it can't be dismissed as merely the opinionated rantings of a disgruntled Java programmer.

Now, he isn't exactly predicting the death of Java. Indeed, Java will undoubtedly be around for many more years, no matter what cool new technologies arise. But he outlines all the reasons why (in his opinion) Java no longer suits the needs of most of its users, and then he talks about what he thinks does meet their needs.

Here's where the book becomes an advocacy paper. Although he tries to give some space to other "possible contenders" such as PHP and Python, and even gives a nod to Smalltalk and Lisp, and he also tries not to sound like he's just bashing on Java, it's very clear that the author has jumped on the Ruby on Rails bandwagon. Ruby on Rails is of course what all the cool kids are talking about nowadays, and it is certainly grabbing mindshare fast. He spends a chapter giving you an overview of the Ruby language, and then another chapter covering the Ruby on Rails framework in brief.

Are his arguments convincing? He writes from the point of view of a developer and start-up founder trying to decide whether he should stick with tried-and-true (and sure to be supported for many years to come) Java, or jump ship to a more agile, productive framework, and incur all the risks entailed in being an early adopter. If you own a web-based company, he probably won't convince you that you should ditch Java and start moving your entire enterprise to Ruby on Rails. Ruby seems poised to become the Next Big Thing, and it's quite possible that a few years from now, every online training site, trade school and community college will be teaching "Web Design with Ruby on Rails" the way they now teach Java. But it's still also possible that Ruby will just never quite hit that critical mass, and become an also-ran like Smalltalk. It's a little too early to tell. But if you are a developer, especially a Java developer, this book should definitely convince you to take a look at Ruby, maybe play around with some home projects using Ruby on Rails, just in case.

There is also a brief chapter about the Seaside continuation server written in Smalltalk, which in its own way looks as groundbreaking and cool as Ruby on Rails. The author admits, however, that Smalltalk's time seems to have passed, so it's unlikely that Seaside will be the "Java-killer," much as it may deserve to be.

If you read this review in 2006 and you are a Java programmer, you should definitely read this book. If you're reading this review in 2007 or later, then one way or the other, it's probably already too late.