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

Comparison with perl??

[poeidon1]

Its probably nice to compare different programming languages but comparing java with something like perl is stupid. Perl is a scripting language to do things more neatly than C/C++, but its not a replacement for Java in any sense. Comparing with C# is much better and should be more detailed.

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.

Perl is not too loose and messy

[truckaxle]

"Perl's too loose and too messy" please provide some meat to that aspersion.

The typical response is to post some obsfustacted perl with a good reg exp thrown in for good measure and some cute comment about ascii explosions. These are red herrings. To these I say:

Any langauge can be obfusticated and C is perhaps the easiest to obfusticate.

Built in reg exp are extreme useful - learn to used them and do not fear them. Or good coding style requires you to document them. A single line reg exp can replace pages of code.

Re:Ruby's Quite Nice, Really

[PopCulture]

Where do you think Ruby will be in 10 years? My guess is either:

1) extinct, or,
2) '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. :-)

Rails

[jkauzlar]

Although I cringe at the name "Ruby on Rails," I'm assuming I'll get past that. I've been writing Java for years and, afraid of falling behind, I decided to try out rails to see if I really could, as the books all say, become more productive. I certainly think it's something to look into. The language's lack of type safety (or even 'my'!) sets off a continual internal alarm and nags at me to no end, but I find I can just set the vars to zero to get past that.

What I've found is that it really is much faster in initial development. Rails has an explicit separation of model, view and controller code, while in Java it tends to become convenient to mix all but the lower levels within .jsp pages. Another worry I have is the packaging system, which is harder to manage than Java's dom.company.package.subpackage structure. I could imagine that namespace conflicts would be inevitable in Ruby as with other 'scripting' (sorry to use that word) languages.

I haven't gotten much further than that.. Once I get to the point of having to maintain and expand on a larger codebase I'll no doubt have stronger opinions on its strengths and weaknesses, but for now, I'd say that most of what people are doing in Java can be done more simply and faster in Rails (or perhaps a Perl framework). I'd be concerned about its resilience and scalability on larger systems, as well as its industry or 3rd party support (Java's support, esp from Apache, is outstanding).

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. :)

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.

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: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:Dynamic typing

[Coryoth]

Whenever there is a debate about static and dynamic typing people always come out to fight with their blinkers on. They seem to be bound by the mindset of the sort of problems and projects they work on. In practice both have their uses and that's the real reason the debate. I use both, and the choice largely depends on what it is that I am coding. Analogies inevitably fail, but let's try one for this case:

If I'm building a treehouse for my kids* I'm probably not going to bother with the same sort of formal measurement that I would use to build a house for myself - line it up and cut it to fit will do most of the time. That flexibility is beneficial because I'm building around a tree, and being able reshape and redesign things easily makes a whole lot more sense in that environment (the other option being spending several weeks surveying the tree, and a lot of long tedious calculations to deal with its twisting organic structure).

If I'm building a house to live in I'm probably not going to just slap it together: I want to have some sort of design and measure everything against that as I go so I can be sure everything will fit together exactly as I want it to when I'm done. This more rigorous checking saves vast amounts of time over a flexible approach because I know that as long as all my measurements match up, the house will stay up - with a more dynamic approach I'll have to be testing everything every step of the way.

If I'm building a bridge or a bank vault I'm probably going to have another level again of formal requirements and calculations to ensure not just that things fit together, but that I can be certain that it will be safe in all weather conditions, or properly secure from potential thieves. Bothering to have detailed specifications from which extensive calculations and proofs of deep properties can be made is going to save me effort in the long run - it's just another level of formality again, above that used to design and build the house.

Now to my mind these three cases represent dynamic typing, static typing, and full formal specification (for those who think static typing in Haskell is as high as you can go, check out HasCASL). Each has their own place, and it's a matter of what it is that you're doing that determines which is the most suitable approach. If you mostly work on treehouses then someone telling you that you need to be properly measuring everything is going to seem like a pedant who just wants to annoy you and slow down your treehouse building. If you mostly build houses then someone telling you to hold up the 2x4 to where it needs to go and cut it to shape is going to seem reckless and foolhardy. As long as you're looking at everything only through the type of things you build the other point of view will always look silly.

Jedidiah
* (I am not trying to suggest that dynamic typing is for inconsequential or throwaway projects, I just wanted an example that is fairly dynamic and works best with an evolving approach)

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.

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.

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.

Re:Dynamic typing

[mad.frog]

static typing charges you through the nose for very, very dubious benefits

Well, as they say, "your mileage may vary".

From my development perspective, static typing isn't a cost, it's a dividend.

Code with explicit typing, to me, is MORE readable, more clear, and easier to deal with, because type expectations are spelled out explicitly; I *can't* avoid specifying them, because the language won't let me. Maybe you find it to be annoying, irrelevant dreck that drowns out the meat of the program, but for me, types are inextricably part of the meat -- removing them makes me wonder, "what are the expectations for this again? I hope someone commented it properly..." (And yes, I've done enough work in dynamic languages to have valid opinion of both sides.)

You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests

Yeah, yeah, yeah, I've heard this argument. I happen to agree that improved testing is a good thing, and that testing frameworks tend to be harder than necessary in most current static-typed languages. But IMHO this argument is rather like saying that seat belts are unnecessary if you have air bags (or vice versa); I'll take *both*, thanks.

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

Whoa, slow down, no one's saying that dynamic languages are impossible to write proper code in. My assertion is that static typing is a tool to help programmer's avoid dumb mistakes, and to make the meaning of the code more clear. Can I get by without this tool? Yeah. But I don't see a good reason to, in general.

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:java growing old....

[kaffiene]

You've never done anything in Java yet you know all about it? I present the typical Slashbot slackjaw.

"Java is an advertising name"????

FFS, this is typical anti Java FUD. You don't go from new to used by IBM, Apple, Google, eBay, most fortune 500 companies in the world by advertising. People like IBM and Google have actual engineers -you know, people with brains. The kind of people who probably even try technologies before presuming to pass judgement on them.

Moron.

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