dow.ngra.de

One of the main problems brought out when comparing dynamic languages to static ones is lack of proper refactoring support. It is usually implied that dynamic languages are not conceptually refactorable, which speeds up code rotting.

Although there is plenty of evidence that dynamic languages do support refactoring, I’d like to concentrate on the other claim — that statically typed languages are refactorable. Challenging this claim may seem laughable, as there is no lack of refactoring tools for Java or C#. But let’s examine a more advanced language that is touted as Java successor — Scala.

Scala supports structural types, which allow treating classes as records of methods that can subtyped by the presence of appropriate methods. This example was given in the Scala 2.6 release notes:

In this code the type { def getName(): String } refers to any class with the method getName(): String in it. Now what happens if we try to rename the method in the structural type?

1. We can rename all the instances of the getName() methods found in all classes anywhere.
2. We can just rename the method in the structural type and update everything else manually

Both of these approaches are useless. The first one is basically a search and replace done on all code and may rename methods that we never intended to rename (e.g. getName() in the Person class). The second one doesn’t really do anything for us.

The truth of the matter is that structural types miss an inherent scope associated with nominative (i.e. usual) types. Since every method signature in a nominative type originates from a single type, it gives refactoring a natural scope of all the subtypes of the originating type. Without that scope many refactoring techniques are essentially useless.

What is worse is that the presence of structural types also breaks refactoring in usual classes. E.g. if we try renaming getName() in the File type, we are also presented with a decision whether or not we can rename the method in structural type. And if we do rename it, we will break the code that accesses java.io.File the same way. Therefore if we want to refactor working code to working code we can again only rename everything or nothing at all.

Luckily it looks like the main refactorings broken by the structural types is renaming the methods and changing their signature. Unluckily these are the most common refactorings and having a same named method in any of the structural types breaks refactoring also in the usual classes. At the moment this mainly affects Scala and some other functional languages, but if the structural types become more spread it may come to a language near you :)

Interestingly, Cedric Beust brought out that you can refactor structural types as opposed to the duck types. Since I obviously think differently it would be interesting to hear his (and your) comments on the matter. Perhaps I’m missing something obvious?

There are quite a few reports about the happenings on Scala LiftOff, so I’ll just summarize my personal experiences, which might have been quite different from others:

• This was the first time I posed as the sponsor. The sponsor part sucked, since it made me feel I bought my way in there :) At the same time we got some attention, which was good. And the community itself was great!
• Scala selling points are static types, DSLs and actors. Lift selling points are AJAX and Comet. Everything else is just eye candy.
• Scala really needs proper clustering, persistence and transactions on top of Actor library (or rather beneath it?). I wasn’t sold that actor-d is that, although it could be on the way there. A lot of architects having to deal with JMS will be sold on that.
• Martin doesn’t care about legal issues. Someone else has to start caring or there will be trouble later
• Unconference is a great social event and facilitates discussion wonderfully. It is not that good for talks though. Some mixture would fit engineering gettogethers better, I think.

All in all it was a great experience and I hope participate next year as well. And for your viewing pleasure, here’s a shot of Martin Odersky from a different perspective:

The reason we’ve been kind of silent lately is that we are organizing exhibiting in three upcoming conferences: JAX, JavaOne and Great Indian Developer Summit. This year we (ZeroTurnaround) are doing some very hardcore promotional work and it is quite a lot of effort to organize it.

JavaOne has been by far the hardest. They sent me in total over 20 e-mails with pages and pages of rules and regulations. Just yesterday I got an 86 page form with which you can order services from the contractor. Apparently I may not bring in my suitcase with all the stuff we need to the pavilion unless I can carry it in my hands alone. Also I cannot take more than half an hour to put up the posters on our booth and etc. It’s not that I care that much about paying for their services, it’s just the time it takes to order through their bureaucratic masterpiece.

Luckily we also have some compensation for our troubles — namely, ZeroTurnaround is the Platinum sponsor of Scala LiftOff. It will be great to finally meet in person both Martin Odersky and Dave Pollak, not to mention other prominent members of Scala and Lift communities. Although I have not tried my hands with Scala as much as I’d have liked, but I have a belief in the language and the community and in any case it’s a much better contestant for Java pedestal than Ruby. I sincerely advice everyone in the San Francisco area at the time to come to this one-day unconference even if you haven’t played with Scala yet. You won’t regret it!

Of course, as always, dow.ngra.ders will cover all the conferences we attend. And this time it’s both Toomas and me that are going, so expect even more coverage, especially from Scala LiftOFF.

Static v/s dynamic types: I will look now into the pros & cons of static typing. What if it’s not really a technical but more of a psychological matter?

This is not exactly an eye-opener, but static types will create a mind map of the project code with considerably less effort than dynamic types. And as long as that map is not important (the project team is small and code complexity is within reason), dynamic types will outperform the extra kickoff needed to fit your design (or lack of it?) into a static paradigm. But when you have to share your code with someone else (even if its yourself in a while) then the dynamicity requires a discipline that is beyond most people.

BTW the constant refactoring debate does not really refer to static types as such, but rather static nominal types a la Java. E.g. in Scala you have structural static types, which cannot be refactored in any reasonable way. When the type system gets complex with a lot of partial structuring and type inference refactoring is almost just as challenging as with dynamic languages.

Evolution v/s revolution: “The fact that languages will improve over time, as software libraries already do, is exciting. It’s less scary than learning a whole new language.” — sorry, Nathan, but it’s not like that. Language is in a way a paradigm that a programmer accepts to build his software on. And paradigm shift is never evolutionary, so unless the changes to the language are small and backwards-compatible they can discourage innovation as software skills and libraries quickly become obsolete (try compiling a library from before 2000 on the latest GHC). Change and learning are necessary, but a stable foundation is also important.