Re: Interface/Implementation (was Re: Design by Contract)

[doylep@ecf.toronto.edu (Patrick Doyle)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5478 bytes --]


In article <mheaney-ya023680000609971901030001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In order to understand something, you have to know a few other things. 
>Because humans are complexity challanged (sp?; man, I've got to install my
>spell-checker...) , we want to limit the amount of information the human
>reader of the code has process in order to understand it.
>
>If he has to scan past a point in the text in order to figure something
>out, then there's a lot of stuff after that point, but prior to the point
>containing the next useful piece of information.  

Ok so far...

>But the reader doesn't
>know what's useful and what's not, in order to understand this particular
>problem, so he has to digest it all, and then prune away all the
>unnecessary stuff after he's figured out his problem.  

This isn't true.  If there's a reference to a class, for example,
he just has to scan the headers of class declarations, of which
there is only on per class.  Not really that much stuff to plough
through.

By contrast, in the loop situation, in general, the entire ramining
part of the loop must be understood to see that it does what's
expected.

Also, remember that on average, saving the programmer from scanning
below saves only 1/2 the work.  Not an order of magnitude, by any
means.  Perhaps you'll argue that 1/2 is important enough?  Well,
then I suggest you get a decent editor and save yourself *far*
more than 1/2 the work by having it look up the definitions for
you. 

>It seems that it
>would be simpler for that reader, if in order to understand something, he
>knows up front that all he needs to care about has already appeared.

Remember, to say it has "already" appeared is implying that there is
a time component to this, which in turn implies that the file is
read in a linear fashion.  

>That's why exit conditions from the middle of a loop make a lot of sense. 
>As soon as the exit condition appears, then the reader can turn his brain
>off, and scan past all the text prior to the end of the loop.  The precise
>intention of the language designers is that this would limit the amount of
>information the reader has to process in order to understand what he's
>reading.

I agree in this case, because in general then entire remaining portion
of the loop would have to be understood to ensure that it does what
is expected.  On the other hand, with forward references, I can't think
of any situation where all the code would matter.  You're just scanning
for the right declaration.

>Incidently, the article Cognitive Strategies and Looping Constructs
>(Soloway et al, CACM, Vol 26, No. 11, Nov 83, p. 853 - 860) described a
>study demonstrating that exits from the middle a loop were easier for
>programmers to understand and get right; they showed empirically that those
>constructs had fewer errors.   Exit-from-the-middle loops better fit the
>cognitive strategy used by real programmers: "When writing a simple looping
>program, those using the loop .. leave .. again construct were more often
>correct than were those using the standard Pascal loop constructs."

No argument here.

>I wish everyone would read this paper, so we could end this perennial
>debate.  "Programming is a human activity.  Forget that, and all is lost." 
>(paraphrased from Stroustrup)  

I didn't think that's what the debate was.

>>Consider this: the reason for this abstraction is that the human
>>reader need not be bothered with unnecessary details.  If these
>>details are unnecessary, who cares where they go?  And if they
>>*are* necessary, then a human reader searching a single text file
>>with any reasonable editor should have no trouble finding it.
>
>But the reader of a piece of code doesn't know what's necessary and what's
>unnecessary when trying to figure something out.  By enforcing dependency
>order, you know up front that what comes before is necessary, and you only
>need to keep reading until you figure your problem out; everything after
>that point is unnecessary.

Yes he does know what's necessary.  Remember, he's the guy trying to
understand something.  If he looks at something and understands it
because good abstraction was used, then he doesn't need the definition.
If he doesn't understand it, he needs to look it up.  If he thinks
he understands it and he's wrong, then the code is misleading,
and badly written code will always present problems.

But also remember this: just because a language doesn't enforce
dependency ordering doesn't mean you can't use it.  So if you have
a thing used in a way that might be misleading, you can put its
definition above its usage and get all the benefits you describe.

The advantage to not enforcing dependency ordering is that it
allows the programmer to choose a meaningful ordering, and also
that the compiler doesn't choke on technicalities when you have
forward references.

>The Eiffel camp seems to think that dependency order is a limitation, but
>it was a deliberate decision by Ada's designers.   As an Ada programmer, I
>haven't found it to be a limitation at all; in fact, I find it quite
>helpful, exactly as the designers imagined it would be.

Perhaps it is helpful, but it is also a limitation.  Perhaps a
helpful limitation, but a limitation nonetheless.  

>To get random signatures put text files into a folder called �Random
>Signatures� into your Preferences folder.

What's this all about?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca