🚀 go-pugleaf

In article  <1991Mar15.062756.3781@engage.enet.dec.com> grier@marx.enet.dec.com writes:
]
]   I believe that Ada's model here is correct.  No correct program may
]depend on exceptions for its operation.  (Implying that if you have
]a correct program, you can turn off all the nice bounds-testing and
]such and end up with a nice and *fast* program.  Commercial Ada
]compilers from both Rational and Digital do this.)

Good grief.  You don't think dynamic typing is safe enough but you are
willing to turn off bounds checking?  That is going to make your
programs a _lot_ more dangerous than any program in a dynamically
typed language.

]...  Loose induction and
]random sampling don't make for proofs.

No, in the realm of software they give you much better reliability
than proofs.  I didn't want to get into another topic, but this just
too much.  Vendor A offers a product that has never been tested but
that has an computer-verified proof of correctness.  Vendor B offers
an identical product that has never been proved correct but that has
been through the normal testing process.  Which one do you want?  Any
sane person would pick the product from vendor B.

Incidentally, there is no reason why you can't have computer verified
proofs of correctness combined with dynamic typing.  Of course, just
as for statically typed languages, it wouldn't be worth the effort to
write the proofs for any but a tiny number of programs.

]   Once again, this is a problem I see in large systems evolving over time.
]My motivation isn't so much to prove correctness as to ensure that changes
]and growth don't invalidate other algorithms' implementations.  My
]extending "Read()" to return baby names in addition to numbers broke
]David Gudeman's program which assumes they're numbers, unfortunately.

If you change read() in such a way as to invalidate its original
documentation then you should have gone through all code that uses the
fuction and made sure they were still correct.  If you didn't do so,
then you did something stupid, and there has never yet been a
programming language made that can prevent bugs due to stupidity.  And
after you changed the function you should have tested the system
again, and that should have found the problem.  And if you didn't find
the problem that way (then your testing was slipshod, but also...),
then the worst that could happen during the actual use of the software
is for the system to detect the error and report it, failing to do
what was expected -- a minor problem for the vast majority of
applications.  A lot worse can happen if you turn off array bounds
checking, and nobody seems overly concerned about that.

]   I want the system to be able to recognize these problems and prevent
]them from being made into a running system.

Yeah, I want the system to recognize all my errors at compile time.
I'm just not willing to give up all the expressiveness I'd have to
give up to make that possible.

](a) we don't do static
]checking because we don't want those blasted type error or syntax
]error messages anyways, (b) there are cases where it is impossible
]for the compiler to statically type-check the program.
]
]   In the (a) case, well, damn the torpedoes, full speed ahead, and I'll
]just make sure I don't fly your airline or do banking with your bank.

The banking example is a non-problem.  I don't believe its possible to
get an accounting error due to lack of static type checking.  If you
get a type error the worst that can happen is for the program to
abort.  As to the airplanes, a program abort might be a little more
inconvient, but the program should be written in such a way that it is
protected from that even if type errors occur.

]   In the (b) case now either you've lost type-safety (which I claim is
]good and worthy of our respect,) or you have to start inserting clues
]about types of expressions back into your program.  Oh, but wait,
]that's sooo difficult, we can't do that.  We'll just let it run... (tick,
]tick, tick...)

Dynamically typed languages are type-safe.  And how many times do I
have to say that it isn't simply the writing of declarations that I
object to?

]There is no doubt in
]my mind that in the environments where the ability to specify the
]types of values which can be associated with a given name in a given
]scope, the quality of software was higher and the debugging cycle
]was shorter than in an environment which had a looser typing scheme

So who is arguing that?  It isn't the _abilty_ to specify types that
is the problem, it is the _requirement_ of specifying types.  A
requirement that leads to either (1) weak typing -- I think you will
agree that that is a problem, or (2) the further requirement of
excessively detailed declarations and excessive interdependency of
modules -- which I claim are more problems.  With optional type
declarations and the ability of the language to insert runtime type
checks you get better reliability.

]and where I spent a few too many late nights tracking down where
]what was eventually an obvious typing error occurred.

There are a few dynamically typed languages with inadequate error
messages or debugging facilities.  That is a problem with the
language (or implementation), not the concept of dynamic typing.

]   If you can remember all those details so that when modules
]evolve you can feel quite certain that interfaces won't be broken,
]I congratulate you.  It's just too bad that you're using an environment
]where your skill and expertise are wasted debugging rather than
]designing and implementing.

I spend a lot more time debugging when I program in C than when I
program in dynamically typed languages.

]   (I really don't understand the motivation.  Is there some amazing
]wonderful power that you get out of dynamic typing?
]  I don't see the costs of static typing being high, and the
]benefits are numerous.

That's because you you don't see the costs at all.  You are so used to
it that you think the problems caused by static typing are fundamental
to programming, and don't see the true cause.

]  I'm trying to see where this claimed
]productivity and quality gain came from.  Please enlighten me!)

Mostly the fact that you have to write a lot less code to get the same
functionality.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman