10 Responses to Is there any more room at the Java wake? »»

Comments

1. Os
   Comment by Os | 2005/11/23 at 19:55:22

   Actually, if in the real world your team is composed of average programmers, wouldn’t you want to use a tool that would amplify their talents to the greatest possible degree thus increasing the productivity of the team?

   You don’t have to be a Bruce Tate or James Duncan Davidson to program with Ruby or to use Rails- mere mortals can do it and to it well (and get the work done a lot quicker than they would have otherwise). And who says you can’t add abstraction layers with Rails? There’s nothing stopping you from ‘doing a lot of work’ on the data coming out of the database prior to applying metaprogramming if you need to.

   To be honest, a lot of your objections sound like the objections that C++ programmers had against Java when it first appeared. You recall the “Memory management shouldn’t be left to a garbage collector, it has to be hand crafted” arguments? Basically it was the C++ programmers lamenting how Java was going to make programmers lazy. Sound familiar?

2. Nik
   Comment by Nik | 2005/11/24 at 11:59:51

   Os, you make several points here. (1) That average programmers (perhaps more than anyone) need tools to amplify their talents; (2) That Ruby or Rails is usable by anyone; (3) That you can add abstration layers to Ruby, too; (4) That I’m echoing the C++ luddites who lament programmers becoming lazy.

   But before I tackle those issues, I need to clarify my stance. You mention my “objections”, as if I’m objecting to Ruby or Rails like some C++ people objected to Java. That’s not my stance. I don’t object to Ruby. What I object to is people heaping criticism onto Java for the wrong reasons, and in particular the failure to acknowledge that many of Java’s features which lead to those drawbacks are, in other circumstances, actually strengths. I also think that those “other circumstances” are really the majority of cases, not the minority of cases. I also fully acknowledge Ruby’s and Rails’ strengths, particularly in the area of knocking up a quick database-driven website. But I’d say those strengths have been overstated, and particularly as creating a small database-driven website is not what real-world developers spend most of their time doing. In summary: I’m not knocking Ruby, I just think the case for it and against Java has been heavily overstated.

   So, onto your points…

   (1) Average programmers (perhaps more than anyone) need tools to amplify their talents.

   I fully agree with this, and would say that tools to amplify developers’ talents are valuable for all developers. But that’s not the whole story — for two reasons.

   First, the case for RoR has been focused around productivity, and more specifically about producing a new application in less time. That’s an excellent thing, no question about it. But there’s much more to development than producing new applications. A very significant part of it is about revisiting old code, fixing bugs, refactoring it, and extending the code’s features. In other words development isn’t just about producing new software, it’s significantly about managing existing software. The case for Ruby hasn’t been made in this area. I look forward to case being made for Ruby’s long term manageability. And when it is made we will have to consider the fact that by making things very explicit, by spelling things out in more detail, by allowing fewer shortcuts, as it is done with Java, it is easier to track down bugs, to understand what your co-workers did, and generally understand how your old code works. Things happening automagically makes these kind of things harder. Until the case is made in the area of code manageability I’d say Java is the stronger candidate.

   Second, amplifying talents and increasing productivity is not just what average developers need. (In fact, let’s stop calling them average developers; I mean typical developers, those who aren’t in the top 10%, the vast majority of us.) Most significantly typical developers need tools which cover for their human fallibility. So automatic garbage collection (related to your point (4)) is terrific because that’s one less area in which to make mistakes. Similarly static typing is good because it means mistakes won’t even get past the compiler. I read somewhere (but sadly cannot find the reference) that the dynamic typing of Ruby is okay in practice because your unit tests tend to pick up those problems that static typing would otherwise catch. Unfortunately another human failing is that we don’t always write enough tests. The more something relies on self-discipline to be effective the less likely it is to work. Something which amplifies talents is great, but if it also relies on less human fallibility that’s bad.

   (2) Ruby or Rails is usable by anyone.

   I’m sure that’s true. My point wasn’t that you have to be a top-10% developer to use Ruby. It was that you need much more support from your tools if you’re in the bottom 90%. Since us mere mortals are more fallible than the Bruce Tates and the James Duncan Davidsons then being forced to make things more explicit (and having our tools signal our failure earlier) is much more important to us.

   This is the “fallibility” point from above. Ruby on Rails is usable by anyone. But it seems to me that it requires a higher standard of developer if the resulting code is to be maintainable long term. Again, the case here hasn’t been made yet and in truth only time will tell. But from what I can tell so far Java is the stronger candidate, as I said above.

   (3) You can add abstration layers to Ruby, too.

   Again, I totally agree. Of course you can add abstraction layers. But that wasn’t what I was saying.

   I was saying that the many standardised abstraction layers in Java was born of a need to work with all kinds of odd (ie real world) systems. These abstraction layers have a specific purpose.

   If you’re trying to throw up a simple database-driven website then Java’s abstraction layers are a big overhead and RoR is going to be a good option for you.

   It’s a case of the right tools for the right job. RoR is the right tool for a particular job. But it would be wrong to say that therefore Java is the wrong tool for any job.

   (4) I’m echoing the C++ luddites who lament programmers becoming lazy.

   Goodness, I hope I’m not. I think laziness is a very good thing in programming. If the system can tell me I’m making a mistake — and prevent me from progressing if I have — that’s a great thing. Static typing in Java, for instance. If the system can take care of things I shouldn’t worry about that’s excellent. RoR will do that for me if I never need to worry about the database or its schema. Again, it has its place. But if the system allows me to take shortcuts which make my code harder to understand that’s bad. And if I’ve got so much freedom that I can make mistakes which the system won’t catch that’s also bad.

   If I came across as someone railing against Ruby (sorry) then I should have been clearer. I simply think there’s more heat over the so-called death of Java (and rise of Ruby) than is justified.

   At the end of the day Bruce says “Java’s not dead”, James says Ruby won’t be the next Java but that Java isn’t the only way, and Jack gives some solid management advice that was true 10 years ago and will be true 10 years from now. I couldn’t disagree with any of that. And in fact it’s all so obvious to me that I’m amazed this whole debate ever blew up in the first place.

   How did it blow up? As I said, I guess simply by a few very smart people getting excited by a new technology. There’s something there, but there’s much, much more hype than substance.

3. Robert “kebernet” Cooper
   Comment by Robert “kebernet” Cooper | 2005/11/24 at 20:53:14

   Some good stuff here. One thing I do want to note, however:L

   But before I tackle those issues, I need to clarify my stance. You mention my “objections�, as if I’m objecting to Ruby or Rails like some C++ people objected to Java. That’s not my stance. I don’t object to Ruby. What I object to is people heaping criticism onto Java for the wrong reasons, and in particular the failure to acknowledge that many of Java’s features which lead to those drawbacks are, in other circumstances, actually strengths.

   I think you are, however, looking at it like a C++ person coming to Java. In real terms we really all are. Even looking at Ruby or (insert Java framework product here), they all have the same problems in the real world: they are all about fresh starts. In the real world, you don’t get that many fresh starts. RPG is “dead”, and yet where I work (Cox) we still have an RPG group, Java has to call into the RPG which manages data across a dozen legacy systems. We have this horrible database that has 15 years of duct tape on it. As long as you have to deal with that stuff, it matters. The question is, will Java remain the preeminent language for new development — and in some peoples view, does that even matter. More on that second part in a bit.

   I also think the point about programmer skill is an important one. A lot of the people working with Ruby are coming from the Java world where, as you note, they have seen a dozen frameworks, know the gotchas on each of them and have taken a handful of language advantages Ruby has and made something that seems better in a certain context. There is nothing wrong with that. In fact, “starting over” at the language level isn’t even really a bad thing, since you get to eliminate common mistakes at a fundamental level. People who mastered the previous generation always have a problem with that. I could relate a story about some of the horrible code we have and the battle we had over our new internal practices doc I wrote, but that is a common theme.

   Thing about programmer skill and that first-choice language, though, is for all some programmers like to say “Best Language for the Job,” that is not really practical from a standpoint of Joe-Codemonkey. In general most programmers, especially at the in-house IT shop level, don’t even really have mastery of a single language. I would posit that it is nearly impossible for anyone to really have a mastery of more than 3, maybe four. By mastery I mean, keeping up with the advances, best practices and new methaphors. Some 10 years ago I was doing VB, VC++, etc. If you put me in front of ancient versions of Visual Studio, I wouldn’t even be able to write what I used to without booking it, and that certainly doesn’t mean I could come into the current .Net world without some serious ramp-up time.

   The point here, though, is that for “general purpose computing” there really do need to be some standards. “Superplatforms”, “Shops” and whatever are generally crap words that sales people use. However, sitting down in front of some code that some contractor wrote 2 years ago to make a change, it shouldn’t be alien, let alone in a mishmosh of languages that you maybe only know one of at more than a passing level. For this reason, Ruby has a long way to go. It has to seriously expand before it is really practical at that level. Of course, Java did too.

   I really think that the whole “Language” thing is overplayed though. Ruby, Python whatever don’t really have anything that JavaScript doesn’t. In a lot of ways, I see them as the 21st century version of LISP — lots of zealotry over not a lot. One hash-based language is generally the same as the next, IMHO. It’s all about the APIs and tools though. Rails made Ruby because it was that one killer API.

   Java needs some work. It needs some serious work in fundamental ways from Sun. The “Applet” concept needs to be completely reimagined. Core APIs need to include JAX-WS, JAX-B, Gecko and some kind of persistence framework — the irony that it is easier to talk to CORBA from a stock JRE than a SOAP server should be gnawing at someone at Sun. Some simple things, like letting Dynamic Proxies use an Object class as an interface declaration would go a long way to letting Java close the gap with Rails on development ease. A little bit of vision could not only keep these conversations from starting in the first place, it solidify Java’s dominance for the next 5 years.

4. Nik
   Comment by Nik | 2005/11/25 at 11:51:10

   Robert, you make a number of points here which I agree with.

   I’ll steer clear of the “superplatform” issue because, although I concur, it does get into the realms of futurology, which I’m never comfortable with. On a more prosaic level on that issue (”standards”) I’d say that common concepts and lessons are essential: patterns, test-driven development, and so on are real transferable skills that all developers should value.

   I’ll expand on two of your other points, though. First, on Ruby’s lack of tools. Ruby doesn’t have the many years (and people-years) of development effort behind it that Java has. It doesn’t have vast range of APIs, alternative product vendors and, crucially, IDEs that Java has. That’s just because it’s younger. It would be unfair of anyone to criticise Ruby because of this lack of software — it hasn’t had the chance yet. As you pointed out, Java was once at the same place, too. It will be really interesting to see how that progresses for Ruby. Java has gone one way over time. Perl, to take another example, has gone another way. How will Ruby’s library- and tool-base develop? It will be fascinating to see.

   Second, your point about “a fresh start”. I think that’s a big factor in the current noise around Ruby. Dave, who’s big the Perl world, has been bemoaning for some time about how Perl has a choice of tools which offer the same thing as Ruby on Rails. Why haven’t they had the same publicity as RoR? Dave thinks it’s because the Perl people aren’t as good at marketing as the Ruby people. I think it’s more about the fresh start that you talk about. RoR is new, it’s fresh, it’s shiny, and it doesn’t carry the baggage of Perl. No matter that Perl can do the same thing in the same way; Ruby is newer and therefore more exciting.

   On a neutral note, then, I think the way the Ruby world develops over the next few years is going be very interesting, and will tell us a lot about the culture of that community, just as the development of Perl and Java reflect the culture of their communities.

5. Robert “kebernet” Cooper
   Comment by Robert “kebernet” Cooper | 2005/11/29 at 21:38:17

   I’ll expand on two of your other points, though. First, on Ruby’s lack of tools. Ruby doesn’t have the many years (and people-years) of development effort behind it that Java has. It doesn’t have vast range of APIs, alternative product vendors and, crucially, IDEs that Java has. That’s just because it’s younger. It would be unfair of anyone to criticise Ruby because of this lack of software — it hasn’t had the chance yet. As you pointed out, Java was once at the same place, too. It will be really interesting to see how that progresses for Ruby. Java has gone one way over time. Perl, to take another example, has gone another way. How will Ruby’s library- and tool-base develop? It will be fascinating to see.

   Well, I think there are a couple of things there that are grinding issues for me with Java right now:

   1. Ruby’s IDE is primitive, but in real terms, you generally don’t NEED as much help from the IDE. I have had this back and forth with Josh at Sun about the future of SWING. Too many people in the Java world seem to think that there should be a “do everything” core and stuff should get pushed off to the “Tools” people to make it easy. That is how we got into our current mess with SWING and EJB and JSF has that smell about it. Java needs to get on board with the declarative markup UI quickly before Avalon and Flex drive it completely out of the space.

   2. We need a serious come-to-Jesus on the “convention over configuration” issue. This is attached to the “tools” part. I am, personally, a NetBeans user. One of the big selling points was the JAX-RPC support that would let you kind of write a basic JavaBean and it would autoedit all the supporting config you needed to deploy in the background. That of course begs the question, if you can determine that information from the Bean signature, why the hell do you need all that configuration in the first place. Similarly, with persistence and transactions and other things that RoR gives you implicitly, Java needs that kind of friendliness not in the tool, but in the runtime.

   Lastly, and as I noted in the comments I sent to Chris for the OJ article, the reason Java isn’t going anywhere for a while is precisely because of the API availability. While I curse IBM for the state of JT400/JTOpen, it is *available*. There is no chance you are going to see that in the Ruby world anytime soon. However, that goes back to the “we sound like the C++ guys” issue. :)

6. Robert
   Comment by Robert | 2005/11/29 at 21:40:56

   edit: One of the big selling points (of NB4.1)

7. Nik
   Comment by Nik | 2005/11/30 at 14:48:27

   Robert, it seems that your two points above are very much about size — initially about size of the language, but I think that also extends to size of the body of people who drive the language, size of the applications that are built with the language, and size of body of people who are responsible for those applications.

   For example, Swing, EJB and JSF are all sizable libraries because they are designed to suit a very large number of people running a very large number of applications: Oracle, IBM, BEA, etc all vote on the Java Community Process. They and their customers have complicated internal sales to make, and decisions (about core/non-core features for instance) have to take into account a wider number of issues than a small band of “enlightened dictators” might like. They and their customers have a large number of needs in their businesses, so they can’t take anything for granted — every decision has to made explicit because there will always be circumstances when the non-obvious decision needs to be made. They and their customers have large numbers of people supporting their applications, so much cannot be assumed by convention because that message won’t always get conveyed and carried out reliably.

   This is probably why, for example, Swing is part of the core language. If it wasn’t then Java would never have stood a chance in its bid to be a significant language of the desktop, which was a major corporate battle at the time. (Whether or how much it has been successful is another matter entirely.) Similarly this is why EJBs are so complicated — because they were designed for large applications managed by large numbers of people in large organisations.

   With regards convention over configuration I’d say (again) it works well with smaller bodies of people, and badly with larger bodies. There’ll be little argument getName() means get the name, but in many large applications managed by large numbers of people you’re going to get into trouble if you’re also implying it means there’s a database column called NAME, and that serializing it to XML creates an attribute called name. You’re going to find 10% of DBAs telling you that actually there isn’t a NAME field, but that it’s a composite of several sources. And you’ll get the architect in your partner company telling you that the XML name attribute really needs to be called id and it must be an element (except for one hour after midnight when the reconciliations occur, when it must be omitted entirely or you’ll get a connection reset).

   Convention over configuration also fails at a higher level in the corporate world. As soon as a major vendor breaks the convention the corporate marketplace (and the innocent corporate customers) are pitched into a very difficult battle. That’s just because that world is particularly aggressive. If the volunteer open source world finds someone breaking a convention then the problem is much less significant: there will be much less of a fuss (no PR departments involved) and it will be resolved by social democracy, which is far more mild than institutional capitalism.

   Java has been moving towards lighter frameworks for some time (eg Hibernate versus entity beans) while Ruby is a far lighter framework than Java could probably hope to be. Many of those who have sought lightness in Java have jumped on Ruby because it goes so much further than Java has done. But that’s not to say that Java would have gone that far if it had had the opportunity, nor that it would have been right to do so.

   Anyway, here’s what it comes down to… At a distance it looks as though this debate is saying that Java is dead and that Ruby is taking its crown. But when you get a bit closer all anyone is saying is that Ruby has got lots of features which they wish Java had, but Java isn’t going anywhere soon. I’d say that it would be wrong to expect Java to have those features as the problems it’s addressing are quite different (size/people). I doubt Ruby could compete successfully in the vast majority of places where Java is now, and I am more pessimistic about Ruby’s chances against Java than many Ruby-enthusiasts are. But I’m happy to agree that there are still plenty of situations where Ruby would have been a better choice than Java. It’s just I think there are less of them than some might like.

   (And completely off-topic, I do wonder what those nice Microsoft .NET people are making of all this hullaballoo…)

8. Robert
   Comment by Robert | 2005/11/30 at 15:38:14

   For example, Swing, EJB and JSF are all sizable libraries because they are designed to suit a very large number of people running a very large number of applications: Oracle, IBM, BEA, etc all vote on the Java Community Process. They and their customers have complicated internal sales to make, and decisions (about core/non-core features for instance) have to take into account a wider number of issues than a small band of “enlightened dictators� might like. They and their customers have a large number of needs in their businesses, so they can’t take anything for granted — every decision has to made explicit because there will always be circumstances when the non-obvious decision needs to be made. They and their customers have large numbers of people supporting their applications, so much cannot be assumed by convention because that message won’t always get conveyed and carried out reliably.

   I certainly understand the ideas behind the “heavy” frameworks. The problem comes in where the rubber meets the road. EJB is a prime example of an API that is simply poorly designed. EJB(1-2) and SWING both suffer from “flatness”. That is, the APIs aren’t tiered to the use cases people have for them. Everything is there in one big flat way, and people get overwhelmed trying to do something fundamentally simple. Yes, there is a need for all that functionality — somewhere. SWING was Java’s answer to MFC, and that is important to have. However, a very tiny percentage of desktop Wintel software is developed using MFC. The vast majority of it comes from the smart layers above it that come from VB5, Windows.forms etc. The lack of this easy to approach, most of the features there automatically kind of development is a big part of why Java never took off on the desktop.

   I know it sounds like I am asking for “lightweight”, and I’m not — though performance on smaller systems is somewhat of an issue. What I am saying is we need all of what we have, PLUS gradiated approachable development models that don’t require (flaky) automated tools to manage. Trust me, I am quite familiar with the sub-optimal world of trying to project legacy databases and object models into “conventions” of other systems. The point is, however, is you are starting with a clean sheet of paper, you should get a lot more power out of the box, then deal with your own “isms” as exceptions.

   Anyway, here’s what it comes down to… At a distance it looks as though this debate is saying that Java is dead and that Ruby is taking its crown. But when you get a bit closer all anyone is saying is that Ruby has got lots of features which they wish Java had, but Java isn’t going anywhere soon. I’d say that it would be wrong to expect Java to have those features as the problems it’s addressing are quite different (size/people).

   I think this is really the thrust here. However, I would say that Ruby does represent a medium-term threat to Java if it continues to rise. Lots of big players are already looking for something to replace Java because they feel that blank sheet to app, or at least blank sheet to prototype time with Java is much to difficult. IBM’s much publicized flirtation with PHP (until they actually tried to use it for something reasonably large, I would wager) is a prime example. Java’s API depth is an advantage, but a potentially transient one.

   I am not predicting the death of Java. In fact, I believe Java has the potential to see another decade of growth. I just think that in many areas, Java is languishing. Sun is simply not providing in respective areas what people already know they need. —

   Actually, this is funny. I was having a chat yesterday with a friend of mine about Apple and the rumors of a Mac Mini + DVR product at Expo in Jan. The funny thing about Apple for the last few years, is they have left “innovation” up to the customers. The look at what people are doing with their products (be it the Linux/iPod, Podcasting, Widget/Applet, Script automation, etc) and they simply try and make what people are already trying to do better. It sound obvious, but in the technology world, it really is a rarity.

   *That* is exactly the kind of model Sun needs to take with Java. When they see 20 different IOC frameworks, they should take than and BETTER them in to a standard. When there are 10 different XML UI markups, same. Gecko, same. It really wouldn’t bother me if the JRE got up to 100 megs, if it just had more of this stuff out of the box. The problem is, whether it is java.util.logging or JAX-RPC or JavaMail, Sun has made things worse, rather than better. JAX-WS and javax.persistence are finally a couple of steps in the right direction, but that idea needs to permeate the product line.

9. Nik
   Comment by Nik | 2005/11/30 at 16:35:25

   Yes, I think we’re probably converging on roughly the same place albeit from different directions. A layered library is an important distinction from a take-it-or-leave-it approach, and Sun would do well to emulate that. Ruby doesn’t have that yet, I think, but perhaps it’s only a matter of time.

   Of course, how Sun might build on the success of (say) 20 different IOC frameworks is an interesting problem. Do they attempt to brush them all aside with a better IOC mousetrap? Or do they build a covering layer which attempts to insulate the user from whichever actual implementation they’ve chosen? They’ve done the latter in the past, and in so doing they’ve kept happy those who implemented the details under the hood, but created a more complex world as a result. I think your point is that that’s what has lead to so much trouble now. Sweeping away the competing implementations might be better for the developers, but it would be troublesome for Sun.

   The difference between Sun here and Apple in your example is that Apple don’t have a pact with (say) other MP3 player manufacturers and won’t lose any sleep over upsetting them; by contrast Sun needs as many friends as it can get — the makers of those various frameworks are all strategic partners. It can’t afford to upset them.

10. Robert
    Comment by Robert | 2005/12/01 at 22:29:41

    Of course, how Sun might build on the success of (say) 20 different IOC frameworks is an interesting problem. Do they attempt to brush them all aside with a better IOC mousetrap? Or do they build a covering layer which attempts to insulate the user from whichever actual implementation they’ve chosen? They’ve done the latter in the past, and in so doing they’ve kept happy those who implemented the details under the hood, but created a more complex world as a result. I think your point is that that’s what has lead to so much trouble now. Sweeping away the competing implementations might be better for the developers, but it would be troublesome for Sun.

    I guess here is my thing:

    1. Pick the most common featureset and the one with the best API and clone it into a spec.
    2. Provide a default implementation in the JRE. (Don’t give me JAX-T in the JRE without an implementation so I still have to go get Xalan anyway).
    3. Make it pluggable so if I want those extras from a specific vendor, I can use the common API and reach into the specific when I need to. That way, if I move from “default” to “Spring” the code doesn’t look completely alien.

    This is kind of where they failed with something really simple: java.util.logging is HORRIBLE. If they had just taken log4j and put it in the JRE it would have been much better.

Leave a Reply »»