Is your language strongly, weakly, statically or dynamically typed?

Would you describe a programming language to be strongly typed, weakly typed, statically typed or dynamically typed? People often use the terms "strongly typed" and "statically typed" interchangeably, and likewise "weakly typed" and "dynamically typed" are often used to mean the same thing. I think this imprecision of terminology is unfortunate. That is, the definition of strong v.s. weak typing is so vague that I would claim it's possible to see them as completely orthogonal concepts.

Revealed: my top secret Grails project

I have mentioned in previous postings that I had been working on a Grails project, but neglected to actually say what that project was. Jelastic not only hosts this project on their PAAS cloud, but Judah Johns of Jelastic was kind enough to interview yours truly on their blog:

The Jelastic Spotlight: My Hometown Video

Now that My Hometown Video (HTV) is out there, it seems unnecessarily bashful to avoid blogging about this project. HTV is the brainchild of my client, Rob Roddenberry, who wanted a way for communities to form around towns of interest. Perhaps you might be nostalgic about a town you grew up in, or would like to tour attractions (parks, beaches). That's where HTV comes in: to provide location-centric videos and discussions. A longer explanation and more screenshots are in the Jelastic spotlight link above, but the best way to check it out is to visit the HTV site.

This has been a fun project. While I have a day job building enterprise Java applications, this is one site that I could sort of call my own. It really belongs to Rob, of course, and is entirely his idea. But it is satisfying to be get to do "everything" at the technical level including UI, server, DB, provisioning, deployment and operations. Grails has been fun to work with, and I find it interesting that every single Jelastic Spotlight application up to HTV has been a Grails app. The presence of public APIs like Facebook's and easy-to-use PAAS offerings like Jelastic has made such applications so easy to turn into reality.

The language wars and the TIOBE index

Recently, I had a bit of fun by writing a modestly titled blog post arguing in favor of Groovy's adoption over Scala. Among other things, I pointed out that the Indeed.com job trends graphs show much stronger Groovy adoption over Scala. One comment there made the interesting observation that the TIOBE Programming Community Index said precisely the opposite. I did not exactly carry out meticulous research so I confess I did not pay attention to this index when I made that blog post. I thought I'd remedy that oversight in this post.

My Groovy can beat up your Scala

This blog entry is inspired by a blog post I read recently bashing Groovy in favor of Scala. I will opportunistically join in the brawl, contributing my 2 cups of kerosene to the flames by coming out in favor of Groovy.  If you are not interested in the language wars, or if you take this sort of thing way too seriously, feel free to skip this post.

I like Groovy. At my last job, I used Groovy almost exclusively as a "better Java", on top of the typical Spring/Hibernate  stack. I did not use Grails at all, except briefly on a minor project. Even though I had a grand time with Groovy, I never thought of Groovy as the heir to the Java language. A new language will eventually replace Java, I figured, but it would not be Groovy. Whatever the merits or demerits of dynamic typing, I thought, the Java community, platform and class libraries were geared towards static typing. Also, Groovy was too slow. Recent developments have made me question my assumptions.

On conciseness

I meant to write this thought for a while, but a recent blog post about implementing the Quicksort algorithm in Scala finally prompted me to write this. As a refresher, here is pseudocode from the Wikipedia entry on quicksort that illustrates a simple version of the algorithm.

function sort(array) // pseudocode from Wikipedia
    var list less, greater
    if length(array) ≤ 1 return array  
    select a pivot value pivot from array
    for each x in array
        if x < pivot then append x to less
        if x > pivot then append x to greater
    return concatenate(sort(less), pivot, sort(greater))

From the Groovy in Action book, here is a Groovy implementation. It works on a List of objects that implement the compareTo() method. The findAll method returns elements from the list that satisfy the given expression, with "it" representing the object in the list.

def sort(list) { 
    if (!list) return list
    def pivot = list[0]
    def less    = list.findAll {it < pivot}
    def same    = list.findAll {it == pivot}
    def greater = list.findAll {it > pivot}
    sort(less) + same + sort(greater)
}

What I find significant about this example is that the real-code, working implementation of an algorithm is every bit as concise and readable as the pseudocode used to explain the algorithm.

From the same book, here is a Java implementation:

    public static void qsort(Comparable[] c,int start,int end){
        if(end <= start) return;
        Comparable comp = c[start];
        int i = start,j = end + 1;
        for(;;){
            do i++; while(i<end && c[i].compareTo(comp)<0);
            do j--; while(j>start && c[j].compareTo(comp)>0);
            if(j <= i)   break;
            Comparable tmp = c[i];
            c[i] = c[j];
            c[j] = tmp;
        }
        c[start] = c[j];
        c[j] = comp;
        qsort(c,start,j-1);
        qsort(c,j+1,end);
    }

    public static void qsort(Comparable[] c){
        qsort(c,0,c.length-1);
    }

This contrast is not completely fair to Java, since this Java version does an in-place sort of the array. Nevertheless, I think it illustrates the look of typical Java code.

Clearly, the newer JVM languages like Groovy allow for concise code. But I suggest that the real value of such conciseness comes not from reduced typing, but from the improved readability of the resulting code. You will read a piece of source code far more often than you will write it. It helps enormously -- whether you are enhancing or debugging code -- if you can comprehend meaning of the code immediately. In this example, the Groovy code's meaning comes through as clearly as the pseudocode. By contrast, the Java code is cluttered with the tedious mechanics of achieving the desired result. Here, the Groovy code emphasizes the what -- the meaning -- while the Java code emphasizes the how -- the process.

Of course, if performance is the primary consideration then it makes sense to write less concise code. See, for example, the various implementations of Quicksort in java.util.Arrays. And I am glad that we have performance-tuned libraries. But most application code has little impact on overall application performance, and for such code I suggest that the readability and conciseness that comes from the expressiveness of languages like Groovy is a big win.

NESS 2009: The Coming Spring

One of the sessions I attended at the recent New England Software Symposium is the one on new features in Spring 3. This covers Spring Core functionality. This session got my attention because the presenter was Craig Walls, who wrote Spring in Action. The main features he covered were:

• Spring Expression Language (SpEL)
• Spring MVC annotations (@PathVariable, @RequestHeader, @CookieValue, @RequestParam defaults), some to support REST.
• jsp tag to generate context-sensitive URL
• Declarative validation of some sort that may or may not make it
• Etag support
• HiddenHttpMethodFilter (more Spring MVC REST support)
• ContentNegotiatingViewResolver
• RestTemplate
• JavaConfig (Java-based alternative to XML wiring). This has been around for a while, but is being bundled in Spring 3. 
• Object-to-XML mapping from Spring-WS
• Java 5 support

Logging: should I wrap?

Once upon a time, there was a de facto logging standard, log4j. Then Sun decided to confuse matters by introducing another -- and many say inferior -- logging API in JDK 1.4. Some people responded with Jakarta Commons Logging (JCL), a wrapper that abstracts away these two APIs. Some other people decided that JCL was awful, and wrote SLF4J, a wrapper that abstracts away the first two APIs and JCL. There are also other logging implementations like Logback and x4juli, but fortunately these natively implement the existing APIs so they don't multiply the confusion.

If you start work on an existing project, I suppose you'd use whatever logging API is already in use. If on the other hand you are lucky enough to start a brand new project, you have to choose from a number of logging APIs:

• log4j
• JDK Logging
• JCL
• SLF4J

The conventional wisdom is that if you are writing a component or library, you'd likely choose one of the wrapper APIs (JCL or SLF4J) since you won't have control over what logging implementation the actual app will use. On the other hand, the conventional wisdom continues, if you are working on a standalone application you might as well code directly to the native APIs since you can pick the logging engine and are unlikely to switch. Even SLF4J's docs say that you needn't bother with SLF4J for standalone applications.

I have joined projects that build J2EE applications almost from scratch, so we got to pick the logging API. My initial inclination was the direct approach: we'd code directly to log4j. After all, why add an unnecessary abstraction? In one project, we ended up using SLF4J, even though we had no intention of switching logging engines. Why? Well, it turns out that SLF4J has a useful feature that log4j does not: parameterized logging. Ordinary logging messages incur the overhead of building the log message even if the message will not be logged at the current log level:

logger.debug("Value of obj#" + i + " = " + obj.toString());

All that work will be wasted if you are logging at the INFO level. The performance penalty could be significant if obj.toString() is particularly heavy. You could wrap that line in an "if (logger.isDebugEnabled()) {...}" block, but that adds clutter. SLF4J lets you defer evaluation of any String conversions until the line is actually written:

logger.debug("Value of obj#{} = {}", i, obj);

Does this minor convenience justify throwing in yet another 3rd party library? We did not need to answer that question. In a substantial app, there is no extra overhead. Quite likely, as in our case, the third party libraries you use will require JCL (e.g., Spring) and SLF4J (e.g., Hibernate) anyway. It's up to you to choose the API for your own logging. For us, SLF4J came along for the ride, gave us the parameterized expressions and still exposed powerful features like Mapped Diagnostic Context (MDC). Where is the downside?

In another project, we coded straight to the log4j API. This project was coded almost entirely in Groovy. In Groovy, we get lazy evaluation for free, so SLF4J offered no API benefits. The Groovy logging code below lazily evaluates its parameters regardless of logging implementation, and more concisely than SLF4J:

logger.debug "Value of obj#${i} = ${obj}"