Newsgroups: comp.software-eng,comp.lang.functional,comp.lang.lisp,msu.cps.misc
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!delmarva.com!newsfeed.internetmci.com!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!oleane!simtel!harbinger.cc.monash.edu.au!bruce.cs.monash.edu.au!mmcg
From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Why typing?
Message-ID: <mmcg.812867053@bruce.cs.monash.edu.au>
Sender: news@bruce.cs.monash.edu.au (USENET News System)
Organization: Computer Science, Monash University, Australia
References: <43pl5a$fok@msunews.cl.msu.edu> <43rcpn$26re@info4.rus.uni-stuttgart.de> <19950921T152258Z@naggum.no>
Date: Thu, 5 Oct 1995 04:24:13 GMT
Lines: 82
Xref: glinda.oz.cs.cmu.edu comp.software-eng:37565 comp.lang.functional:6514 comp.lang.lisp:19342

Erik Naggum <erik@naggum.no> writes:
>[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.

It's only "unnecessary" if you didn't really want any help from the
type system in the first place (in which case, there are other
languages out there for you).  Those of us that *like* strong types
feel that the occasional need to satisfy the type system is a small
price to pay for the detection of a large class of errors.  Think of it
as a lifestyle choice - if you would like to get to work faster, you
might choose a motorcycle, rather than a car with seat belts.

A static type system is a subpart of a program specification which can
be checked at compile time.  If you're dashing off a small program,
such checks may be unnecessary and unwelcome; write it in LISP.  If
you're building a large one, they can be damned useful; write it in a
language that does (at least) some static type checking.  As a side
effect, you usually get some optimisations.

The challenge is to devise more flexible type systems that still manage
to hold the programmer's hand at compile time (rather than crashing and
burning at runtime), while remaining reasonably intuitive.  That's
hard, and, because some things are only semidecidable, there will always
be people for whom current "static type system technology" is too
restrictive to use.

These don't necessarily represent better or worse programmers - just
different styles.  There are also "soft" type systems, for dynamically
typed languages, which don't impose type constraints but will issue
warnings (when they can) and optimise code.

>further, as the number of types increases [...]
>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.

Gotta agree.  But this is the same as keeping track of the function
calls in a large dynamically typed system.  It's precisely when systems
become large that you'd *like* the compiler to check some of the more
obvious potential errors for you.

>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.

Strong type systems discourage mistakes!  And you're arguing *against* it? :)

Hmm.  There's Haskell (actually, Gofer in particular).  Pretty flexible
if you want it to be, but still reasonably safe.  And you don't have to
*use* the extra stuff if you're comfortable with a subset of the type
system.  Haskell/Gofer aren't the ultimate, of course (just reasonably
nifty and intuitive); they seem like a reasonable trade off.

For a better example of a powerful dynamic type system which allows
type constraints to be checked at compile time, there's Quest (Cardelli
et al; papers on the web, and well worth reading).  Quest is
essentially explicitly typed (you mention type parameters to functions
when necessary), which allows its type system to be very general, but
still checkable.  It supports parametric polymorphism, encapsulation,
overloading, record (and other) subsumption, etc; it also seems to
scale reasonably well between small, dashed off programs and very large
systems.

All of these languages are strongly typed, being based on similar styles
of typing technology, but go to different lengths to be flexible and/or
efficient.  Different people will choose different languages.  This is
how it should be.

Cheers,

    Mike.
--
Mike McGaughey			AARNET:	mmcg@molly.cs.monash.edu.au

"Thousands at his bidding speed,
 And post o'er land and ocean without rest" - Milton.
