Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!usc!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object
Subject: Re: A Hard Problem for Static Type Systems
Message-ID: <1159@tetrauk.UUCP>
Date: 7 May 91 09:10:44 GMT
References: <554@eiffel.UUCP> <1991Apr26.203642.17387@leland.Stanford.EDU> <556@eiffel.UUCP> <52166@nigel.ee.udel.edu> <1991May1.143831.2065@maths.nott.ac.uk> <1155@tetrauk.UUCP> <1513@fang.dsto.oz>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 43

In article <1513@fang.dsto.oz> dch@aeg.dsto.oz.au (Dave Hanslip) writes:
| rick@tetrauk.UUCP (Rick Jones) writes:
| 
| >anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
| >]  [ ... ]
| >] That is why it
| >] is easy to describe *situations* in which dynamic typing is desirable,
| >] but we have not seen a completely specified *problem* for which it is
| >] needed.
| 
| >This has to be the most succinct description of the relative advantages of
| >static and dynamic typing that I have seen - thank you, I agree entirely.
| 
| 
| Agree you may, but very few real-world, complex problems are ever completely 
| specified. Even if the specification process is rigorous, the customer never 
| knows completely what he/she wants and over the life of software the
| requirements will inevitably change. That is why it's not only acceptable in
| a finished system, but desirable.

Note that I didn't say that static typing is always better, but that this is a
very good definition of the strengths of each approach.  I know I have been
arguing the case for Eiffel's static type checking mechanisms - that's because
I am an Eiffel user, and some of the type checking concepts were clearly
mis-understood by some contributors to this newsgroup.

The system I am developing is in fact a two-tier model.  In simple terms, there
is a statically typed, hard-coded lower level written by application
programmers (in Eiffel), which supports a higher level, dynamic model which
will be configurable by users.  The high level model is in effect dynamically
typed (although it isn't a "programming language" in the conventional sense).
This enables the dynamic model to be configured very freely, but without any
danger of breaking the static model.

In the context of Dr. Walker's statement, the low level model has a behaviour
which IS completely specified - the system would not be reliable if it wasn't.
The high level model is not completely specified, and so is open to change and
is dynamic.
-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem