Tim “Ongoing” Bray’s Take

Tim Bray posted a blog entry on what drives adoption of a language in which he included some tables such as the only below:

Procedural FORTRAN, COBOL, PL/1 C
Object-Oriented C++ Java
Higher-Level Perl, TCL Python, Ruby

This table of his should inspire a monkey knife fight on a number of blogs:

Web-Centric WebObjects, ColdFusion, ASP.Net, Struts, etc.,
etc., etc., PHP

Here’s an interesting one. What will JavaScript’s successor be? My guess for the short-term (by that, I mean “the next half-dozen or so years”) is “the next version of JavaScript”.

Mobile-Code JavaScript ?

The one about concurrent programming is a little more up in the air. Although there are other languages designed with concurrent programming in mind (either from the ground up or with concurrency retrofitted onto an existing language) and there have been for a while (I used Concurrent C in a course back at Crazy Go Nuts University in the early ’90s), Erlang is getting a lot of the attention these days since it has both a success story at Ericsson under its belt as well the clout of a Pragmatic Programmers book behind it. There is a feeling among some programmers (Bray included) that it isn’t going to be the language to turn concurrent programming from arcane art into mainstream practice:

Concurrent Erlang ?

Shelley “BurningBird” Powers’ Take

Shelley Powers disagreed with Tim’s assessments in her posts Flaws are in the Eye of the Beholder:

I find it fascinating when a person marks as ‘flawed’ the languages that have, literally, defined not only the web but application development of all forms. Perhaps the metric shouldn’t be on syntax, form, or function, but on usability.

Here’s her own table on languages:

'Perfect', but barely used 'Flawed', but simple, approachable, powerful, popular
Higher-Level *Ruby (every time I see 'Ruby' I mentally add, Mama's precious little…)

*I’m giving Python a slide because Python has fairly widespread use today.

Client side code (The to-be-created scripting language that will take a nice, clean, easy to use language and morph it until it satisfies the purists, while breaking faith with the millions of users just trying to do a job) JavaScript
Object Oriented Java (bloated beyond recognition with senseless additions and overly complex infrastructures) C++ (which can kick Java's ass performance and resource wise)
Web-Centric Rails (you know that thing they used for the one application?) Cold Fusion, ASP and ASP.NET, PHP

Those of you who recall Bjarne “C++” Stroustrup’s line “There are just two kinds of languages: the ones everybody complains about and the ones nobody uses” or the essay Worse is Better (or the essay that led to it or Jamie Zawinski’s commentary on it) should be feeling deja vu now.

As for Shelley’s table, I’d probably have put “PHP” where “Perl” is right now.

My Own Take

I think that right now, the “scripting languages” are stuck in something akin to “Three Stooges Syndrome”. That’s the disease where Mr. Burns from The Simpsons, being so old and frail, has so many diseases trying to get at him at the same time that they’re all “stuck in the door”. The doctors illustrated the syndrome with a model, shown below:

“Three stooges syndrome” from “The Simpsons”: All the germs and viruses are stuck in the door because they tried to get in all at once.

And since Tim and Shelley have their tables, I thought I’d make one too:

Scripting Stooge What’s Driving It
Perl Legacy: it was the original “duct tape of the internet”.
PHP Widespread adoption, drives a lot of apps, easy to program, easy to deploy.
Python Very readable, one of the 4 languages approved for use at Google (the others being C++, Java and JavaScript, according to Steve Yegge).
Ruby Ruby on Rails, which is a very nice framework from the web app developer’s point of view. That and maybe the fact that DHH is rather photogenic (although PHPer-turned-Pythoner Leah Culver could give him some competition).

Cross-posted to the Tucows Developer Blog.


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

by Joey deVilla on September 27, 2007

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.


23 Programming Languages Compared

by Joey deVilla on July 5, 2007

Possibly inspired by articles like Tim O’Reilly’s State of the Computer Book Market (here are parts one, two, three and four of the Q1 2007 edition of this series) posts on the O’Reilly Radar blog, Antonio Cangiano decided to do a little research of his own:

Technical books are a topic that interest me a lot. From book sale figures and trends we can attempt to better understand where developers are putting their money, not only their mouths. For this article I decided to perform a small experiment, by collecting some interesting data. I considered 23 fairly well known programming languages, and searched for the top selling book (according to Amazon) for each of them. The Amazon sales rank allows us to compare the success of books representative of each language, and indirectly compare the popularity of the languages themselves.

The Top Ranking Languages

According to Antonio’s research, here are the best-selling programming language books are for these languages, listed starting with the best seller:

Top 4 programming language books at Amazon: JavaScript, Java, Ruby and SQL

  1. JavaScript (JavaScript: The Definitive Guide, Amazon rank 1,227)
  2. Java (Head First Java, Amazon rank 1,799)
  3. Ruby (Programming Ruby: The Pragmatic Programmers’ Guide, Amazon rank 1,881)
  4. SQL (Sams Teach Yourself SQL in 10 Minutes, Amazon rank 1,929)

To see the top 23 programming languages based on Amazon ranking, go visit Antonio’s blog entry.

A commenter on the article wrote:

Actionscript would rank even higher than JavaScript, since the book Essential ActionScript 3.0 by Colin Moock currently is at sales rank #346.

Interesting Languages

There are some interesting languages on this list. Although they get mentioned on Reddit and a number of developer blogs, they’re not quite mainstream yet. In spite of that, they’ve placed quite well based on Amazon’s ranking system:

An interesting set of language books: Erlang, F#, Lua and Haskell

[Cross-posted to the Tucows Developer Blog]


The Lightswitch That Might Explain a Lot About Java

by Joey deVilla on June 28, 2007

John Maeda at The Laws of Simplicity has an interesting photo of a lightswitch at Sun Labs:

Lightswitch at Sun with a lot of confusing features and instructions.
Click the photo to see the original.

He writes:

I gave a talk at Sun Labs where I encountered a special light switch in one of their conference rooms. At first I thought it was some kind of silly “engineer” joke. But the light switch functions as stated for real. Does it win the award for the most confusing light switch? I bet there are other ones out there that are equally complex to use.

The lightswitch design philosophy at Sun is quite clearly reflected in Java.


JRuby 1.0 Released!

by Joey deVilla on June 9, 2007

JRuby logoIt 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!


“Hi, I’m Ruby on Rails…”

by Joey deVilla on May 15, 2007

Since there’s considerable overlap between the Cult of Mac and the Cult of Rails, it was inevitable some Rails enthusiasts would make Rails advocacy videos borrowing from the style of the popular “I’m a Mac / I’m a PC” ads.

Gregg Pollack and Jason Seifer of the blog Rails Envy are posting a series of Rails-themed “I’m a Mac”-style videos, one each day leading up to RailsConf, in order to get everyone fired up for the conference.

Here’s yesterday’s ad, in which Java plays the “PC” role:

Here’s today’s ad, in which PHP — who bears a strange resemblance to Java — is the PC: