The War is On: Static vs. Dynamically Typed Languages
Written by Alex T. Silverstein
Monday, 24 December 2007
There's a flurry of debate going on about whether the Java programming language, as well as any others (including the .NET languages C# and VB.NET) using static typing are becoming (or will become) obsolete.
The argument goes like this: If you had to build a system that was projected to be at least 100K lines of code (LOC) in any statically-typed language, you could expect to reduce that mass of code by 50% (or more) using a dynamically typed language such as Ruby, Python, JavaScript, or Perl.
Many programmers would immediately object to the idea of creating a large-scale ("enterprise-class") system built using one of these languages, mainly because we have come to believe (or have been taught to believe) that static typing protects us from ourselves.
Admittedly, at compile-time, it is helpful to know if I've made a mistake in typing. But in practice, how often does it happen that I try to send a number into a method that expects a string and vice-versa? Pretty infrequently. And when it comes to passing objects, almost never. So we have to ask, what do we gain by using these verbose languages that we hold so dear?
Let's take the example of defining a property in C#. To do this right, you need at least 10 lines of code (including field and member definitions, initializations, null checking, and so on). We have to ask whether having all this boilerplate outweighs the potential maintenance savings gained by dynamic languages. Is it really necessary when the same can be done in one or two lines?
True it is, that, thanks to the Visual Studio IDEs, you can just type in "prop" and this particular bit of boilerplate will be generated for you. But we have to keep in mind that the VS IDE cannot auto-maintain your code for you (not yet anyway)!
In the case of .NET 3.5, we can reduce property boilerplate code to a tolerable minimum by using "automatic properties". Instead of 10 lines, you need only 1.
Would continued development of languages and IDE features that permit less verbose code to achieve the same type support be acceptable? Given the amount of code we need for complex applications it seems that compile-time type safety is vital to code stability. In a perfect world where we have unit tests for all areas of our code base, catching problems in a dynamic typed language would be easy. But we all know that we don't live in that world.
Sure, we all know our own code. We all know the code we've worked with. But what about bringing new developers up to speed? Having compile-time warnings and errors is critical, IMO.
At my day job, there are only two of us who have been there, on the enterprise team, longer than a year. A major part of our time is spent bringing new developers up to speed, whether that's via personal mentoring or through code reviews and team meetings. I'll take any compile-time advantages I can get.
That's not to say dynamic types are without value - not by any means. But I think it may be more a case of, everything has its place ...
