One reason static typing doesn’t suck
Eric Redmond over at Death by Overcoding has posted a discussion on 5 Reasons Static Typing Sucks
It’s a great article, and I agree with pretty much all of it. For the most part excessive static typing is a PITA. The illusion of safety is just that. Static compile time checks only catch the most trivial of bugs, and even then, most of those would have manifested themselves the first time the code was even run. When it comes down to it, the trade offs of the traditional benefits of static typing (you don’t shoot yourself in the foot; you and the compiler always know what’s going on), are often outweighed by the disadvantages discussed in the article.
However, the one thing I’ve always liked when working with static type systems, and one that is often glossed over when discussing dynamic typing systems, is how easily tools can interpret and navigate code. When coding Java in Eclipse, it’s amazing how easy understanding a massive code base can become. You’ve got simple hyperlink navigation, sophisticated refactorings, and smart code analysis that can show you what is called from where and how. Even interfaces and figuring out which implementation is used (which is kinda dynamic typing for Java) can be groked easily with a good IDE.
Got a class with some methods? Want to find where it’s called from? Check. Want to find what methods can be called on the argument you’ve been passed? Check. Want to refactor a whole class hierarchy? Check.
I really love Ruby, but the first thing that struck me when I sat down to code is how much you’re on your own figuring out what is happening. Got a method with an argument passed in? What is it? What can you do with it? Dunno. Want to call another method? What arguments does it take? What about the block it accepts? What does it return? Dunno.
Dynamic languages are great for quickly writing simple elegant code, but not always so great for following and debugging existing code (especially code someone else has written).
Try digging into the internals of Rails, and you’ll become very familiar with the free text search of your text editor. What the hell is that variable? Where was it even instantiated? Dunno. Once you understand the general layout of the classes and modules its pretty straight forward, and thankfully Rails has a pretty well laid out architecture. Which is probably the whole point. If your Ruby code is clean and well designed, then obviously it’s going to be easier to navigate.
So really it comes down to good developers doing smart things. The size and complexity of a good Ruby code base is significantly less than something comparable written in Java for instance. As with most things in software development, this is about trade offs. Ruby is smaller and simpler, but the tools don’t allow you to refactor as easily as Java (the agile purists will say your unit tests allow you to refactor, but it’s still a lot more manual and involved than the automatic refactorings you can do in Java).
It means that in dynamic languages, its more important to have a good design so you don’t get lost in dynamic spaghetti down the track. But at the same time you’re more likely to have a good architecture in the first place because you’re not wasting mental energy focusing on satisfying the static typing system. One of the weakness of static typing discussed in the original article touches on that - the fact that more design must be done up front to predict the future when using static typing. With dynamic typing you’ve got less baggage stopping you from evolving your design as you work, so you can apply the YAGNI principle more easily.
…Although I do still miss being able to zip around Ruby code like I can in Java.
(Yeah, I know Netbeans is getting there, but it’s still a long way behind what you can do with tools analysing and refactoring static typed code).
A decade ago, people said you couldn’t do refactorings and static code analysis with Java. Maybe IDEs will evolve enough over the next few years will make this true for Ruby as well, and we’ll get the best of both worlds.
September 9th, 2007 at 2:18 am
“Static compile time checks only catch the most trivial of bugs”
That’s untrue. Static checks can catch all bugs. Perhaps not in your language, or with your tools, but they can, thanks to the Curry-Howard isomorphism.
“it’s amazing how easy understanding a massive code base can become”
I expect that programmers in dynamic languages tend to modularise their code more to alleviate these issues.
IDEs fail when you do more interesting things. For example, Java lacks method references, so I’ll make a Runnable:
new Runnable()
{
. . public void run()
. . {
. . . . otherMethod();
. . }
}
Now I can pass that around to anywhere that takes a Runnable, and the IDE’s “who calls this?” feature is useless. You can get more information from a running program plus source code than source code alone.
Interfaces and implementations really are not dynamic typing.
“Got a method with an argument passed in? What is it?”
Ask it.
September 9th, 2007 at 7:29 am
I’ll agree that the IDE tooling for Ruby is not quite there yet, but you should consider eclipse’ roots when discussing it’s features.
Eclipse evolved from VisualAge for Java which had evolved from VisualAge for Smalltalk. Despite the dynamic nature of Smalltalk, VisualAge for Smalltalk (and other Smalltalk environments) include fantastic code navigation, refactoring, etc.
It’s the dynamic nature of Smalltalk that allowed it’s amazing tooling. Ruby shares that nature with Smalltalk. It’s only a matter of time before the tooling is here for Ruby.
September 9th, 2007 at 2:10 pm
Julian - I agree with you… tooling is an issue. Massive systems are even easier to manage thanks to tools like Maven, and far easier to navigate thanks to Mylyn (formerly Mylar. If you haven’t used it - I highly recommend it).
Sadly AFAIK there is only one decent tool for managing large Ruby projects, and that is TextMate. Downside: it’s only available for Mac. It is probably the one good reason for owning a Mac, if there were no others. I’d love to see a Linux port - but I don’t see that happening (since the developer said they won’t).
Keep up the good work.
September 9th, 2007 at 3:45 pm
I couldn’t agree with you more: static typing can be indispensable for serious large projects that need to maintained for a long period of time. Signatures of methods and classes can be very helpful in clarifying “what part of code calls other parts”. This is an essential question that we have to ask when fixing a bug in legacy code, or when introducing a new feature.
Sure, one can use “coding and naming conventions” to clarify the design of dynamic code, or “ask the argument to a function about its type”, but this can easily become unmanageable in large teams or long projects.
I have done my share of coding in type-agnostic languages, but in most of these cases, the end result was a quick “one time” script or tool. When I sense that the life of the tool will become relatively long, I typically switch to a “static type” kind of languages.
September 9th, 2007 at 3:56 pm
I agree with the overall point, that the code navigation is nice. However, this has absolutely nothing to do with static vs dynamic typing. If anything it has to do with strong vs weak typing.
Ruby, and Java, are both strongly typed, and there is no problem doing find usages, navigate to definition, and the other basic refactors. As a matter of fact. The only place that a refactor may fail is in the case of passing blocks, closures and continuations.
The reason the tools aren’t there is support. Ruby didn’t have much support until Rails came around. Now Eclipse (via RDT) and NetBeans are making large strides. There is no reason that TextMate shouldn’t have the ability to refactor soon.
Expanding on flexpert’s point: Not only did SmallTalk have excellent code navigation and refactoring support, SmallTalk is where the refactoring support was first conceived.
September 9th, 2007 at 7:34 pm
2 ricky clarkson:
Show me programming language which will catch bugs in specification?
Nothing CAN’T catch ALL bugs
September 10th, 2007 at 9:03 am
Show me programming language which will catch bugs in specification?
INTERCAL!
February 28th, 2008 at 5:04 pm
Used netbeans? you oughta look it up. netbeans dot org