Monkey Knife Fight! (or: Not Much Has Changed)

Woodcutting of two monkeys with knives fighting, captioned “You’ve got to love a language war!”

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

The foxes from why the lucky stiff’s “Why’s (Poignant) Guide to Ruby” yelling “Monkey Knife Fight!”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:


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

    “Humane Interface” logo

  • 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?

    Remote controls, including the very simple AppleTV remote.

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

Cross-posted to the Tucows Developer Blog.



“Bicycle accident” clay figurine.

Say hello — and probably goodbye — to my friend, Globe and Mail writer Jeff Gray, with whom I worked at the Queen’s Journal (a.k.a. “The Urinal”), the official student paper of Crazy Go Nuts University. He BikeBerries — that is, uses his BlackBerry while bicycling:

As a columnist who has suggested that cyclists should wear helmets, and shouldn’t use iPods in downtown traffic, I can’t very well come out in favour of using cellphones and BlackBerrys on the roads. Of course you shouldn’t. And it seems that sensible people have figured this out.

Still, gliding on your bike on a little side street, with no one coming, typing “ok” and pressing send? No harm done.

Dude, it’s even easier to pull over when you’re on a bike. Just do it, or else I’m posting those photos from the Journal staff party. You know, the “tongue” ones.


Steve Yegge’s Resume Tips (The Not-So-Long-Winded Version)

Wastebasket full of paperSteve Yegge, the programmer’s favorite cranky blogger from Google, has posted his Ten Tips for a (Slightly) Less Awful Resume.

Be advised that Steve does like to go on (and on). I personally don’t mind, but if you’re a little short on time, here are his 10 tips, each one reduced to the paragraph that captures its essence:

  1. Nobody cares about you. “Resume screening is just pattern matching. People are trying to figure out if you have the skills they’re looking for. If they could do this reliably without human intervention, so much the better. Screeners will like your resume best if it’s easy to scan visually, and stories about you and your fun-loving personality and fiercely loyal carnivorous parakeet and year-long hiking expedition in Tibet and blah Blah BLAH just don’t scan.”
  2. Use plain text. “Your resume is going to go through a bunch of automated transformation tools and will be mangled horribly along the way. Any non-ASCII character, such as those nonstandard Microsoft Word bullets, or any accented character, or (heaven help you) Unicode will be turned into our old favorite, the question-mark character (“?”).”
  3. Check, please! “Attend to your basic hygeine: spell-check, grammar-check, style-check.”
  4. Avoid weasel words. “Weasel Words are impressive-sounding verbs that make it sound like you did something useful, when in fact all you did was snork down chocolates from the big candy bowl in the conference room while other people did all the actual work.”
  5. Avoid wank words. “Wank Words are words that inflate your perceived importance (e.g. using “architected” rather than “designed”), or words that have simply become synonyms, such as “Rational UML Process”, for the so-called work done by people who sit on their asses and don’t know how to code anymore.”
  6. Don’t be a certified loser. “Don’t ever, ever use the word “certified” your resume. It’s far and away one of the most prominent red flags in resume screening, bordering on a dead-giveaway round-file 86-that-bad-boy no-review-required situation, if you know what I mean. (If you don’t know what I mean, well, you know the old saying about not knowing who the sucker is at the poker table.)”
  7. Don’t say “expert” unless you really mean it. “A friend of mine at Amazon once told me that he takes resumes that list “expertise” and he tells the candidate something along these lines: “Wow! You don’t often find true experts in fields like this. I feel like I’ve found a kindred spirit here. I don’t often do this, but I’m going to pick one of these technologies you’re an expert at, and we’re doing to do an incredibly deep technical dive on the subject. But before I start, is there anything you want to take off the resume?” He says it’s like truth serum.”
  8. Don’t tip your hand. “Resume writing is just like dating, or applying for a bank loan, in that nobody wants you if you’re desperate. And there are dozens of sure-fire little ways to let it slip out accidentally that you are, in fact, desperate, such as (just as one example) using the word “desperate” on the actual resume. Don’t do that.”
  9. Don’t bore us to death. “Seriously, take a close look at your resume and delete anything that seems obvious. If you worked at a company that everyone in the world has heard of, such as Microsoft or Amazon, then don’t spend time explaining to us what they do.”
  10. Don’t be a lying scumbag. “See, it’s like this: you’ll get caught. I’m still amazed at how many candidates think that the resume game is some variant of bingo, wherein all the words on your resume have optional invisible stars indicating whether you actually know something about that word, and you just cross your fingers hope the interviewer shouts out Bingo! after randomly selecting five starred words.”

Cross-posted to the Tucows Developer Blog.


Canada’s Copyright Czar Dismissed for Being a Little Too Cosy with Movie Industry Lobbyist

Dog and cat caught in embrace in a night-vision camera.

Canada Rocked by Copyright Scandal, reads the Inquirer headline. Speaking as a Canadian, I’m not rocked. Slightly tickled with schadenfreude perhaps, but not rocked.

Here’s the story: Patricia Neri, the Director General of Copyright Policy at Canadian Heritage has been removed from her position for a conflict of interest — inappropriate involvement with Doug Frith, President of the Canadian Motion Picture Distributors Association (and one of Canada’s biggest copyright lobbyists). We knew from Sam Bulte’s campaign disaster from the 2006 elections (where yours truly is proud to have played a part) that the government was in bed with big content, but we had no idea it was literally.

Canada’s number one good guy in the copyfight, Michael Geist, has this to say:

While Neri’s personal life is no one’s business but her own, this does raise troubling questions about the quick passage of Bill C-59, the anti-camcording legislation, since Neri appeared as a witness before a Senate hearing on [an unusually speedily-passed bill on camcording in theatres] with [Doug Frith] in the room. The Privy Council Office places particular responsibility on public servants that appear before a Parliamentary committee since they do so on behalf of the Minister.


Did a Blabby Google Employee Spill the Beans About the gPhone?

Old WWII poster “somebody blabbed” updated to include a gPhone.

Michael Bazely writes that a loose-lipped Google employee at the Apple Store in Emeryville confirmed the existence of the fabled gPhone:

So I’m standing in the Emeryville Apple store today trying to troubleshoot a problem with a sales rep when a young woman bolts up to us saying she wants an iPhone. Like, now. After some back-and-forthing about the particulars, she says she’s a Google employee and she was going to wait for a demo of the gPhone, but it turns out Google’s only letting 30 people test it internally and she’s not one of them. So she’s going with the iPhone instead.

At which point, the Apple rep and I exchange glances and he says “gPhone? So it’s real, huh?” And the Google gal realizes she’s probably said too much and changes the subject.

Take this with a grain of salt. Spreading gPhone rumours at the Apple Store sounds like something that an ambitious viral marketer might try or something I might do if I were much younger and really, really, really bored.


He’s in Biz Dev, That’s For Sure…

Here’s a photo found via Reddit. Take a close look:

A vice president of business development uses his mouse with his laptop — but it’s not plugged in.


Furries vs. Klingons: The Reese’s Peanut Butter Cup of Alternative Nerd Lifestyles

Don’t you hate discovering an interesting party just after you’ve confirmed your plans for the weekend?

“Furries vs. Klingons” promotional graphic
Click to see the image on its original page.

This Saturday, the MurrFurr Furries will take on the USS Republic Klingons in their second annual bowling competition at Midtown Bowl in Atlanta, Georgia. Attendees are encouraged to come in their suits, whether furry or Klingon.

If only this were available on pay-per-view…