| David A. Herman 2006-07-06, 7:02 pm |
| > His argument was this: Why would anyone *not* want the computer
> to find bugs *automatically* at compile time? (Ignore the practical
> difficulties for a second.) I have no problem with this *in
> principle*.
This is one of the two good reasons for automatic static type checking.
Coding in a typed discipline involves understanding and often documenting
the types of a program. Indeed, why not let the computer automate this?
The second reason, though, is that static type checking gives a programmer
the flexibility to *change* the data design. Documenting invariants in
unchecked comments is notorious for being prone to getting out of synch
with the actual program. When you document your types in comments (or
don't document them at all) and then make a change to the type structure,
you get no help from the computer. I was recently burned by a number of
type errors in a compiler I'm writing in Scheme, errors that had lain
dormant for months when I changed just a couple of the types in my AST
definition. This would have been trivial in ML; it would have caught all
of the modules that needed to change and guided me in all my refactorings
one by one. Instead, months down the road, I had to try to remember what
the changes had been and try to perform the type-checking algorithm myself
across the entire codebase. This didn't take minutes, but hours. And my
codebase is only a few thousand lines!
Just as you say, Joe, it's critical to give the programmer flexibility to
discover and reshape the structure of the program during the development
process. This is why I generally like languages with many equational
properties: they tend to admit a larger set of useful refactorings. But
types don't necessarily hinder this flexibility, they in fact increase it.
>
> That's the rub. I object to giving the computer hints about types
> (especially at the beginning of a project), and I truly object to the
> computer refusing to run any part of my program unless it *all* type
> checks. I also like to use type-ignorant constructs like lists; the
> type checker has a hard time with these.
>
> [SNIP]
>
> I don't like to declare types in experimental code because I really
> don't know what the type is at that point. Once the code is fairly
> mature and I'm happy with the design, it becomes rather obvious what
> the types are. At this point in the process I would welcome more help
> from the compiler.
I think that so-called "optional" type systems hold a lot of promise in
addressing your usage patterns. It's a hot research topic, and there are
lots of variants with different names: optional types, pluggable types,
static types with Dynamic, hybrid types, etc. Some of the literature is
bogus, but some of it has potential.
If you don't have to document types when they're obvious, or where there
are impedance mismatches, or where you simply don't know what the types
are, then the type system becomes a tool that helps automate the
programming process and facilitate refactoring, rather than an austere and
inflexible design discipline.
[color=darkred]
> Shriram Krishnamurthi wrote:
>
I hear this argument a lot, and it's true. But it's missing the fact that
type systems don't just catch errors, they facilitate *change*.
Dave
|