Subject: Re: Why typing?
From: Erik Naggum <erik@naggum.no>
Date: 1995/09/21
Newsgroups: comp.software-eng,comp.lang.functional,comp.lang.lisp,msu.cps.misc
Message-ID: <19950921T152258Z@naggum.no>

[Peter Hermann]

|   The benefit pays off in a drastic(!) reduction of programming errors.

the value is in early detection of programming errors, ideally causing a
reduction of programming errors in the running code, but this is not
necessarily the case as even those "errors" that there is no value in
detecting are detected, and "correcting" them only adds unnecessary
complexity to the program.

further, as the number of types increases (as it is wont to do when users
are encouraged to create their own types) and the interactions between
types increase (as it is wont to do as users need to involve the type
system in all the semantics that previously were implicit in less specific
types), the ability of even very intelligent and highly experienced
programmers to keep track of them and obtain the desired result in the
presence of overloaded operators is decreasing dramatically.

|   With strong typing you are even able to introduce dimensioning
|   of types. examples: inch, centimeter cannot be added.

they should be, and the result should be convertible to any unit of length.
be careful not to make your type system too narrow, or you run into the
problems outlined above.  if you have created a type system where "inch"
and "cm" are incommensurate types, you will have to write functions to add
functions of _some_ incommensurate types, but not others, i.e., manual work
to add such functions.  if you instead had a type for length, and it knew
the original unit in addition to the value in terms of the least common
denominator, you could add inches and centimeters, but you would have to
request a particular unit before the result could be displayed.

|   Dollars and D-Mark etc. etc.

but that is incredibly useful!  you would of course need to know the date
associated with a currency amount, with function that returned exchange
rates for a given date, so you could add them and obtain a meaningful
value.  also needed: future and indefinite dates with the ability to fix a
date (exchange rate) later.  in fact, you need dates in any currency type
whether you deal with multiple currencies or not.  in the presence of
inflation and interest, the value of a currency is time-dependent.

see the pattern?  if you create types that are too narrow, you will
seriously limit the usefulness of the type system, _and_ create a
complexity from which you will find yourself wanting, but unable, to
escape.  that's why less restrictive type systems win.

|   Mechanisms can be implemented with the features of a strongly typed
|   language, which inhibit the multiplication of kilometer*kilometer
|   giving kilometer but instead allow (only) kilometer*kilometer giving
|   squarekilometer Mechanisms of that kind enforce your abstraction for
|   the sake of preventing lots of programming errors.

seems that you need a "unit" system, not separate types.  may I suggest a
look at the HP 48 implementation of calculating with units?  they have done
it right.  it is unfortunately very complex to get it right.

this leads me to my second argument against strong typing.  getting a type
system right requires so much detailed specification that the cost is so
high that mistakes are actively discouraged.  this cost is not necessarily
offset by the benefits of using such types, especially not if the program
needs to adapt its speficiation to changing needs discovered only as the
program is being used in preliminary forms (often called "prototypes", but
I'm not sure building a prototype only to discard it and build "the real
thing" is a good idea.  it seems the projects that go into a state of
completion such that they are no longer learning from the experience of use
are extremely rare.  projects that no longer _can_ learn from the experience
of use is, however, quite common.

the cost of mistakes in type systems is often caused by poorly understood
or outright misunderstood relations between types.

my conclusion is that less strongly typed (i.e., dynamically typed) systems
are the ultimate type systems, because they allow growth and change, while
preserving the ability to use machine reasoning about types.  strict type
systems, where every "object" is a type, do not scale well because the
computer is not involved in the typing decisions, only in checking them.
still, some of the lessons of "object-oriented" programming in the Algol
family can be fruitfully employed in dynamically typed systems.  CLOS and
Dylan are both embracing the "inclusive object" where methods are added as
needed, instead of the "exclusive object" where methods must be known a
priori.

essentially, it is the a priori aspect of strongly typed systems that is
fundamentally unsuited to the process of acquiring the knowledge of the
types necessary to implement them and relate them correctly.

#<Erik 3020685778>
-- 
there's a car that has more computing power than it took to get man
to the moon: the BMW 750.  but _you_ are stuck here on earth.  haha.