|[7 earlier articles]|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code firstname.lastname@example.org (1993-01-13)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code nickh@CS.CMU.EDU (1993-01-13)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code chased@rbbb.Eng.Sun.COM (1993-01-13)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code email@example.com (1993-01-14)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code firstname.lastname@example.org (1993-01-14)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code email@example.com (1993-01-14)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code firstname.lastname@example.org (1993-01-15)|
|Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code email@example.com (1993-01-16)|
|From:||firstname.lastname@example.org (Thomas M. Breuel)|
|Date:||Fri, 15 Jan 1993 19:50:14 GMT|
email@example.com (Dale R. Worley) writes:
... in Ada, once the program compiles, there are very
few bugs in it. Ada was designed with the intention of turning what would
be run-time bugs in C into compile-time bugs, and it appears that it has
succeeded to a large extent.
firstname.lastname@example.org (Robert Virding) writes:
OK, this takes care of the easy bugs. [...] I have found that the
more experienced a programmer becomes, generally and with a
specific language, then he/she makes fewer of the "easy" bugs.
The kinds of storage bugs, undefined behaviors, and implementation
dependencies that crop up in C programs with regularity can be very
Incidentally, I find that as I have become more experienced, I tend to
make such bugs less frequently per line of code, but not much less
frequently per unit time.
This is unfortunate as most compilers and support environments
concentrate on the "easy" bugs. If I have a large system with many
concurrent activities that stops after 3 weeks running then knowing
that the parameters to functions are of the right type will
probably not help me much.
I think it will help you a lot, for the following reason. C-style bugs
(bugs involving pointers, memory management, etc.) tend to be
intermittent. Often, they only occur under large loads, when the optimizer
gets used or changed, or when you move to a different architecture.
On the other hand, algorithmic bugs are more predictable. You understand
your algorithm, you know its special cases, its boundary conditions, and
its induction steps. You can (formally or informally) design a set of
test cases for it. If your language has no other source of variation or
errors, then that will give you confidence that if it runs for input of
size 10, it will also run for input of size 10^9 or on a different machine
(except, of course, for arithmetic exceptions and resource shortages, both
of which are signalled).
Now, you mention concurrency. Well, if you use currently popular notions
of concurrency introduces an element of undefined, implementation defined,
or random behavior. Type checking is obviously not going to help you
there, but choosing a safer, more predictable paradigm of concurrency
Using type checking is not a panacea, but it contributes to making
programming safer and easier.
Return to the
Search the comp.compilers archives again.