Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsc!lgm
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.misc
Subject: Re: An Interesting View of "Strong" Vs. "Weak" Typing
Keywords: typing, Ada, Lisp, definitions, evidence
Message-ID: <12886@cbnewsc.ATT.COM>
Date: 17 Jan 90 03:48:48 GMT
References: <1633@castle.ed.ac.uk>
Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,)
Organization: AT&T Bell Laboratories
Lines: 74

In article <1633@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
>type-secure module system then the abstraction mechanisms limit
>the amount of dependency between modules, so that changes are
>as localised as possible. Even for the inevitable global changes,
>if you trust the type system, then you can tend to make the changes to
>the support modules which provide the basic types, and let any
>changes to the types and sharing constraints propagate through.
>The work is done when the typechecker accepts the whole system
>once again.

My basic objection to this scenario is that multiple
modifications, sometimes spanning across the entire system, must
be made simultaneously in order to transition from one stable
system state to the next.  This presents several problems:

a) Source code may not be available for all parts of the system.
The wide-ranging adjustments which static typing can make
necessary - e.g., of inheritance relationships - may not be
possible.

b) Even if such source code is available, customer modification
may void warranties or other support.  Again, wide-ranging
adjustments may have to be ruled out for this reason.

c) Introducing a set of wide-ranging modifications simultaneously
increases the risk of catastrophic failure.  To prevent this, one
must typically conduct more extensive testing, delaying
introduction of new functionality - perhaps beyond the window of
profit opportunity.

Testing itself becomes more difficult, because the tester must
deal not with her/his own individual change, but rather an entire
set of (perhaps wide-ranging) changes, often made by different
people.

d) Simultaneous wide-ranging and interlocking modification also
increases the difficulty of change management.  The usual solution
- a more complex and bureaucratic change management system - slows
down development, again delaying feature introduction.

e) Some applications have extremely stringent availability
requirements (limits on downtime).  Under such conditions, taking
down a production system in order to bring up an entirely new
image is out of the question, except perhaps once every two years;
but a two-year delay in feature introduction is no longer
tolerable.  Such markets now demand "incremental update."

Even in lab testing situations, continual building and bringup of
entire images is an undesirable overhead and slows down the
development process.

f) Restricting each identifier to a single predetermined and
(usually) predeclared type, and restricting each function/method
to a predetermined and predeclared number and sequence of
arguments and return values, is fundamentally a bookkeeping
exercise which hinders programmer productivity.  Such restrictions
may be symptomatic of an attitude of rigid, centralized control
which, if applied uniformly throughout software development, leads
to higher prices and lower profits, and in the extreme case to
eventual exit from the market.


Perhaps my main point is a general one, applicable to many debates
of this kind:  Don't be closed to new approaches, even seemingly
radical ones, unless your current approach is absolutely
*delighting* your customers.  And even then, keep looking over
your shoulder...


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.