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

[AKAImBatman]

Java, on the other hand, is much too bloated.

People keep repeating this, but it just isn't true. What Java has is an extensive set of libraries that provide all kinds of common functionality. If I were asked to trim it down, I'd have a hard time nixing anything that wouldn't get me in trouble with a LOT of people.

The main problem that Java still has is a large memory footprint. This is due to loading all those libraries into memory at startup. Why is this done? To reduce startup time. (i.e. It doesn't have to keep hitting the disk every time a new class is instantiated.) Thus Java appears "bloated". Yet if they remove the "bloat", people complain about the startup time. It's really difficult for Java to win this one.

The only real solution to this dichotomy is to make Java an operating system component. As a system-wide component, it could keep all the info in memory ONCE (including the pre-compiled versions of the classes) and make effective use of the system resources. This is very similar to what most OSes do with their libraries. Sun has taken steps toward this design with new code that preloads the classes into a shared memory area, but it's only partially complete. Given Microsoft's stance on Java, it's doubtful that they'll ever be able to completely solve the issue on Windows.

Thankfully, systems today have tons of memory and disk space. Since the unused classes will just be swapped out to disk anyway, there's no real concern. So quit whining, and enjoy what the Java platform has to offer. :-)

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

[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.

D programming

[AeiwiMaster]

I think digitalmars D is the next big language.

See it here http://www.digitalmars.com/d/

Re:D programming

[xiphoris]

Don't mod parent funny! D is a serious programming language with many benefits. It has been around a long time and it's a shame no one has picked it up yet.

News flash:

[grasshoppa]

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.

If you half ass your job in any professional field, you are in for a rude awakening. This is not news.

Ah. Dynamic typing. Again.

[jameson]

Well, if it's dynamic, it must be good, right?

    I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.

    Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").

    I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.

    Just my EUR 0.018.

-- Christoph

Re:Ah. Dynamic typing. Again.

[the eric conspiracy]

I agree with pretty much everything you say, especially with the frequent abuse of reflection. Runtime errors that occur in production at a client's site are a real heartache, and are often very expensive to debug and fix. Any language model that increases the likelihood of this is a bad design IMHO.

I've been using Python for prototypes, and have come to like the concise and clear nature of the syntax compared to Java and Perl. However I don't like the thread handling, the lack of quality compared to Java in the libraries, and the lack of some libraries that enterprise applications commonly use. Some performance measurements I've made also show Java is 4-10 times faster.

Re:Ah. Dynamic typing. Again.

[Ian Bicking]

I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.

The only time Python segfaults is when you have some really crazy code, or far far more commonly when you have C code in your system and that code is bad. Most dynamic languages also are not fully interpreted -- Python is not, and Ruby is interpreted, but won't raise syntax errors at runtime. The exception is if you are doing source code generation, which Rails does a fair amount of, but is not very common in Python code.

Now, the null pointer exceptions don't happen in these languages because there are no pointers, but similar things do happen. And they happen in Java too. Java not statically typed enough? Well, whatever, you get back to me when you have that awesome statically typed language with no slop that anyone actually does useful things with.

I don't think experience has shown us that statically typed languages are more reliable than dynamic. Programs that are developed with obsessive attention to detail, extensive review, and formalized practices and standards are reliable. None of those has anything to do with static typing; static typing is the absurd notion that the computer can be disciplined for you. If you look at something like programming by contract, it has nothing to do with static typing -- it's all about the programmers writing the system spending time indicating the exact needs and promises of the API, and language gives those programmers a structure in which to describe and automatically confirm those promises.

News flash!

[GileadGreene]

News flash! Not every tool is right for every job! In other news, newly released book discusses why afterburning turbofans make poor engines for commuter cars.

And no, the Batmobile doesn't count as a "commuter car".

Lisp

[fionbio]

I have been thinking that 'Lisp is not accessible' for years. I regret all these years beyond expression. Don't believe it. It's horrible lie. Here's the proof.

Re:Lisp

[Scarblac]

Hey, that's what I was going to post!

I used to work as a Java programmer, then on to Python and Perl. I've looked at RoR, and it's extremely impressive (basically, one guy defined web app best practices for the next decade, I think - not necessarily this particular implementation in Ruby, but the setup of the framework, emphasis on good defaults, sensible object model, well integrated testing, real easy use of Ajax, etc... very impressive)

But then I read Practical Common Lisp. And it rather opened my eyes. Turns out all these dynamic features of Python, Perl, Ruby etc are really just subsets of what's available in Lisp (like those Lisp people always insisted, but I never believed), and it's blazingly fast. It's compiled into machine code. I'm in love.

Right now, the useful Web libraries are just about there, but I don't think they are quite as featureful yet as what we're used to in the scripting languages. But I expect that to change dramatically in the coming year, as so many web programmers are checking out that book...

It's Too Much.

[Cranky Weasel]

On any large development project, by the time you've actually rolled into production, the toolset you selected is already out of date, and you have to start an "update the back end" project. And of course next is the project to unify your companies approach to delivering solutions, which means projects to bring the other projects in line. And when you're done that, it's time to revisit the back-end again.

I'm only 35 and I'm so tired of it. I don't want new languages. I just want to work with tools the team truly understands.

I have a life outside of work. The days of my wanting to read through stacks of documentation in the evenings to learn the latest new thing are gone.

So I'm being groomed for what I think is the natural progression for the tired but still knowledgeable developer... project management.

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

[Jerf]

I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.

Fact: Nothing is free.

Everyone will agree with that in principle, but few people have internalized it.

Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.

The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.

You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.

I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.

You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else.)

There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)

One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.

Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.

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

[sulam]

Rails (not Ruby) is faster than Java because it's a RAD framework. R = Rapid. If you used a Java RAD framework (there are a couple), it'd be just as fast. Ruby _can_ be faster (to develop) than Java due to things like collections semantics, but there's no guarantee it will be. As far as MVC separation goes, the two languages are functionally equivalent with the right framework. People conflate Rails with Ruby, but that's a mistake. Java was popular long before any great web frameworks existed for it, but now that they're there, people don't conflate WebWork (for instance) with Java. They do with Rails and Ruby because the two are getting popular together. With Rails, you have .rhtml files as your view, with scripting possibilities available there. You have your controller obviously, and your model bound to a db via ActiveRecord. This is no different from something like WebWork where you have a .jsp file as your view with JSTL scripting available within it, a controller class that provides objects to the view to manipulate, and model objects that use Hibernate to bind to a db. Ruby will get additional libraries and third party support over time. Heck, it may even get another web dev framework besides Rails (would be nice, people might quit conflating them). So I think over time Ruby will become a more compelling replacement for Java, and of course people who like to do original development for the sake of getting their name out there or just pride have a lot more to do in Ruby than they do in Java. That's true for books too, imagine trying to write a Java book today covering almost any topic, it's guaranteed to be a "me too" book. But with Ruby you can be the first guy to write the classic ActiveRecord book, or whatever it is you become an expert in. So yeah, it doesn't surprise me that people who create libraries or right books are excited about Ruby, there's more left to do. But that doesn't mean I'm gonna start using it in production code. :)

Not very insightful

[Ian Bicking]

I have read parts of this book, and still need to write a review of my own since I got a review copy, and that's supposed to be the deal. If you are going to write a book "Beyond Java" you probably should have ventured beyond java a little yourself. I don't think the author did in a signficant way. It includes contributions by other people, but most of those people are primarily Java developers who have history with other systems or are flirting with them currently. This isn't sufficient to give you a feel for the lay of the land. This isn't enough to write a book.

If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.

Application Programming

[Zobeid]

What ever happened to programming stand-alone application programs? For several years now I've seen almost nothing discussed on Slashdot other than web programming. It's all about scripting websites and accessing databases, etc. Is application programming no longer interesting, or profitable, or fashionable? Is it an activity now considered contemptible?

Looking at Java, the only thing I found interesting was the ability to write platform-independent applications. Even for that, Java appeared to have some significant shortcomings. I'm sure I'm not the only one who felt that way -- considering how few stand-alone Java apps I have installed on my computer now. Let me count. . .

Three. I have three Java apps. I have more apps built in REALbasic than in Java. So much for Java taking over the world, eh? And now people are buzzing about Ruby. Ruby? Man, it's an *interpreted* language! If I were coding a CMS, sure, I'd consider it. I may use it as a scripting language for my apps, it should be very spiffy for that. Will I code the apps themselves in Ruby? No!

Recently I've been learning my way around Mac OS X, with Objective-C and Cocoa. It's not perfect. But. . . For what it's designed for, for developing stand-alone GUI-based applications, I haven't seen anything dramatically better. And you know, I have doubts about whether I'm ever going to. Nobody is working on languages oriented toward application programming anymore. Some of the newer languages can do it, but they aren't focused on it. Apps and GUIs are a sideline, an afterthought.

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.

Heard it all before....

[kaffiene]

I've heard this crap before, and usually on slashdot where the editor's BIAS against Java is demonstrated ably by the utter crap anti Java FUD they promote to the main page.

Java is omnnipresent in the marketplace and contra the usual /. FUD, that is not because of "marketing" or "hype". You can't survive over a decade on hype - eventually you need to walk the walk, which Java has done and is still doing.

Java utterly dwarfs Ruby or Python in the workplace, and that's not because Ruby needs more time - Ruby has been around for ages already, it's just not what people want to use. The fact that Rails is a nice solution to ONE single problem domain doesn't make the Ruby language a success - in fact, a simple perusal of the numbers shows that Ruby doesn't even figure. Go read the book sales numbers for Ruby - all but nonexistant compared to Java.

Show me where the tool support for Ruby is. Show me Ruby for cellphones, show me Ruby on embedded devices. Show me enterprise level Ruby. Go look at eBay - running Java, go look at Google - running Java, go look at IBM and Apple - strong proponents of Java. Why? Not fucking hype, but because it does the fucking job well - DESPITE the bleating of whiney assed slashbot fan boys. Grow the fuck up, Java is successful because it is good at getting stuff done. End of story.

Sourceforge is now dominated by Java - more FOSS is coming out made in Java than C or C++. Compare the supposed "Java killers" like C#, Ruby - they don't even figure.

This whole "Java is dead" thing is utter crap and merely reflects the /. editors' own bias against the language.

Java will be superceded at some point, all languages fade from the number one spot at some point, but none of the current crop of tin pot alternatives being bandied around on /. will be the language to do it.

Re:Dynamic typing

[sproketboy]

Here in a nutshell is what's wrong with dynamic typing.

// Proto language dynamic typed
// This function trims a string from the 2nd param
FUNCTION trimString(a, b)
   IF typeOf a <> "String" OR TypeOf b <> "Number"
     // er, not sure what I should do here.
     // Maybe the caller passed the wrong params OR
     // maybe I was passed the wrong number of params OR
     // maybe I was passed NO params
     // I "guess" that maybe I cuold throw an error OR
     // maybe I should just pop up a message box OR
     // Is this a web application? If it is I really can pop a message box
     // I "guess" that really I should just throw an ugly runtime error
     // at the user even though this realy should be a "compile" time error.

     throw new WTFError()
   ENDIF
   // Code goes here....
RETURN

In other words. It's *impossible* to write any kind of generic code without having to deal with these kinds of runtime issues.  Much better code:

// Proto language static typed
// This function trims a string from the 2nd param
String FUNCTION trimString(String a, Number b)
  // code goes here....
RETURN