Debuggers

[Ed Prochak]

Hi Mr Tirkin

First, thanks for your contribution. It was a very interesting read.

[snip]

Now, question for the people that keep a small part of common
sense here:
Is *reading* a program the *same* as *DEBUGGING* a program?

If you mean by "reading," "reading with understanding," then I'd
guess I'd have to answer "yes" to this. When I read code and can't
understand why something is done or why something is done the way it
is, I've oftern found a problematic section of code which contains
bugs. I basically execute the code mentally as I read it. If you
mean to ask whether you can debug a program just by reading the
source code, the answer is also (obviously) yes. I have often found
that an algorithm was incorrectly implemented, just by looking at the
source code of the implementation.

This is of course possible, I will never deny this. But, as you read
lines and lines of code, your attention suffers, and you *think* you
understand what the code is doing but you actually don't because you
failed to see that

if (smp < smpGoal)

should have been

if (smp <= smpGoal)

and you are doomed.

Yes, you are doomed, but NOT for the reasons you give of brain limits.
You seem to think that on reading the wrong code, the reader mistakes
it for correct because of the volume of details around it. That may
sometimes be the case, but it is not the real source of the problem.

I have a saying I often repeat that describes the real cause of many
problems like this:
Self documenting code isn't.

On reading a large program there may be hints in the code that one or
the other of those two IF statements is the correct one. But the only
way to be sure is to have the requirements documented. Source code
cannot be self documenting. Source code can, by definition, only tell
you what it DOES, not what it is SUPPOSED to do. This is a stumbling
block for many, keeping them at skill levels of programmers versus
advancing to skills of software engineers. (This discussion might be
more rightly placed in comp.programming or comp.software-eng).

Maybe getting into a bit of psychology, we observe that the brain, with
ALL its power, can't do things that a lowly computer can easily do.

That is why BRAINS make computers in the first place!!!

Because they can do things that brains can't. And one of them is that
they have the capacity of doing things, and repeating them "ad nauseum"
without ever getting fed up with it.

You are attributing emotions to computers

Brains can't do that. They just CAN'T.

But brains with paper and pencil and time can. You place limits that
do not really exist.

... It is not a matter of will, it
is a fact of the circuit (the brain's circuit). It gets tired easily
with repetitive tasks and just shuts down. This is a reflex that is
common to all circuits based on neural networks: they learn to ignore
repetitive things and concentrate into CHANGE.

You THINK you understand the code, but after 867 lines you MISS the
deadly detail that will kill you later on.

Specially if there is a lot of repetition and not much redundancy.

Maybe on a casual reading of the code. If we are looking for a bug, a
difference issue comes into play which is: we see what we expect to
see. That is a problem. It is not the code repetition per se.

But knowing why something is written is a better way of finding the
bug than just reading source code in isolation.

C is not designed to be read by normal people.

I already know I'm not normal. 8^)

..... You *can* read it of
course if you are a programmer, but it is missing all the normal
parts of language that makes a human language easier to read and
understand. C must be understood by the programmer of course ( at
least the one that writes it for the first time ) but it ALSO has
to be understood by the machine. This makes C repetitive, and hard
to swallow in big quantities.

That's why modularization was invented and included in C.

Let's not make a fool of ourselves. I *know* that you can read a
lot of code, and I *do* read a lot of code. But I know that I can
pass 20 times over

strcmp(foo, "foo");

without noticing that it was Foo and not foo what should have been
written there.

The best proof of what I am saying is that (as you know) BUGS
exist. And they exist BECAUSE only BRAINS make mistakes and
introduce errors when building software.
okay.

What I am trying to point out is that automatic tools for following
the code when it is running are a VERY useful tool for understanding
foreign code.

This conclusion does not follow from your remarks in this post. Manual
tools (e.g. paper and pencil) may be effective as well. Sometimes just
another pair of eyes can see the bug. So your post did not make the
case for automated tools.

In fact you fall into the trap: if we cannot write bug free programs
without automated tools, then how do we write the programs to
implement those automated tools?

Obviously you have to know how to read C, if not, even the best
debugger is useless. But I would NOT rely so much in the capacity
of the brain. It is just not *done* for that kind of task.

It can be a matter of training. (experience is a kind of training).

And after writing that, I take it away of course. There are
people that can compute the 12th root of a 25 digit number in
a few minutes or sometime less. I heard in the radio last month of a
championship being held somewhere, where all those people did
*amazing* feats.

Don't give in so easily. Did they find your bug? (Foo vs foo?)

[]

And I know that if I have to, I can do without any debugger, because
I know the code I am working with, its failure modes, what I have
changed lately, etc. But I know that if I have a debugger
it is better (and MUCH faster) to use it.

Tools are made to be used. The issue seems to be, by analogy, whether
a hand saw is better than a power saw.

I stick to my limit, and I find a confirmation of this in your sentence:


That's the point I am making. 1500-2000 lines is the maximum
the brain can handle.

So then keep you code size below that limit and you will not need the
debugger.
for the saw analogy, stay with smaller dimension boards (half inch
plywood versus 6x6 pine) and a hand saw is just fine. But you still
will need blueprints to get the job done right.

But your post is so interesting (at least for me) in that you bring
many good ideas about why modularity is necessary, and how to structure
the code to preventively avoid bugs. It is a very welcome contribution
in a discussion (and it is my fault too) that we should have in a
much more *relaxed* manner. I agree that I make to much polemic
sometimes.

Excuse me.

Yes, David, thanks for the post.
Ed

 

[Richard]

But brains with paper and pencil and time can. You place limits that
do not really exist.

And you seem not to recognise that time is an important commodity and
can indeed be limited in the real world.

I can beat you 999 times out of a thousand in spotting a bug using a
debugger than you can with a pencil and paper on a foreign code base.

 

[jacob navia]

Ed Prochak wrote:

[snip]

I have a saying I often repeat that describes the real cause of many
problems like this:
Self documenting code isn't.

On reading a large program there may be hints in the code that one or
the other of those two IF statements is the correct one. But the only
way to be sure is to have the requirements documented. Source code
cannot be self documenting. Source code can, by definition, only tell
you what it DOES, not what it is SUPPOSED to do.

In a perfect world you are right of course. In a real world you are
completely wrong. Most of the cases I find is that there was a small
word document somewhere when the project started, but nobody took
the time and management didn't give a damm since keeping the
requirements documents current takes resources that are wasted,
since they could be used for doing project z progress a bit faster.

This means that when I am called as the last resort nobody has any
idea why the code doesn't work since the guy that wrote it was
fired after the project was done.

And then, you have only the actual code. Nothing else. That's when
a debugger is very useful...

This is a stumbling
block for many, keeping them at skill levels of programmers versus
advancing to skills of software engineers.

This is completely false. Most of the programmers would love to
spend time doing the documents and keeping them current. Most managers
do not give a dam about this and just focus in the best way to
finish the project in time no matter what.

> (This discussion might be
more rightly placed in comp.programming or comp.software-eng).

You are attributing emotions to computers

No, precisely. Reread. I am saying precisely that computers have NO
emotions at all and can do repetitive tasks over and over again.

But brains with paper and pencil and time can. You place limits that
do not really exist.

Brains can't do huge computations, and there are strict limits in
pencil and paper methods.

If you have to add 5 000 numbers and you have a failure rate of
only 1 in a thousand (what would be staggering low) you have a
sure chance that your sum is wrong!

Reading code (I repeat) is good, but you have to be conscious
of the LIMITS of that method.

I already know I'm not normal. 8^)

You are changing the contents of my sentence. I said that C is not
designed for normal people but for C programmers, i.e. you have to
know programming to be able to read C.

Try this. Pass a C program to your grandmother.

In fact you fall into the trap: if we cannot write bug free programs
without automated tools, then how do we write the programs to
implement those automated tools?

This is called bootstrapping. You make smaller tools for building bigger
ones. The same with printed circuits and the modern processors of
today.

No modern processor can be designed by people, it is just too complex.
The time when you did all circuit design by hand is long gone. Now, you
use automated tools for this, VLSI compilers, etc etc.

 

[CBFalconer]

Chris Dollin wrote:

[It found them without having to execute the program, and without
manual intervention too. /That's/ what I imagine replacing
debuggers with -- tools that spot problems in advance, using some
kind of abstract interpretation, powerful type systems, and test
cases / examples. I imagine Jacob would label such a thing "a
debugger", and he might have a case for that.]

I would call them Pascal or Ada.

Neither Pascal nor Ada has a type system I'd call "powerful".

At least an order of magnitude more powerful than C. Every
integral object can have strict limits. Those limits can be used
in computing the need for run-time checking. Pointers are
segregated from array accesses. And so forth. There is no such
thing as a perfect type system.

 

[Morris Dovey]

I have a saying I often repeat that describes the real cause of many
problems like this:
Self documenting code isn't.

Hmm. I think code _can_ be reasonably self-documenting when the
choice is made to make it so.

I just grabbed the main() module for a stock market trading
engine that I wrote some time ago and dumped it out on my web
site. I'm willing to bet that relatively few people here are
intimately familiar with this particular application, but I'm
willing to gamble that if I provide a bit of application-specific
vocabulary, almost no one will have difficulty making sense of
what I coded and commented strictly for my own benefit...

An /offer/ is a proposal to trade.

A /bid/ is an offer to buy, and an /ask/ is an offer to sell.

A /market/ offer is an offer to buy or sell at the going price.

A /limit/ offer is an offer to buy at some maximum price, or to
sell at some minimum price.

A /trade/ is what happens when the price is right.

A /symbol/ identifies what's to be sold.

/The Book/ is the collection of all outstanding offers.

The vocabulary is larger than the code, which can be found at the
link below.

 

[CBFalconer]

Ed Prochak wrote:
.... snip ...

If you have to add 5 000 numbers and you have a failure rate of
only 1 in a thousand (what would be staggering low) you have a
sure chance that your sum is wrong!

Reading code (I repeat) is good, but you have to be conscious
of the LIMITS of that method.


You are changing the contents of my sentence. I said that C is not
designed for normal people but for C programmers, i.e. you have to
know programming to be able to read C.

Try this. Pass a C program to your grandmother.

Very good. This posting never got off into denigrating the
previous author, and stayed pretty well on subject. If you
continue like this you will become a respected poster here.

 

[Flash Gordon]

jacob navia wrote, On 14/03/08 18:06:

Ed Prochak wrote:

[snip]

I have a saying I often repeat that describes the real cause of many
problems like this:
Self documenting code isn't.

On reading a large program there may be hints in the code that one or
the other of those two IF statements is the correct one. But the only
way to be sure is to have the requirements documented. Source code
cannot be self documenting. Source code can, by definition, only tell
you what it DOES, not what it is SUPPOSED to do.

In a perfect world you are right of course. In a real world you are
completely wrong. Most of the cases I find is that there was a small
word document somewhere when the project started, but nobody took
the time and management didn't give a damm since keeping the
requirements documents current takes resources that are wasted,
since they could be used for doing project z progress a bit faster.

You've obviously never worked in a company doing work for the defence
industry, or I suspect for the automotive industry, or for any other
industry where there are real checks in place.

This means that when I am called as the last resort nobody has any
idea why the code doesn't work since the guy that wrote it was
fired after the project was done.

And then, you have only the actual code. Nothing else. That's when
a debugger is very useful...

Well, if your only experience is of badly run projects and companies
that follow bad practice that would get them sued in some industries and
prosecuted in others (in safety critical projects the management and
engineers can, in the UK, be taken to court individually as ell as the
company getting done) it is not surprising your opinions are different
from people who have worked in companies that develop SW properly.

This is completely false. Most of the programmers would love to
spend time doing the documents and keeping them current. Most managers
do not give a dam about this and just focus in the best way to
finish the project in time no matter what.

Definitely not worked on significant projects in the defence industry.
When I worked in it your code would be reviewed against the
documentation, and if it did not match you would not be permitted to
release it until either the code or the documentation were fixed so that
they did agree. You also get the customer auditing projects to ensure
that you are following the processes. If a bug gets in to the code base
(whatever you mean by that, since your definition seems to be different
to mine) and passed testing without being found (and some bugs
inevitably do) then where I worked in the defence industry you would not
be permitted to put the fix in for formal testing (which is a
requirement before release) until you had raised the change requests on
the documentation, and the QA team would challenge you if you did not
update the testing so that it proved the bug was not there.

Other industries are less strict (including the one I'm in) but your
absolute claims about documentation are clearly wrong.

No, precisely. Reread. I am saying precisely that computers have NO
emotions at all and can do repetitive tasks over and over again.


Brains can't do huge computations, and there are strict limits in
pencil and paper methods.

There are also advantages to pencil and printout. Such as the ease with
which you can sketch diagrams of what is going on.

If you have to add 5 000 numbers and you have a failure rate of
only 1 in a thousand (what would be staggering low) you have a
sure chance that your sum is wrong!

Reading code (I repeat) is good, but you have to be conscious
of the LIMITS of that method.

As with using a debugger, you focus your attention on the areas of the
code where the bug is likely to be. You don't read every line of a 50000
line program to find one bug just as you don't step through all 50000 lines.

You are changing the contents of my sentence. I said that C is not
designed for normal people but for C programmers, i.e. you have to
know programming to be able to read C.

Try this. Pass a C program to your grandmother.

Try giving your grandmother a debugger and a C program and you will get
the same effect.

This is called bootstrapping. You make smaller tools for building bigger
ones. The same with printed circuits and the modern processors of
today.

No modern processor can be designed by people, it is just too complex.
The time when you did all circuit design by hand is long gone. Now, you
use automated tools for this, VLSI compilers, etc etc.

Just as you don't single step through the library code you don't read it
unless there is reason to suspect that is where the bug is.

I use debuggers for finding some bugs but I always start by reading the
relevant parts of the code because stepping through it won't tell me
much if I don't understand it. Some of the time reading the code is
sufficient. Some of the time using the debugger does not help and I have
to go back to reading the code, analysing it and even going back to the
requirements. Some times the debugger does help.

I'm only arguing against your absolute statements that it cannot be done
because not only can it be done but it has been done and still is done.
Some times analysis is the only way to debug a problem because attaching
a debugger or a logic analyser or even an oscilloscope is enough to
upset critical timings and hide the bug.

 

[Chris Torek]

Nowadays I'd write test cases for [robustness testing]. Tweaking in
the debugger doesn't leave a reusable trail. (I could be wrong about
that -- does it?)

It depends on the debugger. In particular, some rather nice Lisp
system debuggers keep huge amounts of history. I have not used a
C source-level debugger that has anything close to this sort of
capability, though.

(I prefer test cases myself, particularly ones that can be automated
and run as nightly tests. Some bugs do not lend themselves to
automated test cases, though.)

 

[Antoninus Twink]

Very good. This posting never got off into denigrating the
previous author, and stayed pretty well on subject. If you
continue like this you will become a respected poster here.

Very bad. This patronizing posting couldn't resist denigrating Jacob,
and has nothing to do with the subject. If you continue like this you
will never earn any respect here.

And fix your fricking signature.

 

[Ian Collins]

If the test case exists. They often dont.

As usual you haven't read the thread, note the little phrase in Chris'
post "write test cases".

 

[c gordon liddy]

If the test case exists. They often dont.


A test case equivalent was hardly ever done by stepping though in a
debugger. Unit testing or module testing was done in other ways.

I can't reliably rebuild the conversation here, but wanted to mention that
ruby seems to be good for the purpose of testing. I put some time in on a
test suite for a common C extension that used ruby to do all the the things
that aren't native to the syntax. I later found where most of the ruby
script was from. I don't have a hyperlink, but the filename is
MetaprogrammingIntroduction_0.4.zip .

But as usual, the criteria are being changed once more to suit the
"debuggers are not unnecessary" band.

I think a person uses a debugger to find all the bugs *he* can. I kill an
average of two cockoaches a day here on the Rio Grande, and the topic
grosses me out prima facie. They would scurry under my feet to my machine's
tower, that with its rubber soles, has perfect bug clearance.

I put my tower on my desk and flooded the perimeter of my house to twenty
feet: I'm bringing the war to them now.

 

[Chris Dollin]

It depends on the debugger. In particular, some rather nice Lisp
system debuggers keep huge amounts of history.

Oh, well, Lisp, I'd /expect/ a serious Lisp system to let me do
pretty much anything at any time -- after all, the evaluator/compiler
is only a () away ...

(I'd like some (em syntax) myself, being unfortunately wedded to
visual incluing, but I've managed without before and could do
so again.)

 

[Chris Dollin]

Chris Dollin wrote:

[It found them without having to execute the program, and without
manual intervention too. /That's/ what I imagine replacing
debuggers with -- tools that spot problems in advance, using some
kind of abstract interpretation, powerful type systems, and test
cases / examples. I imagine Jacob would label such a thing "a
debugger", and he might have a case for that.]

I would call them Pascal or Ada.

Neither Pascal nor Ada has a type system I'd call "powerful".

At least an order of magnitude more powerful than C.

I'm thinking more at the level of ML or Haskell, or better; I'm not
up with the state-of-the-art so I can't quote better.

There is no such thing as a perfect type system.

I'm not claiming otherwise. Did you really think I was?

--
"It took a very long time, much longer than the most /Sector General/
generous estimates."

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 

[Ed Prochak]

Ed Prochak wrote:

[snip]

I have a saying I often repeat that describes the real cause of many
problems like this:
Self documenting code isn't.

On reading a large program there may be hints in the code that one or
the other of those two IF statements is the correct one. But the only
way to be sure is to have the requirements documented. Source code
cannot be self documenting. Source code can, by definition, only tell
you what it DOES, not what it is SUPPOSED to do.

In a perfect world you are right of course. In a real world you are
completely wrong. Most of the cases I find is that there was a small
word document somewhere when the project started, but nobody took
the time and management didn't give a damm since keeping the
requirements documents current takes resources that are wasted,
since they could be used for doing project z progress a bit faster.

yes management does have a bad habit often of thinking documentation
does not increase value. I think you agree that this habit is
misguided.

This means that when I am called as the last resort nobody has any
idea why the code doesn't work since the guy that wrote it was
fired after the project was done.

And then, you have only the actual code. Nothing else. That's when
a debugger is very useful...

This is where you are wrong. If you have only the code, then there are
no bugs.
Let me be clear: a BUG is when program results differ from expected
results.

You have users that are dynamically defining the expected results.
They may be only verbalized, not documented, but the expectation is
what makes a bug. And in situations like this, the expectations can
change over time because they are not documented.

This is completely false. Most of the programmers would love to
spend time doing the documents and keeping them current. Most managers
do not give a dam about this and just focus in the best way to
finish the project in time no matter what.

If most did want to document their programs, they could do it in the
comments. Fact is most programmers are not good writers of
documentation. Just ask yourself how many times you saw code with
inline comments equivalent to this:
xcount++; /* increment the X count */

No, precisely. Reread. I am saying precisely that computers have NO
emotions at all and can do repetitive tasks over and over again.



Brains can't do huge computations, and there are strict limits in
pencil and paper methods.

only in the speed at which they can be done. But there are ways to
compensate if necessary. All the calculations needed to produce the
first atomic bomb were done on paper and pencil (well maybe mechanical
adding machines too but that does not reduce the point). The fact is
humans have been doing many large calculations long before electronic
computers were invented. It is only a matter of scale.

If you have to add 5 000 numbers and you have a failure rate of
only 1 in a thousand (what would be staggering low) you have a
sure chance that your sum is wrong!

You need to learn some statistics.

Reading code (I repeat) is good, but you have to be conscious
of the LIMITS of that method.

Yes. I was just pointing out there are limits other than what you
considered.

You are changing the contents of my sentence. I said that C is not
designed for normal people but for C programmers, i.e. you have to
know programming to be able to read C.

Try this. Pass a C program to your grandmother.

Geez, can't you read a smiley face? You are way too serious about
this.
And maybe I changed the context of your sentence,
but I did not change its contents since I copied it verbatim.

This is called bootstrapping. You make smaller tools for building bigger
ones. The same with printed circuits and the modern processors of
today.

You cannot have it both ways. If we can build the tools without bugs,
then why not use that method to build the applications? Development is
much more complex than you seem to think.

No modern processor can be designed by people, it is just too complex.

Oh, so modern processors are designed by those aliens at Roswell after
all!

The time when you did all circuit design by hand is long gone. Now, you
use automated tools for this, VLSI compilers, etc etc.

Tools used by humans. All they are is a lever. To get back to the
topic, debuggers can help. They should be one tool in your tool belt.
There are times to use a debugger, times to use source code (e.g.
static analysis by reading the code), and times to go outside the code
and tools (e.g. asking the users). Any over emphasis on any one
approach is crippled.

Don't become overly dependent on debuggers. It can still do no more
than tell you what the program does.

Ed

 

[Ed Prochak]

And you seem not to recognise that time is an important commodity and
can indeed be limited in the real world.

He stated an absolute that does not exist. he did not say brains
cannot do it within a time limit.
I am well experienced with the time, cost, functionality trade off.

I can beat you 999 times out of a thousand in spotting a bug using a
debugger than you can with a pencil and paper on a foreign code base.

So I'll check for your real name in the guiness book of world records.
You must be the worlds fastest developer on bug fixes.

Ed

 

[Ed Prochak]

Hmm. I think code _can_ be reasonably self-documenting when the
choice is made to make it so.

I just grabbed the main() module for a stock market trading
engine that I wrote some time ago and dumped it out on my web
site. I'm willing to bet that relatively few people here are
intimately familiar with this particular application, but I'm
willing to gamble that if I provide a bit of application-specific
vocabulary, almost no one will have difficulty making sense of
what I coded and commented strictly for my own benefit...

An /offer/ is a proposal to trade.

A /bid/ is an offer to buy, and an /ask/ is an offer to sell.

A /market/ offer is an offer to buy or sell at the going price.

A /limit/ offer is an offer to buy at some maximum price, or to
sell at some minimum price.

A /trade/ is what happens when the price is right.

A /symbol/ identifies what's to be sold.

/The Book/ is the collection of all outstanding offers.

The vocabulary is larger than the code, which can be found at the
link below.

In your program, the market to market trade happens before limit
trades. There is nothing in your program that shows this is correct
behavior. They program is self documenting only to the extent that it
describes what it does, but it does not (and cannot in code alone)
document WHY it does what it does.

So I continue to stand by my assertion: code cannot be self
documenting, because it cannot describe the requirements.


Nice program though.
Ed

 

[David Tiktin]

Hi Mr Tirkin

First, thanks for your contribution. It was a very interesting
read.

And thank you for your "cool" response ;-)

Just a few more remarks on the points you made.

[snip]

You THINK you understand the code, but after 867 lines you MISS
the deadly detail that will kill you later on.

Again, I wouldn't even try to understand 867 lines of code at once.
One function's worth is about what I can manage at one time, maybe
100 SLOC, tops. But once I've understood that, I can give those 100
lines a meaningful name so that they become, in effect, 1 line of
code. Keep compressing in this way and you can end up, at the top
level, understanding fairly large pieces of software.

[snip]

C is not designed to be read by normal people. You *can* read it
of course if you are a programmer, but it is missing all the
normal parts of language that makes a human language easier to
read and understand. C must be understood by the programmer of
course ( at least the one that writes it for the first time ) but
it ALSO has to be understood by the machine. This makes C
repetitive, and hard to swallow in big quantities.

Let's not make a fool of ourselves. I *know* that you can read a
lot of code, and I *do* read a lot of code. But I know that I can
pass 20 times over

strcmp(foo, "foo");

without noticing that it was Foo and not foo what should have been
written there.

I grant you C was not designed to be read by "normal" people. But
that just means we have to do our best to use it in a way that is.
For instance, in my code Foo could never be the name of a variable
since it starts with a capital F. It could only be the name of an
opaque type. That's part of the purpose of coding conventions. To
make code look a certain way when it's right. (A good syntax
highlighting code editor really helps too ;-)

[snip good points about human limitations]

In the last few days I've come across 2 interesting articles on the
web which bear on this topic of debugging software. If you have the
time, you might find them interesting:

http://realm3.com/articles/know_thy_code

and, for an entertaining story about debugging a complex foreign system:

http://smuglispweeny.blogspot.com/2008/03/tiltons-law-solve-first-problem.html

Dave

 

[Morris Dovey]

No modern processor can be designed by people, it is just too complex.
The time when you did all circuit design by hand is long gone. Now, you
use automated tools for this, VLSI compilers, etc etc.

Too far. Every modern processor /is/ designed by people. There is
no other source of vision. The automated tools only come into
play to /implement/ the design produced by a human (or a group of
humans) and to place the circuitry onto the available real
estate.

 

[Morris Dovey]

In your program, the market to market trade happens before limit
trades. There is nothing in your program that shows this is correct
behavior. They program is self documenting only to the extent that it
describes what it does, but it does not (and cannot in code alone)
document WHY it does what it does.

So I continue to stand by my assertion: code cannot be self
documenting, because it cannot describe the requirements.

Nice program though.

Thanks - your feedback, by the way, may be even better than you
guess. The fundamental premise of the engine (which
differentiates it from existing exchange mechanisms) is "just
trade or no trade", and the point you raise is sufficiently
related that I think I'll add that essential rule to the top of
every module's prolog.

You at least strengthen your position _and_ make a first class
case for the value of peer review.

 

[Morris Dovey]

I've been thinking about what you've said. The complete rationale
for this system is a fairly sizable document that deals at least
as much with philosophical as technical requirements.

I've decided that it may be a worthwhile exercise to include as
much of the rationale and technical requirements as seem
appropriate in each function's prolog. Just for grins, I updated
the source file on the server in case you might be interested in
seeing how your contribution is being taken seriously.

You at least strengthen your position _and_ make a first class
case for the value of peer review.

I probably understated. Thanks again.