Class Variable Question

[Patrick Wray]

"Pieter Nagel" <pieter at equinox.co.za> wrote in message
news:Pine.LNX.4.21.0104101931590.21742-100000 at bast.jhb.equinox.co.za...
[...]
> In fact, static type systems often force you to overspecify types too
> narrowly; which forces one to a) write all kinds of runtime-type or
> template or preprocessor gumph to get around the type system, which
> is in itself error prone, or b) have code duplication all over the
> show because the type system makes it too difficult to hoist the
> higher-level abstractions out the code.

I agree with these points, especially the part about "hoisting higher-level
abstractions out of the code". This is especially relevant for unsolved
problems, or systems that are likely to change a lot.

In my experience, the errors detected by static typing are usually mere
bookkeeping errors caused by fiddling and fussing with the type system
itself. Static typing forces you to mess with too many extraneous details
too soon, and the errors it detects are irrelevant to the problem you're
trying to solve. Hardly a big win.

This is one of the reasons why I like Python and Lisp so much. Being able to
postpone decisions about the internal representation of an object (or a
piece of 'knowledge' if you will) is crucial for quickly trying out ideas to
see what works best. Static typing makes an evolving system brittle by
'concretising' the abstractions too soon, unless you're lucky enough to hit
upon the perfect solution up front (which I don't think happens very often).

Once a system is very stable, it sometimes makes sense to fill in the
necessary type info for the compiler, or to enforce explicitly typed
contracts with users of the code, if that's your thing. But until then, a
static type system just gets in the way, causing more (real) problems than
it prevents, IMO.