Python from Wise Guy's Viewpoint

[Matthew Danish]

On Thu, Oct 23, 2003 at 12:38:50AM +0000, Fergus Henderson wrote:
> Pascal Costanza <costanza at web.de> writes:
> >Marshall Spight wrote:
> >> But why should more regression testing mean less static type checking?
> >> Both are useful. Both catch bugs. Why ditch one for the other?
> >
> >...because static type systems work by reducing the expressive power of 
> >a language. It can't be any different for a strict static type system. 
> >You can't solve the halting problem in a general-purpose language.
> 
> Most modern "statically typed" languages (e.g. Mercury, Glasgow Haskell,
> OCaml, C++, Java, C#, etc.) aren't *strictly* statically typed anyway. 
> They generally have some support for *optional* dynamic typing.
> 
> This is IMHO a good trade-off.  Most of the time, you want static typing;
> it helps in the design process, with documentation, error checking, and
> efficiency.  Sometimes you need a bit more flexibility than the
> static type system allows, and then in those few cases, you can make use
> of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
> "System.Object" in C#, etc.).  The need to do this is not uncommon
> in languages like C# and Java that don't support parametric polymorphism,
> but pretty rare in languages that do.

The trouble with these `dynamic' extensions is that they are `dynamic
type systems' from a statically typed viewpoint.  A person who uses
truly dynamically typed languages would not consider them to be the
same thing.

In SML, for example, such an extension might be implemented using a sum
type, even using an `exn' type so that it can be extended in separate
places.  The moment this system fails (and when a true dynamic system
carries on) is when such a type is redefined.  The reason is because the
new type is not considered to be the same as the old type, due to
generativity of type names, and old code requires recompilation.

I'm told Haskell has extensions that will work around even this, but the
last time I tried to play with those, it failed miserably because
Haskell doesn't really support an interactive REPL so there was no way
to test it.  (Maybe this was ghc's fault?)

As for Java/C#, downcasting is more of an example of static type systems
getting in the way of OOP rather than of a dynamic type system.  (It's
because those languages are the result of an unholy union between the
totally dynamic Smalltalk and the awkwardly static C++).

> >I think soft typing is a good compromise, because it is a mere add-on to 
> >an otherwise dynamically typed language, and it allows programmers to 
> >override the decisions of the static type system when they know better.
> 
> Soft typing systems give you dynamic typing unless you explicitly ask
> for static typing.  That is the wrong default, IMHO.  It works much
> better to add dynamic typing to a statically typed language than the
> other way around.

I view static typing as an added analysis stage.  In that light, it
makes no sense to `add' dynamic typing to it.  Also, I think that static
typing should be part of a more comprehensive static analysis phase
which itself is part of a greater suite of tests.

-- 
; Matthew Danish <mdanish at andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."