Friday, 17 January 2014

Dynamic and Static Languages

Recently, I had a small debate with one of my friend when he kept trying to use Ctrl + click to open method declaration for one javascript method (in Eclipse). I told him that it is impossible for the IDE to reliably find the declaration for whatever object in a dynamic language. He insisted that he has tried that before and it work.

I tell him that it is likely that the declaration of the object he found may be luckily appear on the same js file, that why Eclipse IDE manage to scan and find the method declaration.

To back my argument, I keyed in Static, Dynamic Type language and manage to find a good article that clearly explain about Strong, Weak, Dynamic, Static language

http://coding.smashingmagazine.com/2013/04/18/introduction-to-programming-type-systems/

If you manage to read the article carefully then you can see what I mean. Let say if you have two javascript files

script1.js
function foo (param){
alert(param);
}

script2.js
foo(“hello world”);

Can you expect the IDE to find the function foo declaration for you? Practically yes but definitely guess work. It is quite simple to see that we will never know if browser will load both script1.js and script2.js files. It is perfectly possible for browser to load another file that have another declaration for the identical function name and and you get another behavior when you call this function.

If you use jQuery before, you should notice this behavior. jQuery register themselves as $. If you create your own $ function, you may accidentally override jQuery methods and all usage and jQuery will throw errors in runtime.

On another occasion, I used RadRails to debug one legacy Rails application. Fortunately, the finding reference work quite well because the IDE automatically scan all the .rb files in the workspace. However, it only work up to a point when there is external library linked up by relative path like this:


require "#{File.dirname(__FILE__)}/../foo_class"

Apparently, the IDE do not know what exists in the parent folder of the current application and it does not try to guess by linking to other project. This is where Java is shining. If you develop Java application now a day, it is likely that you will use Maven to control scope of dependencies or some framework that support dependencies management (like Play frameworks). Whatever way you do, you will not start a project without knowing what will be available in your Virtual Machine. You know all of the classes that can be accessed from compile time. With that knowledge, the IDE become powerful, especially for refactoring. Throughout my years of experience, I prefer dynamic language to write simple, no legacy integration, minimal maintenance application. When the project grow bigger and bigger and change happen often, static language becomes more necessary.
One of my friend has decided to convert his jQuery based application to GWT just for the sake of quick refactoring. Imagine if you have more than ten thousand lines of code, developed by more than 10 developers and you get change request everyday. Finding which behaviour has been bind to which event and change it finally become too tedious that he moved the whole code base to Java and use GWT to translate it to Javascript. Finally, it was a good choice that the maintenance time dramatically dropped and there is no noticeable performance change.