Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code

drw@euclid.mit.edu (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.


rv@erix.ericsson.se (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
"hard".


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


Using type checking is not a panacea, but it contributes to making
programming safer and easier.


Thomas.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.