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

[jcr]

I disagree. Not all languages succumb to the pressure to add "features" ad infinitum. Lisp, Smalltalk, and Obj-C are all still quite clean.

-jcr

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

[mclaincausey]

WTF? Look at the BNFs for each language: Java is NOT simpler than Ruby.

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.

Re:Ruby's Quite Nice, Really

[AKAImBatman]

It's not so much the release process, as the development process, which still requires the distinct build and compilation stages.

As I said, you can automate it with ANT or Maven. :-)

Or making changes to a bean and needing to restart java.

Don't use Tomcat. Seriously. Use Orion or something. With hotdeploy enabled, you can deploy an EAR file just by copying it to a directory. Everything will reload automatically. You said you use JRun? It has that feature as well.

And I can't (as far as I know) make a separate bean class (component) as a jsp file that can be treated as a bean by the rest of the system.

You can, and you can't. You can create a include JSP with an anonymous inner class, but it's really kind of dirty. You're much better off using an automated build and hotdeploy.

Rails and unit tests

[tcopeland]

One nice thing about Rails is that the unit tests are built in. Rather than having to go out and use JUnitWebTest or whatever, once you start writing Rails code the basic tests are generated for you and writing new tests involves fairly readable code, like this:

assert_redirected_to :action => "thanks_for_applying"
follow_redirect
assert_res ponse :success

It seems like the folks who are writing Rails are aware of the whole web development picture; not just getting a web app up but also making sure it's well tested. It's certainly making RubyForge much busier...

Oh, and, book plug!

(ot-ish) Perl is not too loose and messy

[tehshen]

Actually, I've been thinking about this for a while, and Perl seems "messy" to some because it has so much special syntax, that other languages just have as functions.

Example, if you had a list of files, and you wanted to print files from a list that exist (not contrived, I was doing this the other day) you would probably write something like:

foreach (file in files) {
    if (Exists(file)) {
        print file;
    }
}

A programmer who has never seen the language before could read through the code... "for each file... if it exists... print it". In Perl, I would do:

print grep { -e $_ } @files;

Although I would think "print all the @files that match the condition (they exist)", someone who has never seen Perl before would be like "whoa". Sure, it looks like nonsense, but that's only if you don't understand Perl. It's clear to me what it does, and I am no Perl-guru. People who think Perl is messy should take the time to learn it before slagging it off.

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:Python

[scottsk]

Not only that, but with Jython you get the killer embedded scripting language for zero effort other than adding a jar file - it allows you to drive all your object model's objects in a script. If you have a good MVC design in the first place, you can do amazing stuff to extend your application using Jython scripting. I wouldn't even design a Java program anymore without embedding Jython. (You can do this with JavaScript too, but the language isn't as powerful.)

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.

Re:Dynamic typing

[ratboy666]

What "dynamic typing" lets you do is forget about data types.

Then, code can be restructured to REDUCE the amount of code that is necessary. Sort of what the C++ template system is supposed to do.

Source code reduction is a very good thing.

With OOP programming, the idea is that an "object" encapsulates "dynamic type" -- not by type, but by interface. Generally, it is preferred to be able to inspect the possible behaviour at run-time (C++ RTTI).

This means that generic code can be written, that separates out the thing being done from a particular "type-based" implementation.

An example is in order: If I have a "type" that represents ordered values, it can have a "less than" and "equal to". Knowing ONLY that, I can derive "greater than" as "not (less than or equal to)".

I need no further information. Specifically, my "greater than" will now work on ANY ordered type: integer, large integer, float, date, string. And here it is, in psuedo-code (modified to look non-OOP):

greater_than(orderedX, orderedY)
return not(or(equal_to(orderedX, orderedY),
                            less_than(orderedX, orderedY)))

Now, it may be a NASTY job trying to execute this "efficiently" (or not, efficient language interpretation is not a specialization of mine). But the definition is correct. And can be reused easily (if the language is "correct" (by some definition) the reuse is automatic.

Languages that implement this are THE most productive: Smalltalk is the prime example. I still prefer LISP, but YMMV. This kind of thing should be easy, and automatic.

If a language is "OOP" there should be no way of peeking under the covers for an implementation. This is important because it allows the REPLACEMENT of an implementation; potentially at runtime. There is an entire class of bugs that are easily eliminated by this.

Contemplate the following definition of factorial (and it may be wrong, I am just typing this in):

unsigned int factorial(unsigned int n)
{
    if (n
Ratboy

Not written by a programmer

[SassyDave]

By the way, the author, Bruce Tate, is not a programmer. By his own admission, his qualifications are based on experience "reading code" and hiring developers. I listened to him speak at a conference, and I was underwhelmed with his presentation's technical content.

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!

Re:Lisp not accessible?

[be-fan]

I have to concur. After several years of programming C++, switching to Lisp was an awesome experience. It's a very productive language, has very fast compilers that can generate native code, and has some excellent development tools (Emacs + SLIME). For people who can get away with using it on a project (ie: you're not forced to make yourself easily replaceable by using a "commodity" language), I seriously recommend at least an enthusiastic attempt to learn it. "Enthusiastic" is the key word here. If you go in skeptical, you'll never get past the fact that its different from what you're used to. You'll get hung up on the parens, the naming conventions, etc. Common Lisp was designed to be a programmers language first and foremost. Thus, you really can't appreciate its power and flexibility until you write something substantial in it.

Re:Lisp not accessible?

[be-fan]

It's been done. It's called Dylan. It's got much of the power of Lisp, much of the speed of C++, and has a conventional syntax. Apple was pushing it for awhile in the early 1990s. Unfortunately, it never really caught on. The Lisp users didn't like the new syntax, and the project's distancing of itself from Lisp, while the mainstream didn't like it because it was created by a bunch of Lisp gurus. The Apple Dylan implementation suffered from being too memory hungry (like most OOP languages) to fit properly in a Newton, and lost out to a competing C implementation of Newton OS. Ultimately, the language was killed (within the company) when Apple closed its Cambridge Development Lab. Today, there are two existing Dylan implementations maintained by the Gwydion Project. The first, Gwydion Dylan, is derived from CMU's Dylan Compiler while the second, Open Dylan, is derived from Harlequin/Functional Objects's compiler.

Re:Lisp not accessible?

[youknowmewell]

Without the Lisp syntax, macros aren't even possible. Or at least the implementation of macros becomes exponentially harder. Macros are really one of the fundamental Lisp features that make it so powerful.

Another funny thing that most people don't realize (I know I didn't) is that Lisp is HIGHLY object oriented, more so than Java (not sure about Smalltalk/Ruby though). Lisp can be used in nearly the same way as other object oriented languages. It's just not a requirement.

What's funny is that at face value one gets the impression that Lisp is trying to be everything to everybody, but in fact Lisp isn't everything. It just gives programmers the ablility to make it everything :) "A programmable programming language" it is.

Boo Ruby + Java

[mythz]

You shouldn't need a dynamic scripting language to be productive. If you want something with the productivity and brevity of Ruby with performance >= Java, you should check out Boo (http://boo.codehaus.org/).

It can run on mono/.NET which gives you access to the .NET Framework, has Python inspired syntax (wiithout the annoying quirks), and advanced language features not even found in Java like: properties, events, closures, extensions, macros, partial classes, etc.

It can run in interactive mode (without needing a compile) or compiles down to CIL giving it the same performance as C#.

Re:D programming

[Per Wigren]

Yes, D is a wonderful language! The main thing it is missing for it to take off for real now is a stable GUI library. For me, cross platform is a must for me to even look at it. Cross platform is at leastMac OS X, X11 and Windows.

Currently the most promising project is WxD but it's still not ready for production use. I'd love to see bindings for Qt 4, because it feels much more "native" (user-wise, without #ifdef'ing code for each platform) than Wx currently does, especially on OS X. Also, I find Qt to be better designed.

Re:D programming

[Per Wigren]

One thing I forgot to mention in my last post, D is a system programming language. It aims to replace C++ first, Java/C# second. Its design is a lot cleaner than C++ (and even Java and C# in many places) and it's designed with compiler-writers in mind, which means that it is a lot more optimizable than C++. It also has support for inline assembler and things like that. You can write an OS kernel in pure D.

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.

Re:beyond?

[uptoeleven]

for small and even medium sized sites you're right, of course. Using WARs is an unnecessary pile of pants EXCEPT that it makes your site portable. If your server dies, you copy the war (a single file) somewhere else and your site's back.

When you start getting into bigger sites with clustering and multiple layers & tiers and whatnot WARs kind of bring sanity to the front-end. You create a WAR, you distribute it across the presentation-layer servers and you have a handy package with which to build a presentation server. If you have load balanced across 2 servers and you need it across 4 WARS are really handy for the distribution of that code.

They can be an almighty faff though.