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

[mheaney@ni.net (Matthew Heaney)]

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


In article <EG2Dv5.74D@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:


>In the entity-declaration case, we're talking about attaining
>a higher level of abstraction by separating the declaration of an
>entity from its implementation.  Does it really matter to the human
>if the implementation comes before or after the usage?

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

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.

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

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)  

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

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.

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