Archive for January, 2008

TestNG and Scala

There’s been a lot of activity in the TestNG world lately… Here are some highlights.

TestNG in Scala

Josh Cough has been busy working with TestNG and Scala. As a credit to Scala’s great integration with the JVM, it looks like the task was rather easy and Josh is showing a few examples in this blog post.

I notice two interesting pieces. First, a Data Provider:

@DataProvider{val name="generators"}
def createGenerators = {
val gens = Array(off, on)
for( x <- gens; y <- gens ) yield Array(x,y)

Notice how the same array is used to generate the two dimensions of the boolean matrix... This data provider will simply return the four possible combinations of "on" and "off" pairs.

The test making use of that Data Provider is fairly straightforward:

@Test{ val dataProvider="generators" }
def testAndGateStates(genA: Generator, genB: Generator){
val and: AndGate = new AndGate(genA, genB);
val whatItShouldBe = genA.on && genB.on
assertThat( and.on, is(whatItShouldBe) );
println( and.on + "==" + genA.on + "&&" + genB.on )

Notice also the appearance of HamCrest (assertThat).


Bill Venners, from Artima, has also been busy cranking Scala code, and he came up with this nifty test framework called ScalaTest. His 0.9 release made the rounds and the discussion on Artima is now up to 58 replies(!).

Not surprisingly, Josh chimed in on the thread about the 0.9.1 release and TestNG support in ScalaTest was achieved in less time it took to write these words (I'm a slow typist). Talk about a match in heaven!


On a different front, the efforts to replace the default TestNG reports have not abated. First, there were Cosmin Marginean's XSL based reports, and now we have ReportNG, by Daniel Dyer, who uses Velocity to achieve grace and aesthetics in testing reports (who would have thought?).

Surefire 2.4 release

TestNG users who use Maven to build their code have been having a very hard time these past months. Because of various incompatibilities in the ways that TestNG and Surefire have evolved, TestNG users have been forced to use Surefire snapshots, which are notoriously unstable, and all kinds of mayhems and cryptic errors ensued.

These dark days are now over: Surefire 2.4 is out and it fully supports the latest TestNG releases.

Deleting SNAPSHOT files has never felt so good.

Book review

Finally, Masood Mortazavi likes our book so much that he decided to write a review. And we didn't even have to pay him!

And that's all for today...

The myth of the Killer App

An innocent blog post on Lambda the Ultimate has generated a storm of comments about the idea of a killer app for programming languages.

I’m sure you’ve heard this expression before, and the idea is very simple: it’s an application which, in and of itself, will promote its infrastructure (the operating system, or the programming language or the framework it’s built on) from obscurity to instant fame and de facto standard overnight.

For example, one might say that Microsoft Office was Windows’ killer app. Of course, this would be simplifying the equation somewhat since a lot of factors made Windows the success it is today, but you get the idea.

While reading through these comments, I started questioning the very existence of the killer app concept. Especially for programming languages.

Let’s start with Java. Does Java have a killer app? Did Java go through the transition “obscurity -> killer app -> fame”?

Back in the early Java days (circa 1996), there was one thing that made Java stand out from other languages. It doesn’t mean that Java was more popular than these languages, nor that it was gaining momentum: it’s just that it was attached to a particular concept that was unique to it and because of that, it received a lot of hype and was discussed heavily on Usenet and other forums.

Do you remember what that killer app was?


Thanks to applets, Java was going to take over the world and redefine the web as we know it.

We all know what happened.

Applets never went anywhere, but Java had enough interesting properties that a lot of programmers started working with it in many areas, most of them never envisioned by any pundit at the time. Who would have guessed back then that Java would become the de facto standard on the back-end, sharing an equal footing with .Net in delivering millions of transactions every day to users around the world?

Let’s take another example: PHP.

Does PHP have a killer app?

None that I can think of. Of course, a lot of very successful programs and web sites are written in PHP (forums, blogs, etc…), but none of these can be considered “clinchers”. Instead, PHP became successful quietly, discreetly, behind closed doors, while both programmers and the required infrastructures (massive support by Internet Service Providers) were being slowly achieved without anyone realizing it. To onlookers, it looked as if one day we woke up, and PHP was everywhere. But make no mistake: the process was continuous, slow and developed on a massive scale.

A similar argument can be made for Javascript.

The more I thought about it, the more I started wondering if the idea of a killer app isn’t a fallacy. Or worse: a kiss of death. As soon as a programming language or a framework finds itself in need of a killer app, it has already failed and its proponents are just reaching and trying to save a product that they know is already slowly falling back into obscurity, as the rest of the world inexorably percolates toward the next big thing, one that makes them truly more productive and that doesn’t need bigot advocates to sell.

Maybe what we are really looking for is not a killer app but killer apps. Not one defining product by which all the others are measured, but a multitude of tiny ones which, individually, don’t really deserve any particular mention, but when put together, create a comfortable ecosystem in which programmers thrive, are productive and enjoy working in.

Now, let’s see if we can find the Next Big Programming Language using this criterion…

Sun acquires MySQL AB…

Time for Sun to rename its ticker symbol to “SQL”?

I’m not tired of Java yet

Rick Hightower posted an interesting follow-up to Zed’s rant against Ruby on Rails. There are a lot of insightful comments in this discussion, and one in particular caught my attention:

People are tired of dealing with Java’s many idiosyncrasies

I’ve been reading this a lot these past years but I’ve yet to see any evidence of it.

Come to think of it, this statement is mostly coming from bloggers, but…

  • They don’t speak for all Java developers (actually, they represent a very tiny fraction of them).

  • They need to drive traffic to their blog, and nothing achieves this goal better than posts titled “Java is dying” or “Ruby has won”.

I’ve been programming in Java for more than ten years. I have studied a lot of languages, and I keep learning new ones just out of curiosity. I even use some of these exotic languages here and there as the need warrants. Yes, some of these feel really good to program in (Ruby and Groovy for example), but at the end of the day, I still like Java. A lot.

Sure, there are things in the language that bother me, but it’s true for any language, and as a whole, I always enjoy going back to my favorite Java IDE and leverage its superb features to write code that I find is elegant and that achieves a goal.

Whenever I use a non-Java language, I always have this nagging feeling in the back of my head that something is going to hold this piece of code from ever becoming mainstream or used by a lot of people. It can be because the language is slow, or that it needs an interpreter. Or that it will be hard to deploy my program on a user’s machine. Or that this language was created before OO became mainstream and its support for new paradigms feels retrofitted and creaky.

Or that its support for floating point is very poor. Or that its thread API is primitive and the author of the language keeps saying that it’s no big deal and that you can do without that. Or maybe it doesn’t have any Web framework that supports internationalization, a clean MVC model or out-of-the-box testing. Or I want to write a client application that leverages its host operating system but all that it offers is an ugly-looking user interface and leaking metaphors.

None of these defects take away the pleasure I derive from sometimes straying off the beaten path and writing code in an exotic language, but it does set my mind into a mode that tells me that this piece of code will never be promoted past the “toy” status.

Toy listings are great for sniped blog entries, but a mainstream programming language they do not make.

Whatever your favorite language is, be it Scala, Ruby, Python or Groovy, I’m with you. I really am. I understand the warm glow you feel when you write code in your language because I feel it too. But what you need to understand is that there is very little chance that your language will displace Java in any way in at least the next five years to come.

But please, keep posting cute code snippets that show how great your language is, because I love to be challenged in the way I think and indirectly, Java benefits from all these great ideas that keep being posted in the blogosphere.

Has Ruby on Rails become mainstream?

A friend of mine recently contacted me about my entry called Why Ruby on Rails won’t become mainstream and is asking me if I’m still of this opinion. I thought that revisiting this topic would be a good way to start the year, so here goes…

My first reaction was to go to and and check out a few numbers. Here are some preliminary results:
Ruby on Rails243190
Java14996> 5000
C#6886> 5000

These numbers are fairly consistent but since the data sample is relatively low, you are welcome to dismiss them as not representative, but that won’t stop me from elaborating a bit more on the subject…

My overall impression is that Ruby on Rails has settled in a niche that is probably not marginal any more but is still a far cry from being any close to mainstream. I’m also betting that this mindshare will probably not grow by much in the coming year, so it will be interesting to revisit this prediction in one year from now.

At any rate, I would say that my concern with Ruby on Rails has shifted in a few subtle ways. The problem is no longer that it won’t become mainstream but that it suffers from a few blemishes and flaws that still make betting an entire business on it a risky call plagued with limits that even the most determined entrepreneur will have a hard time overcoming.
Here are a few random thoughts:

  • From a developer’s perspective, finding a job in Ruby or Ruby on Rails is probably not extremely hard, although it’s still much harder than finding one in Java or C#, but it seems to me that the very fact that Ruby is a niche is what allows the few developers that are fluent in it to locate paying jobs with reasonable salaries (at least, it seems to be the case around me, but I live in San Francisco so my personal data sample is probably a bit biased).

  • The lack of powerful IDE functionalities such as refactoring for Ruby (and Ruby on Rails is much worse off) is still a concern and limits tremendously the pool of developers that Ruby can tap into (see below for some elaboration on this topic).

  • Let’s suppose we can rank developers on a scale from A+ to G-, G- being “terrible” and A+ being “stellar”, I claim that in order to implement a similar product, you will need a team of B+ Ruby developers while a similar result could be achieved with a team of C+ Java developers.

This echoes one of the points I made in my original article: Ruby on Rails is sometimes too clever and too magical, and it takes quite a bit more of intellectual effort to understand how it works than it takes to understand how a servlet or even an advanced framework like WebWorks works. I also suspect that in order to be efficient with RoR, you need to practice it every day. Stop using it or abandon a certain section of your code for a few months and I’m afraid that the combination of Ruby and RoR’s sometimes overbearing cuteness will lead you to a lot of hours trying to understand how your own code works (RoR’s tendency to have a lot of implicit defaults or source files in different directories magically connected to each other doesn’t help).

Let’s go back to the developer quality argument: not only do you need smarter developers when you’re writing a Rails application, there also happens to be *less* of these smart developers, since the pool of Ruby programmers is dwarfed by that of Java.

In short, you need better people picked from a smaller pool.

This is potentially a deadly hurdle for start ups that have passed the prototype stage and are now trying to grow their business and their product. They can no longer afford to be picky: whenever they find someone who appears to be good enough, they need to hire him, regardless of any other potential flaws.

And to conclude this brief opinion piece on something even more gloomy, Zed Shaw, the author of Mongrel, a very popular Ruby framework and someone who’s highly respected in the Ruby community (albeit probably not for much longer), posted this very morning a scathing summary of his experience with the Ruby on Rails community. It’s not pretty, it’s very abrasive and probably laced with as many inaccuracies as correct statements, but I’m pretty sure a lot of Rails programmers will relate to some of the anger and frustration that Zed feels.

So do I still think that Ruby on Rails won’t become mainstream? Yes. Definitely. And even if I’m wrong, it will take many years before Ruby on Rails can come even close to the numbers displayed by other popular languages and web frameworks.