[UPDATE] My friend, Mat pointed out that this post isnt really about compiled vs interpreted languages but rather static vs dynamically typed languages.
Its always interesting to see the conflict between developers who love and those who hate interpreted languages. It often feels like the developers’ equivalent of a generation gap, with a lot younger developers preferring interpreted languages like Ruby and Python over things like Java and C. An interesting post I read on why Web Applications Should Be Compiled which is an interested read, though a bit strongly worded against Ruby. I quote:
The whole philosophy behind Ruby is that the machine should be the servant, not the coder. This is madness. We’re engineers, and we make machines work. You use the best tool for the job to do that. You don’t choose some pretty language that “brings back the joy of coding” or equivalent hippy shit. This is analogous to hiring someone to build a house and having him tell you he’s not going to use conventional materials like wood and steel because they aren’t as fun to use as Play-doh.
The performance argument is often valid. No ruby developer can claim that it can outperform its compiled brethren, though there are signs that this could be changing, with news like JRuby outperforming Ruby C. The core reason people who love interpreted languages is that it gets the cruft out of the way, allowing developers to think more of the business problem.
So how does this debate affect me, considering most of my work is in client side languages like Javascript or Actionscript?
The last few months I have been working with Javascript and have slowly started appreciating it quite a bit. One of the reasons I wasn’t pulling my hair out with cross-browser javascript is because of the JQuery library. JQuery syntax is really nice and I love the chaining feature. For example the purpose of the following line should be pretty self evident:
$(".mydiv").width(200).height(200).bind(click, function(){ alert("I got clicked") }).css("visible", true);
The actionscript equivalent would be something like:
mySprite.width = 200;
mySprite.height = 200;
mySprite.addEventListener(Event.CLICK, function(event:Event){"I got clicked"});
mySprite.visible = true;
I hate the zig-zag i have to do to read AS3 code, so while extending OpenPyro I figured I could make my methods return the object instance back, that could be used to further set properties on the object.
So say my UIControl had a function like setSize(w:Number, h:Number):UIControl and setVisible(val:Boolean):UIControl, I could use them in chaining like:
myControl.setSize(200,200).setVisible(true);
nicer right?
But now imagine you extend UIControl to make it a button and add functions for setLabel(str:String):Button and setIcon(icon:DisplayObject):Button. Note the return types have to be Button so that I can do something like this:
myButton.setLabel("print").setIcon(printer_png_instance);
Now for the fly in the ointment: Lets try chaining this:
myButton.setLabel("print").setIcon(printer_png_instance).setSize(200,200).setVisible(true);
works fine. but
myButton.setSize(200,200).setVisible(true).setLabel("print").setIcon(printer_png_instance);
fails. Why? Because the compiler sees setVisible returning a UIControl but then trying to set the label property on that control. At runtime, the returned instance is a Button but the compiler cannot check that. The only way to do chaining would be to cast objects appropriately for the compiler but at that point, the elegance and readability of the single line is lost.
And that is the core problem. Compilers are stupid and completely depend on the return type information defined in the method signature. I could return Object datatypes for all methods but the performance hit would be pretty severe.
As I write this a new direction comes to mind. Doing $(”#mydiv”) in JQuery doesnt actually return a div but rather a jQuery wrapped set. Maybe a AS3 equivalent could be created using Actionscript 3’s Proxy class
Hmmm…stay tuned for a followup post.
Epilogue:
Returning for a bit to the previous quote chastising developers on choosing Ruby, a counterpoint can be found on why developers at Twitter chose Scala:
The other big reason we looked at Scala was that, although we’ve run into problems with Ruby, we like the flexibility of the language. We like that it’s such a full featured language, that it’s fun to code in. … We know that people write super high performance code in C++, and engineers like Steve and Robey have had experience with that. But we wanted to be using a language that we’re really passionate about, and it seemed worth taking a gamble on Scala.
I think programmer productivity is a factor of more than the programming languages, its also dependent on the developer’s passion for the language.
