🚀 go-pugleaf

In article <OLSON.91Apr12012507@lear.juliet.ll.mit.edu>,
olson@lear.juliet.ll.mit.edu ( Steve Olson) writes:
|> [about something I wrote]
 
|> Thats ridiculous.  Your argument assumes a bad design.  No language
|> outlaws
|> stupidity.  Do you believe that Lisp programmers go around making up
|> lists
|> of completely random elements just to make things challanging?
|> 

The ability to do just this has been touted by others as one of the
advantages of dynamic typing. My point was that if they do not do this,
they could use static typing, as you yourself say.

|> Of course you can use a statically typed language.  The question is how much
|> programmer resources (usually more) vs. how much machine resources (usually
|> less) will the static solution consume?  The choice depends on the
|> application.
|> 

Again we agree -(see below)

|>[me]    Any problem solution can be programmed in a statically typed
language,
|>       if the programmer is prepared to *design* the program before
|> writing it.
|> 
|> Any problem solution can be programmed in a statically typed
|> language, period.
|> So?  Are you trying to imply that using a dynamically typed language
|> somehow
|> prevents one from designing?
|> 

It's a strange kind of logic that has my claim imply what you suggest.
There is, though a conection between the design effort I associated with
using static types and the "programmer resources (usually more)" that
you associate with static types.


|>  Many (most?) 
|> large complex programs written in statically typed languages have little
|> bits of roll-your-own dynamic typing in them.  This is a prime source of
|> "hackery".  Screw up one of those explicit type tags and there is no
|> end to the troubles you face.

This may well be true, but what does it show? A lack of design effort.

Let me make a statement - up to now I have just responded to other postings.
First, let me try to define what I mean (sorry if this is boring).
- A type is a set of operations.
- a value has type T if it understands all the operations of type T
- a type violation occurs when there is an attempt to apply to a value an
  operation which is not in its type.
- Languages can be classified as untyped, dynamic typed, static typed.
- Untyped means that it is solely the programmer's responsibility to
ensure that
  no type violation occurs. Failure to ensure this will not be detected
at
  compile time or by the system at run-time. Usually the code
implementing the
  operation is applied to the bit pattern representing the value as
though that
  pattern represented a value of the appropriate type for the operation,
with
  serious results. E.g. doing a floating point add to an integer value.
- Dynamic typed means that values/objects contain type information at
run-time,
  so can detect attempted type violations and respond. This is fine
unless the
  response is unanticipated.
- Static typed means that a type is associated at compile time with each
  variable. (In a functional language, which is what interests me, this
normally
  means with each defined function and by implication its formal
parameters.)
  It is possible at compile time to ensure that a value is never bound
to a
  variable of the wrong type, and that only type-valid operations are
performed
  on variables, thus preventing type violations.

You made a trade-off between development costs and run-time costs. Fine,
there is nothing wrong with that. I prefer to note the trade-off between
development cost and run-time unreliability. I.e. it's better, in an
important application, to take the extra time in development to protect
against run-time type violations. This is not a complete guarantee of
program correctness, but it is a step in the right direction.

If I had to accept liability for damages resulting from the failure of a
software system, which had to be developed from scratch, I would, other
things being equal, (programmer skills and experience, etc), insist on
the use of a static typed language. Since I moved from industry to
Academia, my own programming efforts carry no such burden of
responsibility, so I could freely use lisp or apl or smalltalk in my own
little world, but I believe my responsibility to students, most of whom
will become practitioners in industry, is to encourage them to use safe
practices, or "solid engineering principle". 

--brian
-- 
Internet: brian@comp.vuw.ac.nz
Postal: Brian Boutel, Computer Science Dept, Victoria University of Wellington,
        PO Box 600, Wellington, New Zealand
Phone: +64 4 721000   Fax: +64 4 712070