Strong typing epiphany
1st March 2006
It has nothing to do with skills at the keyboard, but with programming languages and environments. For the first time ever, while working on a small, self-contained script, I missed having static typing and a compiler to help verify what I was doing. I almost fell off my chair when I realized it.
Let’s back up and I’ll try to explain what this is about. As usual, I’ll ignore all kinds of details to try to get the idea across.
There are lots of different ways of classifying programming languages. One distinction that has always been relevant to me is that between scripting and compiled languages. Scripting languages (and here I’m including things like Perl, VBScript, and PHP) lack two features that, in my simple classification scheme, belong to compiled languages: strongly typed variables and, of course, compilation.
But that lack of features is, to me, a good thing. When trying to write a quick program, strong typing and compilation get in the way. Strong typing requires you to be careful about the way you use data and variables in your program — the way you handle things like numbers or text. Spending time to get that right can slow you down. Compilation is an extra step in the process. With a scripting language, you just write the code and then run it. But with a compiled language, you have to write the code, then compile it, then run it. That compilation step may only take a few seconds, but when you’re doing it dozens of times while building the program, it adds up. Edit-compile-run is a noticeable difference between Edit-run.
I have never doubted the value of strong typing, or static typing and type safety, anyway, in large programs with multiple people collaborating on it. There’s tremendous value in the structure those systems impose.
But until today I had never wanted those features/burdens when working on scripts. The script I’m working with is about 500 lines and was written several months ago. Now that we’re working on the next version of our product, the assumptions that were made when the script was first written are no longer valid — it needs to handle more possibilities.
So I’m reworking the script to handle these possibilities. And the logic of what I’m doing — the actual purpose of the script — is very simple. But there are enough variables and subroutines, and they’re used enough places, that there are plenty of opportunities to make mistakes, often just with a typo. Maybe the variable is abcVariable and the first five times I type it correctly, but the sixth time I type abVariable. With a compiled language, the error would be flagged before the program could run. But in a scripting language, I can’t know that the error exists until I run the program. You may have heard the terms compile time and run time. This is the distinction.
In this case, the script takes a few minutes to complete its work and restoring the system to its previous state (so that I could try the script again) takes a few more minutes. To make things even more dangerous, the script copies and deletes files. If I make a mistake in some of that code, I could erase a whole lot more than I intended. And it’s no fun restoring from backup.
So, working in the scripting language, I have had to pull bits and pieces out as I make changes and put them into another script, write a bit of code to run those bits and pieces, and test things piecemeal as I go.
This is the first time that I’ve been handling a scripting task where I would have been faster with a compiled language. It’s pretty darned surprising to me.
And, please, all you fans of Ruby or Python, don’t tell me I’m an idiot because your language could solve these problems. If I had the luxury of using Ruby or Python — or even taking the time to rewrite the script in a compiled language — I would. But we have a budget and I can’t spend enough of it on this to rewrite it.
March 2nd, 2006 at 22:38
Cool post Tommy. How long did it take you to realize? I mean - how long have you been using scripting languages and not realized you misssed static typing?
March 2nd, 2006 at 22:44
For pretty much as long as I’ve been programming in any serious way. Say, since 1991?
I’ll point out again that I have recognized — and enjoyed — the value of strong typing in collaborative development and big projects. But this was such a surprise because I was working on a single script, by myself, that doesn’t do anything too fancy.
March 8th, 2006 at 8:06
I think that’s brilliant. Especially how you reverted to a kind of defactoring and unit test to sort it all out.
Have you tried compiled JavaScript yet (on .NET)? I understand that the next version of ECMAScript is supposed to add optional strong typing on variables. It will be interesting to see how that helps in your situation.
March 9th, 2006 at 9:50
[...] Dennis — a.k.a. Orcmid — dropped by and left a comment this morning. He asked whether I had tried compiled JavaScript in .NET or not. [...]
March 16th, 2006 at 20:06
I’ve never thought of any connection between strong or weak typing and whether a language is intepreted or not. C is almost the definition of a language with weak typing. Ada is interpreted and strongly typed. A more modern example of a strongly-typed interpreter Python. Perl and PHP aren’t even really languages — they’re poorly designed hacks. Pascal — which is very strongly typed — could be gotten either as an interpreter or compiler way back in the day. All of the Modula-2 tools I’ve played with have been interpreters. Java can be interpreted or compiled. Forth is completely untyped but is usually compiled (except in OpenBoot firmware and toy demonstrations). And the beat goes on.