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

Ruby's Quite Nice, Really

[Cruxus]

I can understand why he noted Ruby as a primary contender with Java. I've been learning it from an online primer, and it seems quite flexible and elegant. Java, on the other hand, is much too bloated.

Re:Ruby's Quite Nice, Really

[Anonymous Coward]

If you've worked with Java you'll realize everything is *not* in the language itself. The Java language is quite simple, a lot simpler than Ruby for example. Once you understand classes and interfaces you can understand any Java library. This is partly why there are such great development tools for Java - even your IDE can understand it well enough in real time to do something smart. There is a lot of stuff in Java's standard library, and there is a ton of third-party stuff that is commonly used, but that has nothing to do with the language. You can run Java on a cell phone with J2ME, and it's the same language with a different standard library.

Re:Ruby's Quite Nice, Really

[msuzio]

Ruby is great, but the standard libraries are under-documented and just don't measure up to the JDK (which, granted, is f'ing huge and includes so much stuff I have never in 10 years of programming Java had a need touse). It's also lacking some of the other support I take for granted with Java (for example, nice IDEs - they exist, but are still not as good as the average Java IDE in terms of boosting my productivity).

It looks like my next language of choice, however. I like the OO concepts, and although the block/yield methodology is a bit awkward (the packaging of blocks into Procs is the way the entire language should have gone, I 'got' that concept much easier), it's solid and on it's way to much wider use.

Re:Ruby's Quite Nice, Really

[bikerminstrel]

Ruby has things like modules, mixins, blocks, procs (closures), builtin syntax for maps and regular expressions, the ability to re-open classes and add or change them, metaobjects, singleton classes which allow an individual object to be extended as opposed to all instances of the class. So yes, I'd say the Ruby language itself is quite a bit more complicated than the Java language itself, though with Java 1.5 it's catching up in its own ways. Granted, you don't need to understand all of the above things to start using Ruby, but neither do you need to know all about Java to start using it. I think what's become bloated about Java is some of the APIs, like J2EE. It's definitely true at least for small apps that you'll write a lot less code to write a Ruby on Rails app than a J2EE app. Also, due to static typing and a less expressive language, Java source code size tends to be a lot larger than an equivalent Ruby program.

Python

[nuon3]

I'm always wondering why Python is left out from this kind of conversations.
Python is the best language I've ever worked with. It's very human friendly, no need to learn/read/write hieroglyphs, like in Ruby or Perl. Very compact, no need to write a pages of text to print Hello World, like in Java. It's very oo, supports multiple inheritance, what makes code reuse a reality. Has a wide range of modules, a wonderful application server, called Zope, a code generator, that eats UML and many many features, to make it an outstanding choice.

Re:Dynamic typing

[dmeranda]

If the topic of this book interests you, it is also quite worth reading some of Paul Graham's essays.

For the dynamic versus static typing debate, in particular read http://paulgraham.com/hundred.html

I've done both styles quite a lot, and I can say that static typing really is overrated. It sacrifices too much language power for what is really too little benifit (the benifit is often perceived to be much greater than emperical studies of real-world coding errors seem to confirm). The main problem that many static-typing fans seem to have is a lack of exposure to the other way of doing things--and enough experience to allow themselves the freedom to break old habits/patterns to actually see the power of dynamic typing.

Lisp not accessible?

[youknowmewell]

Lisp isn't accessible? Is that because of the parens or some other reason? If it's the parens, then obviously people are too superficial to look past the syntax (which is minimalistic to say the least). I've coded (and continue to code) in PHP, which has C-like syntax. When I first saw Lisp it was a bit different, but that's all it was: different. In fact, because there is so little syntax to worry about it makes the language even MORE accessible than C-like languages.

I've been reading Practical Common Lisp, and I have to say I love Lisp so far. I'm down to the practical examples and continue to enjoy the experience of reading, learning and coding lisp. It's certainly an excellent book and it shows, since it is a finalist in the Jolt awards.

Paul Graham is a big advocate of Lisp. He made big bucks selling is 3 year-old company to Yahoo, a company that was built off of software coded in Lisp.

Of course, one can't forgot the quote from Eric Raymond's 'How To Become A Hacker': LISP is worth learning for a different reason -- the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. I especially like these quotes from the blurbs section of the PCL website:

"This book shows the power of Lisp not only in the areas that it has traditionally been noted for--such as developing a complete unit test framework in only 26 lines of code--but also in new areas such as parsing binary MP3 files, building a web application for browsing a collection of songs, and streaming audio over the web. Many readers will be surprised that Lisp allows you to do all this with conciseness similar to scripting languages such as Python, efficiency similar to C++, and unparalleled flexibility in designing your own language extensions." --Peter Norvig, Director of Search Quality, Google Inc; author of Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp

"Please don't assume Common Lisp is only useful for Databases, Unit Test Frameworks, Spam Filters, ID3 Parsers, Web Programming, Shoutcast Servers, HTML Generation Interpreters, and HTML Generation Compilers just because these are the only things happened to be implemented in the book Practical Common Lisp.--Tobias C. Rittweiler, Lisp Programmer

Lisp was once in the same position C, C++ and now Java were/is in. It was one of those languages you had to know if you were going to get a job in programming. The only reason why it isn't still in that position is because it was ahead of its time. It was once thought to be slow, but Lisp compilers can compile to machine code and run as fast or even faster than C/C++. Lisp gives you the flexibility to code quickly to get features working and it also allows you to go back and optimize your code to perform at C levels.

So don't make the mistake of thinking Lisp is simply a worthless, academic language. Just check out Practical Common Lisp and see for yourself!

Don't confuse dynamic with weak typing

[dmeranda]

You, like many people, seem to be confusing two independent concepts: static v. dynamic, and strong v. weak typing. Read up here: http://en.wikipedia.org/wiki/Datatype

Dynamically typed language like Python or Ruby are also strongly typed. This means that the language absolutely *prevents* you from accessing an object incorrectly (breaking type safety).

C on the other hand is statically typed, but also weakly typed....the exact opposite!

C++ and Java are also in the same camp--static and weak; although both are much much closer to being strongly typed than C ever was. Although you can argue that Java is static/strong except for some low-level exceptions; or that C++ is partly dynamic (with template meta-programming)

Just for completeness, assembly is most always dynamically/weak; and Haskell is static/strong.

BTW it is the weakly-typed behavior of C (casts, void pointers, array bound checking, etc) that causes probably 95% of all type-error bugs. In fact this falacy that dynamically typed means the same as weakly typed is probably the primary reason that so many people seem opposed to dynamic typing. Dynamic != Weak.