Here is the final comparison of the Scala port of Heiberg's Java code. As always, comparing a port to the original is not quite fair because of accumulated cruft that gets thrown out.

The Java code was high quality, mostly idiomatic Java 1.1 code that was updated to take advantage of generics and for-each syntax. The main oddity was the use of public fields, which was convenient but made refactoring harder. Scala has no public fields (though it can use those compiled by Java), so that part of the port was annoying. There was a Pascal accent to the code, especially the avoidance of return/continue/break as well as nested if instead of && (due to Pascal's broken and semantics).

My Scala code improved greatly as I learned it while porting. However, there is likely still a strong Python and OCaml flavour to the code. In particular, I think my naming conventions do not match Scala's well. The lack of documentation on the language itself is a factor; there are a few good case studies, but if you stray from these you are on your own, especially for recent feature changes which seem to happen frequently. Interop with Java has almost no documention, partly because there isn't much there; however since both languages compile to the same bytecode, there isn't any magic required to write your own interop layer. Another area that is weak is the documentation of traits, which are equivalent to Ruby modules and close to Java's interfaces. Fortunately I was able to find some online discussion of how to make a Java class implement a Scala trait.

Compared to the previous analysis, the numbers have all dropped by hair; two percent each for words and lines and one percent for bytes. My bias for short, squat files still shows: Scala's word count is 2/3 of Java's but the line count is 1/2. Some of the longer lines come from my bias and some are an unavoidable consequence of functional programming. I promise I didn't stack ending braces Scheme-style! ( } } })