Re: language design tradeoffs

jlg@cochiti.lanl.gov (Jim Giles) writes:


>... The source for commercial C products I looked at had a total
>of 12 statements (not counting "compound statements", which are actually
>statement *blocks*) that actually crossed line boundaries out of over
>10,000 statements of code ...
  [...]
>people tend not to put line breaks within statements unless there's no
>choice - in which case, an explicit mark denoting that something unusual
>is afoot seems not amiss.


After reading the above comments I decided to look up some of our
production C code. I have found that between 5%-10% of our statements are
of the line crossing variety. This is probably due to long variable names
and indentation but I have a problem with the <0.12% value. If you have
variable references like
"Xmit_C1_msg.Master_Control_Word.master_mode_switch_setting" then it is
very easy to break across lines. Now you may argue that it is silly to
have such long names but if code readability is of importance than longer
names are better(up to a point).


>decide not to *require* such marks in your language. The programming
>language Turing requires neither type of marks. The price is less
>localizability of certain types of syntax error.


This may be true in theory but in practice Turing has a exceptionally good
error detection and reporting rate. I have had C programs where the error
is not even reported in the offending file.


I just throw this out as a general question/statement.


We found that when we were forced to stop developing software
in Euclid/Turing and moved to C our productivity dropped
dramatically.


Is there a study that correlates languages to types and frequency of
errors. If not I am sure that it would make for an interesting study. It
would seem to me that if equivalent programmers were given the same
problem to solve but different groups where forced to use different
languages. Then later correlate the number of errors/bugs/compilations to
the language features that they are relevant to. This may to a long way
in determining what are important language design tradeoffs
--
Alvin Starr || voice: (416)513-6717
Eyepoint Inc. || fax: (416)513-6718
alvin@eyepoint.com ||
--

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