🚀 go-pugleaf

In article  <1991Mar13.163629.12630@engage.enet.dec.com> grier@marx.enet.dec.com writes:
]
]   In mathematics, it makes NO sense to talk about applying a function
]or operation to a symbol unless the symbol is known to be in the
]domain of the operation/function.  I.e. writing something like "for all
]x, exp(x) is greater than zero" is nonsense.

Nonsense.  Anybody with a clue immediately understands that x is
restricted to values in the domain of exp.

]...  In David Gudeman's example, I most
]certainly don't want some "read()" operation which can return ANY
]type of value to allow my code to blindly attempt to apply the "+" or
]"Log()" operator to it.

In the first place, the read() only produced ints and floats, and the
return value was used in a context where either was a legal value.  In
the second place, if the read() function were defined to return other
sorts of values and you wrote "x + read()" the problem would be in the
program, not in the definition of "read()".

]My code should have some reason to believe
]that "Log()" makes sense when applied to the value.  Statically checked,
]before allowing me or anyone else to run it.

Then you are going to need types "positive int" and "positive float".
Do you also want type security for division?  Then you are going to
need "non-0 int", "non-0 float", as well as "positive non-0 int", etc.
I count 8 numeric types needed just to get type security for two
common operations.  The point is that static type checking involves an
essentially arbitrary set of restrictions, and there is no evidence
that it adds to program security at all.

I will concede that optional type declarations might help program
security in the same way that optional assert clauses do.  (I don't
object to having type declarations in a language, I object to
_required_ type declarations.)  However, for many variables there is
no need to declare the type since it is obvious from the var's use,
and programmers should be smart enough to know the difference.
Whatever makes a language designer think --at language design time--
that he knows more about the requirements of a program than the
programmer will know --at program design time?

]... I just wouldn't do my banking or trust my life to software which
]relies on extensive testing rather than some level of ensurred correctness.

You must be joking.  Static type checking doesn't give any reasonable
level of assurance at all -- it is never the case that simply because
program compiles without errors, there is reason to believe that it
has some level of reliability.  Testing is the _only_ known way to
give any assurance at all.  And a given amount of testing generally
provides more assurance for a language with dynamic typing than it
would for a language with static typing.  (Because programs in
dynamically typed languages are usually much smaller and have fewer
paths to test.)

]   Heck, there's an even more direct parallel.  Syntax checking!  Next thing,
]why don't we have languages where they "try" to interpret commands and
]do what their best guess to the requested operations are!
]
]   I don't WANT a smart computer, I don't WANT a computer which can
]misinterpret ambiguous commands, I don't WANT a computer which
]can forget...

There is no parallel there at all.  Dynamically typed languages in no
sense try to interpret ambiguous commands or "guess" what is wanted.
The typing rules are just as unambiguous in a dynamically typed
language as in a statically typed language.  But in the dynamically
typed language the rules are simpler, more intuitive, and easier to
use.  (Depending on the language of course -- I wouldn't argue that
Smalltalk's rules are any of the above...)

]... and some program writes past the end of an array, blasting
]away the stack, crashing the ATC computer,)

You are confusing weak typing with dynamic typing.  I don't know of
any dynamically typed language that lets you write past the end of an
array (unless it first expands the array).

]   This is tiring.  If you don't agree with me, that's OK, but I hope you
]stay in the research world rather than producing software which people
]pay for and expect to work reliably.

I'm sure that the thousands of people currently using and relying on
software written in dynamically typed languages are touched by your
concern.  We aren't worried about it though, we'll just go on using
easily modifiable software that was written in half the time with
twice the functionality, with no loss of reliabilty.  (Although we
_do_ have to buy faster machines or put up with slower response.)
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman