Why I don't believe in static typing

From: Erann Gat (gat_at_jpl.nasa.gov)
Date: 11/17/03 

Date: Mon, 17 Nov 2003 11:38:50 -0800

We've been having so much fun having theological arguments about the
relative merits of static versus dynamic typing I thought I'd spoil it all
by introducing an actual data point.

Once upon a time I wrote a credit card billing system for a company which
shall remain nameless. The company's product was on-line advertising
delivered by an ad server, which was already up and running. (At the
time, the company only had corporate accounts, which were billed
manually.) The number of ads delivered was written to a database which
the biller that I wrote would periodically scan to generate invoices. The
invoices were then automatically charged to credit cards on file. The
entire process was fully automated.

During the initial development of the system I had a run-in with a
high-level manager at the company who opined that my dislike of Java and
C++ in favor of Lisp was irrational, that the static type systems provided
by these languages provided a powerful and reliable mechanism for
introducing incremental changes to a system, to wit: you'd make a change
to part of the system, compile it, and the compiler errors would point you
reliably to all the other parts of the system that required attention in
order to support that change. The introduction of credit card billing
required some changes to the ad server which were done more or less
following that methodology by a very bright and highly competent engineer
(not me).

The system was launched and had been happily humming along for a week or
two when all of a sudden it began to issue outrageously large charges -
millions of dollars in some cases - to people's credit cards.
Fortunately, sanity checks at the credit card processor prevented most of
these charges from going through, but a few did, and sorting out the
resulting mess took a very long time.

The proximate cause of the problem was quickly determined to be in the ad
server, which was suddenly claiming to have served vastly more ads than
was physically possible. But the ad server was old software. It had been
running for months with no problems. So there we were, facing this
critical problem in what had been a stable piece of software with no idea
how to even reproduce it, let alone track it down.

To make a long story short, what happened was this: when an ad-server shut
down, part of the shut-down code did a final update of the database to
record all the ads that had been served since the last update before the
shut-down. But the ad-server was multi-threaded, and it turned out that
there was a race condition. The thread that did the final database update
used data structures whose destructors were being run in a different
thread. Kablooey.

I can no longer recall whether the changes made to support credit card
billing actually introduced the race condition or just changed the timing
so that a problem that had actually been there all along began to manifest
itself, but it doesn't matter. The point is this: the more kinds of
errors are flagged for you at compile time, the more you can get lulled
into a sense of complacency and start to believe that if a program
compiles without errors then it is actually free of bugs. This is
especially true if you are using a language that doesn't allow you to run
your program at all until you have eliminated all the errors that the
compiler could find. After all, it is not unreasonable to expect that all
the work required just to get the program to compile so you could run it
for the first time should pay a dividend of some sort, and what else could
that dividend possibly be other than having to do less testing?

So it is not at all clear to me that eliminating even a certain class of
run-time errors actually has net positive utility. The real payback from
compile-time detection of type errors is not a reduced necessity for
testing; it is instead merely a time savings, finding those errors sooner
rather than later. And if one does allow onesself to be deluded into
thinking that static typing does pay a dividend in reduced testing then
static typing could actually have a negative net benefit when the laws of
physics and mathematics come around to remind you that you were wrong.

E.

Relevant Pages

  • Re: RAD vs. performance
    ... All of the implementations are either slow to compile ... exactly the same for a dynamically typed language as it is for Ocaml? ... Then you're implementing static typing. ... course, I think you must), then it follows that dynamic typing does NOT ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... Then you're implementing static typing. ... type checking work to compile time as possible. ... that it is possible to invent dynamically typed languages that compile ...
    (comp.lang.misc)
  • Re: Problem compiling remote web in VS2005
    ... > remote webserver, which is highly unlikely that it could do. ... I develop from home on a staging server in the datacenter of my company ... computer create a new project and develop and compile on it from my laptop ... >> I've setup a new website in IIS, enabled .net, fpse, etc. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: XKB problem with x-terminal
    ... >>> Is there a way to compile keyboard definitions for X and save them ... >> where you can make the X server load it upon startup using the option ... * you can't keep the X server from wanting to call xkbcomp, ... * you are expected to specify the bare name of the keymap (without the ...
    (Debian-User)
  • Re: What Gets Deployed?
    ... server side code within the content pages will be compiled on the server as ... .pdb or other debug files) on a web server as the code has been compiled. ... I would suggest you are right and your over excited friend ... Content is simply copied; Compile is just that; ...
    (microsoft.public.dotnet.general)