Challenging Java

There seem to be two completely divergent perspectives on programming languages and tools: one, coming primarily from industry, is currently focused primarily on "conventional" (i.e., not Smalltalk) object oriented languages, XML, XML-based frameworks, visual basic, SQL, etc. The other, coming primarily from academia, focuses primarily on research languages like SML, OCaml, Scheme, Haskell, etc., and on things like new type systems and tricks. Frequently, I find it frustrating that there's less interaction between the two, and a recent article on O'Reilly's OnJava about "four technologies to watch" to replace Java in the mainstream is a perfect example.

Article link.

The first thing that bugs me is his confusion about the value of dynamic programming. It's certainly true that dynamic programming has its proponents, and they would be happy to claim it has advantages[1], his examples miss the point completely.

Example 1:

class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello World!")
  }
}

vs.

puts "Hello, world."

It's certainly true that the second block of code -- written in Ruby -- is shorter than the first. However, this has nothing to do with whether or not "With Ruby, types are dynamic, so you don't have to declare them." The corresponding Haskell (which is about as strongly typed as you can get) is:

main = putStrLn "Hello, world."

His next example is equally classic: a Fibonacci function:

class Fib {
  public static void main (String args[]) {
    int x1 = 0;
    int x2 = 1;
    int total = 1;
    for (int i=0; i<10; i++) {
      System.out.println(total);
      total = x1+x2;
      x1 = x2;
      x2 = total;
    }
  }
}

vs.

x1, x2 = 0, 1
10.times do
  puts x2
  x1, x2 = x2, x1+x2
end

Again, the Ruby is much shorter than the Java, but it has nothing to do with Java's static typing. The corresponding Haskell is

main = print $ take 10 (gen 0 1)
     where gen x y = y : gen y (x + y)

The code is certainly not intuitive from the perspective of a conventional object-oriented language. But, at the same time, 10.times do is not necessarily any more intuitive to anyone not familiar with Smalltalk.

Neither of these examples really have anything to do with dynamic typing. They certainly address places where Java's syntax is more verbose than Ruby's, but the same terseness is perfectly expressable using statically typed systems (even type systems much more strongly typed than Java). This kind of basic confusion over terminology is a poor start to any discussion of programming language tools and terminology.

The remainder of the article, while not as blatantly wrong, does nothing to highlight anything particularly new in programming languages. Continuations are an old game in all functional languages, metaprogramming has been part of LISP and Scheme since the beginning (and is still very much around in Haskell, although in a different form), and I'm not even sure why he's excited about "conventions" instead of "configurations." While I'm happy to see XML start to lose it's position as the supposed be-all and end-all of data representations, I'm not sure it's a major world event either way.

More than anything else, this article highlights the way one toolkit -- Ruby on Rails -- can capture the mindset of most of the industrial programming world. Nothing in Rails is particularly new and different -- it mainly seems to be a clever hybrid of Scheme and Smalltalk -- but it's come in a new, exciting presentation. This seems to suggest two things:

First, for industrial programmers, it should suggest that the world of programming language research is a fertile one for new ideas. Unfortunately, it's not likely to, as long as articles like the one linked up above don't actually credit the true source of these ideas. As nice as it is to see continuations and meta-programming finally making their way closer to the programming mainstream, it's unlikely that this really heralds a new era of cross-over ideas, especially as long as the ideas that do cross over continue to be shrouded in the same object-oriented ideas that haven't worked for the past fifteen years or so.[2]

Second, for academic programmers (and others interested in research languages), it suggests that all it really takes to get their languages plenty of mainstream notice is one well-designed, timely framework. Unfortunately, most academic programmers are either employed doing something else, or put their spare time into other pet projects. While most of those projects are valuable, it's worth wondering how much more attention (and help) they would get with a wider market for the result.

The truth is, there's plenty of room for ideas to cross between research and production languages, even if the next version of Office isn't likely to be written in Haskell. Someone just needs to try.[3]

[1] As may have become obvious, I am not one of those people.
[2] Oh look, my next topic!
[3] Not me, of course. You!