Re: Is strong typing worth the cost?

["Robert I. Eachus" <rieachus@attbi.com>]

Brian Rogoff wrote:


> Another related question I'd like language designers to think about is the
> relationship between verbosity and readability. It's often insinuated in
> the Ada community that verbosity and readability are directly proportional,
> but I don't believe that's true. If we look at the history of mathematics,
> there was a period of time when mathematicians wrote mathematics like
> prose, and it was a big advance to get more succint notations. Just making
> it like prose does not enhance readability, especially when the underlying
> ideas are just inherently difficult, as with mathematics.


I think you may have gotten a wrong impression here.  I think that 
outside of software with very tough performance requirements, anyone 
here would favor adding one line of code if it replaced the necessity 
for three lines of comments.  In practice that trade-off almost always 
occurs in declarative parts where additional Ada source is unlikely to 
result in code size expansion or performance penalties.

Having said that, if I am given the choice between two ways to implement 
a function or package in Ada, one that is more complex and requires much 
more source code, which am I going to choose?  Right.  So the natural 
evolution of Ada code during the creation process is toward smaller more 
easily understood modules with fewer comments explaining obscure or 
difficult to understand sections.

My personal criteria are that comments that explain what a package, 
module, or section of code does are fine.  Comments on why something is 
done one way instead of another are also a good idea.  For example, in 
an implementation of the Miller-Rabin algorithm I just wrote:

  -- We now need to pick off all the bits of Reduced in reverse order.
  -- It shouldn't matter how we express this, but just in case avoid two
  -- obvious divide routines.
        loop
          Temp := Temp_Reduced/2;
          if Temp + Temp /= Temp_Reduced
            ...
          Temp_Reduced := Temp;

The first comment is definitely what, and the second explains why I 
chose not to use (Temp_Reduced mod 2) /= 0 to test the low-order bit. 
This is inside a generic, with the intent that Temp_Reduced could be a 
non-standard integer type, and the compiler might not be able to do the 
test for oddness efficiently.  Oh, and the parantheses around 
Temp_Reduced mod 2 above are another example of helping the reader.  I 
know the parentheses are unnecessary, but they make reading easier.

Comments that explain how code works are a clue that I shouldn't write 
the code that way, but in a way that is more self-explanatory.  Comments 
that explain what a variable is used for indicate that the variable is 
poorly named, and so on.

So I guess what I am saying is that the "Ada style" is to move comments 
into compilable source code whenever possible.