Scala ends the Groovy fad

Looks like Groovy is going to loose its steam.

Two reasons: tooling and governance.

Tooling is a critical element as the code base and number of involved engineers increase. Refactoring in a single code base which involves a dynamic language and dozens or hundreds of engineers may lead to hairy situations. When you change a public library API in Java your tool will let you know where is the effected code, update the references for you and will let you know if a contract is getting broken. Tests should locate problems created by refactoring, but:

• Groovy engineers (and not only them) are sometimes too cool to do a 100% code test coverage.
• Even a 100% test coverage can not guarantee that there are no bugs, it can only confirm that the test code didn't find bugs.

Typical refactoring problem with Groovy might be changing Java code like:

public int getProductID();

to:

public ProductID getProductID();
class ProductID{
  int id;
  VendorID vendorID;
}

So if you have a method in your Groovy shopping chart that gets a productId and compares it to a local product id it will not break the code. I.e., no method names where changed and the compare with int and object will simply return false. If the method is rarely used and not tested, or tested only in a way that supposed to return false then you won't find it before your user, and they always find these things.
Prime large scale products can not afford this.

Most of the claims I heard for having dynamic typing is for cleaner and smaller code. Yes, you may have strong typing in Groovy if you wish, but then your back to ugly Java code. With the amazingly comfortable type inference in Scala, you enjoy both words.

The second reason is governance. Both Groovy and Scala are still in the youth where the Cathedral model is the only way for them to react fast and efficiently enough to feedback from the market. Unfortunately Groovy is JSRd. On its face it looks good, hey - what's wrong with Democracy? Well, it appears that its not the best way to run an engineering project and in some case it locks the product in infinite politics games and narrow interests of the few in charge.

Scala prez by Twitter

Nice presentation, learned few things from it. One of them is that Scala is supported by JavaRebel which is in use @ LinkedIn too.

Why Scala?

View SlideShare presentation or Upload your own. (tags: c4 scala)

No closures in Java 7

Ricky's technical blog: Java Just Died (no closures in Java 7), referring to a tweet.
As Neal Gafter wrote in his blog post Is the Java Language Dying? "...we should place Java on life support and move our development to new languages such as Scala...". Yea, I know I abuse the quote, but its not too bad.
Actually I think Java is going to be around for a long while, like Cobol, there is just too much good tooling around it.
Fortunately, it will not be too hard to switch to Scala being statically typed and thus stable in a large code base and tooling friendly. Haven knows how much grief you can have in a very large code base with refactoring and not statically typed languages like groovy, ruby, python.

Had to add this one: "I'm not dead yet!"

Great Dijkstra quotes

Taken from his Dijkstra's interview video

• Computer science is no more about computers than astronomy is about telescopes.
• The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task in full humility and avoids clever tricks like the plague.
• We should not introduce errors through sloppiness but systematically keep them out.
• Program testing can convincingly show the presence of bugs but it is hopelessly inadequate to show their absence.
• Elegance is not a dispensable luxury but a factor that decides between success and failure (is it about Scala ?).

Its a nice video which also explains well why Alan Kay said that arrogance in CS is measured by nano-Dijkstras.

Scala only Spring RPC/Remoting Service: works

I know it should work, but didn't see and reference that it does. So I tried it out and, of course, it does.
Since the service object will be represented by an AopProxy which is basically a Java proxy, you must have the service to implement a Java Interface (proxy can be created only to interfaces). Scala does not have the notion of interfaces like Java, but the language creators did invested a lot in compatibility with java. Creating a plain Scala trait spits out a POJI (Plain Old Java Interface), which solves the issue. And even though declaring checked exception is not native to Scala, they did enabled the special throws annotation for that which helps in case your service must declare some kind of remote exception.

Here is sample interface that you would create to your spring service:

trait ScalaService {
  @throws(classOf[MyRemoteException])
  def bar(info: MyInfo)
}

And this is what you'll get by running javap on it:

Compiled from "ScalaService.scala"
public interface ScalaService{
    public abstract void bar(MyInfo) throws MyRemoteException;
}

Is object creation is Scala really faster then Java?

The argument is that it should not be that case since Scala compiles to Java class files and runs on the same JVM/JIT, hence they are actually identical.

In my other post I claimed that for the benchmark I wrote, Scala object creation is faster. Actually, it took about 323 nano to create the java object set and only 221 nano to create the scala object set. I.e. it took about 46% more time to create the objects in Java then it would in Scala. Its pretty significant.

The code is out there so I urge you to check it out and prove me wrong.

Here is the code for creating Scala objects (from a Java Class):

public MediaContent create(){
 Media media = new Media("http://javaone.com/keynote.mpg",
 "Javaone Keynote", 0, 0, "video/mpg4", 1234567, 0,
 123, null, Player.JAVA());
 media.addPerson("Bill Gates");
 media.addPerson("Steve Jobs");
 Image image1 = new Image("A", "Javaone Keynote", 0, 0,
   Size.LARGE());
 Image image2 = new Image("B", "Javaone Keynote", 0, 0,
   Size.LARGE());
 MediaContent content = new MediaContent(media);
 content.addImage(image1);
 content.addImage(image2);
 return content;
}

Here is the code that creates the matching Java object set:

public MediaContent create(){
 Media media = new Media(null, "video/mpg4", Player.JAVA,
    "Javaone Keynote", "http://javaone.com/keynote.mpg",
    1234567, 123, 0, 0, 0);
 media.addToPerson("Bill Gates");
 media.addToPerson("Steve Jobs");
 Image image1 = new Image(0, "Javaone Keynote", "A", 0,
    Size.LARGE);
 Image image2 = new Image(0, "Javaone Keynote", "B", 0,
    Size.SMALL);
 MediaContent content = new MediaContent(media);
 content.addImage(image1);
 content.addImage(image2);
 return content;
}

The code as you see is almost the same. There is a minor difference with param order in the contractors, should not matter a bit, and the reference to a Scala enum Size.LARGE() which is not a real Java enum. The hidden nugget in the story is the usage of lists in Scala and Java. In Scala lists are immutable so you throw the old list once you added a new element to it. As Itay mentioned, the object immutability might makes the implementation faster.
You can also compare the Scala class set and the Java class Set and check out the benchmark runner. As expected from code I write for fun after midnight, it is fully documented for those of you who can read Java and Scala.

In Java, the way I handled lists is like this:

private List Images _images;//html generics format problem

public void addImage (Image image){
 if(_images == null)
   _images = new ArrayList Images();//generics format problem
 _images.add(image);
}
And in Scala:var _images: List[Image] = Nil

def addImage(image: Image){
   image :: _images
}