Tag: Java

Java’s nickname, “The New COBOL”, as a badge of honour: “…considering COBOL’s standing in the industry: It’s not clear that being the ‘new COBOL’ is actually a bad thing. It may not be glamorous, because people see COBOL programmers as being outmoded and uninventive, but COBOL is far from dead.”

Seems Like Old Times

Back in December 2005, I wrote a blog article talking about the blog shooting war between Java and Ruby advocates that erupted over which approach was better: the one taken by Java with java.util.list or the one taken by Ruby with the Array class.

It’s interesting to see that nearly two years later, not much has changed — now we have a shooting war over Obie Fernandez’ blog entry, Top 10 Reasons Why Java Sucks Ass. I’ll write about this shooting war in a future article — in the meantime, for the sake of reference (and because the blog in which the article originally appeared in about to disappear), here’s my “Monkey Knife Fight” article from December 9, 2005.

The Original Article

Of late, I have been applying the term “Monkey Knife Fight” to language and architure wars among programmers. There’s something about them that reminds me of having two monkeys, each armed with a stilletto knife, squaring off while cheered on by a rabid crowd. I suppose that the major difference is that unlike monkey knife fights, you can glean some knowledge, understanding and even cooperation in the aftermath of a language war.

The particular monkey knife fight I am referring to starts in an entry on Martin Fowler’s bliki (bliki being a blog and a wiki), where he talks about two schools of thought about programming interface design:

• What he calls the minimalist approach: just provide the basic building blocks and leave it to the programmer to build what is needed. “Minimalists tend to focus on the minimal set of necessary methods to support these behaviors,” he says.
• What he calls the humane approach: design the interface so that the most common-case uses are easiest. He writes: “humane designers try to add methods that are needed. Often these extra methods are referred to as convenience methods, a term that minimalists do not consider to be a complement.”

He compares two similar structures: Java’s java.util.List with its 25 instance methods and Ruby’s Array, which has a hefty 78. He then shows us what it takes to fetch the last element of a Java List:

myList.get(myList.size - 1)

While in Ruby, getting the last element of a list is simpler:

myList.last

Elliotte Rusty Harold, author of a lot of books on Java and XML, disagrees with Fowler. He’s of the “less is more” school and wrote:

A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good.

…

Java’s List class does not lack any of the functionality in Ruby’s. Java just factors it out into a few more classes, especially the Collections class, and skips a couple of rarely used “convenience” methods. The result is a simpler, easier-to-understand, easier-to-use, more humane API.

And thus the monkey knife fight began, with a much excitement from the spectators:

• Martin Fowler’s original post
• Elliotte Harold’s response
• James Robertson, a Smalltalk guy, chimes in: “We are far more interested in solving application problems than we are in the production of extra code to support sparseness.”
• Cees deGroot: “My favorite analogy here: the difference between a human and a donkey is maybe 5% in genes. I like to think that a good object system works the same – the difference in behaviour between my classes, if you count everything they inherit, is typically 1-5%. Just a handful of methods, with usually a couple of lines of code because the base classes are so rich. Now, that is where simplicity rules.”
• Antonio Vieiro: “Each programming language has its idioms, and an API that follows those idioms is a simple API. An API that tends to be ‘simpler’ and make things against the idioms is an API that makes things more difficult. As Elliotte says the more the buttons the bigger the difficulty. So that’s just my opinion: I like simple things, but not ‘simpler’ things (because those are more complex to maintain).”
• James Higgs: “All of this makes it more frustrating that System.String does not have convenience methods like .Right(int length) or .Left(int length). It’s easy enough to do using .Substring(int startIndex, int length) – it’s just that reading that code takes a little longer, as indeed does writing it. And, of course, string is sealed, so we can’t subclass it.”
• Peter Williams: “Each of those decisions [to keep an interface minimal and let developers write a little extra code] are reasonable in isolation but put together pretty soon you and your community are stuck with a lot more code to maintain than if that behavior had been included in the core library to start with.”
• Cedric Beust: “Humane Interfaces clearly violate both YAGNI and the “do the simplest thing that could possibly work” principle, so I’m quite happy to see them gaining traction. For these same reasons, you can expect XP advocates to come out strongly against the idea of Humane Interfaces (and Elliote is leading the charge), which probably guarantees that they will become mainstream in no time :-)”

  [I rather like the graphic he included, shown below.]

  

• John D. Mitchell: “Alas, arguing back and forth over those sorts of details makes it easy to miss a fundamental, crucial point: no software (library, application, language, operating system, or whatever) can be all things to all people. Fighting that war is not only pointless but is one of my definitions of insanity. The point of a chunk of good software is to enable the effective and efficient creation of more good software and to help inhibit the creation of bad software.”
• Stuart Roebuck: “Finally, if I’m going to agree with Elliotte at all, I guess I should express doubt in the value of method aliases. One of the values of Java over C is that it provides fewer ways of expressing the same thing. I can’t see any great value in having two methods with different names that do exactly the same thing. In a collaborative project it would inevitably lead to situations where code confusing uses of both method names for no apparent reason. On the other hand, aliases in the method documentation would be good, e.g. you look for a method length() and it says ‘see method size()‘.”
• Elliotte Harold: Which remote would you rather use?

  

• John Tirsen: “If your requirements on that class library is to have a ‘humane interface’ then that is what should control how you implement that class library. So you implement each feature of the ‘humane interface’ in a YAGNI style. YAGNI doesn’t dictate what features you implement rather it dictates how you implement these features. The principle of ‘humane interfaces’ is what dictates what to implement.”
• Hitesh Jasani: “Perhaps the notion is that Java’s interface looks simple if all you do is look at Javadocs, but it is not simple if you actually try to use it. Ruby’s interface looks more difficult looking at the documentation, but turns out to be much easier when in use.”
• Blaine Buxton: “I like having a minimal set of methods to implement because I make sure duplication and cognitive friction is reduced. But, the users of the class wind up with terse code that’s harder to read than with a richer interface. It seems both sides of the argument will always be at odds. This is where I think concepts of object composition from prototype languages can help. Organizing Programs Without Classes is worth a study for it shows the way that we can have our cake and eat it too.”
• James Robertson: “Smalltalkers – and I think Rubyists – look at this problem very differently from Java folks. The Java people seem to like sparse classes, but they don’t seem to realize that sparse classes combined with an inability to extend leads to everyone creating their own set of utility classes. In Smalltalk, the useful protocol that people add tends to migrate up to the vendor over time…What we seem to have a two very different approaches to the class design problem. I think the Smalltalk/Ruby one is better, because it favors putting code where it belongs. The Java approach implicitly favors lots of utility classes.”
• James Robertson, again: “I like the way [Elliotte] baldly asserts that 78 methods [in Ruby’s Array class] is “an atrocity”. So what’s the magic number? Is 22 methods ok, but 23 – heck no, that gets into atrocity range? There’s absolutely no way to look at the raw number of methods and make that statement. He’s assuming that there must be fluff in there – but that’s an assumption, not evidence.”
• Elliotte Harold: “I suspect there’s more middle ground between Fowler and me than perhaps some people realize. His essential point is “The essence of the humane interface is to find out what people want to do and design the interface so that it’s really easy to do the common case.” I don’t disagree with the principle. However we part ways on the practical application of that theory to class design.”

  [Be sure to read his examinations of what he considers to be extraneous methods for the Array class.]

• Charles Miller: “In Java, List is an Interface. In Ruby, Array is a class. The distinction may seem to be hair-splitting, but it’s important…java.util.List isn’t really a shining example of good interface design either.”
• Rob Lally: “Harold is wrong. Plain and simple. And I can prove it. The Ruby Array class is probably the most useful class I’ve ever had the pleasure of using. If it offends his aesthetic senses, then his senses are mis-attuned…He talks about the 80/20 rule in his posting. For me the 80/20 rule is about minimising the amount of work done. Minimal interfaces are great on objects that are only going to be used a few times. If a class is going to be used (in the case of lists/arrays ) 10s or 100s of millions of times then giving it a broader interface is by far the best choice.”
• Bernard Notarianni: “I think that Object Oriented programmers may look at the situation a little bit differently. 78 public methods are 78 different way to talk to an object. Actually, we don’t care what is behind the object, but a large set of methods is an opportunity to find the best one for the programmer purpose.”
• David Crow: He points to John Maeda’s “Rules of Simplicity”, a set of good ideas that programmers should take to heart.
• Ian Bicking: “But I think the Java guy has a point: 78 methods on your list objects isn’t good. Less methods is good. Unless the result is stupid. Now, let’s be honest here, Java is stupid. Dumb, idiotic, maybe written by people who aren’t programmers; I just don’t know how else to make sense of it. list.get(list.size() - 1) should be embarrassing. list.last or list[-1]? I think [-1] reads well enough, and fits into a very elegant set of functionality involving slices and whatnot. But I also think list.last is entirely justifiable. OTOH, list.get(0) isn’t embarrassing, so list.first isn’t as compelling. And the nitems method he points to really seems overboard.”

As for me, I fall closer to the Martin Fowler camp rather than the Elliotte Harold camp, largely based on gut instinct. All the setup you have to do to get Java to do anything of consequence drives me bonkers. Classes with a pared-down interface may be simpler, but not when I have to start linking them to all manner of utility classes to get them to do what I want. It’s not so much simplicity as it is sweeping complexity under the rug, where you’ll have to eventually deal with it. Working with Java, I feel that I’m always thinking “How do I get Java to perform task X?”, while with Ruby, it feels more like “How do I get this result?” With Ruby, I feel that I’m wrestling only with the problem, not the language.

I do have one complaint about the Ruby approach — method aliases. While it’s convenient for luring in programmers from other languages, I think it actually detracts from code readability to have two method names mean the same thing.

It hasn’t even been a year since Sun hired JRuby contributors Charles Nutter and Thomas Enebo to work on it full-time. It’s been an even shorter period since Ola Bini (whom I had the pleasure of meeting at RailsConf 2007) got hired to do the same by Thoughtworks.

In that short span of time, they’ve done something impressive: they (and all the other contributors involved) have brought JRuby to version 1.0.

According to InfoQ:

The release is being termed as “Ruby compatible” with all known JRuby bugs causing incompatibilities with Matz’s Ruby (MRI) resolved. Applications should “just work” out of the box.

Here’s InfoQ’s summary of Charles Nutter’s roadmap for JRuby post version 1.0:

• Performance:
  In the last year speed has been increased by an order of magnitude and a JIT compiler has been enabled. The team will continue to work on improving the JRuby speed and performance.
• Java Integration: Today libraries can be called, interfaces implemented, and classes extended. Edge cases exist however. A redesigned integration API is targeted for 1.1.
• Ruby 2.0 and Rubinius: The goal is to support Ruby 2.0 and Rubinius byte code execution soon.

We at Global Nerdy would like to congratulate the JRuby (and NetBeans) teams on a job well done. We salute you with a filet mignon on a flaming sword!