Re: Software landmines (loops)

[smize@news.imagin.net (Samuel Mize)]

In article <35F06D6A.91A3D34E@s054.aone.net.au>,
Loryn Jenkins  <loryn@acm.org> wrote:
>> Humpty Dumpty had perfectly clear thoughts, but he didn't use the
>> agreed-to language, so his thoughts weren't clear to others.
>
>This is dubious at best. Although many linguists in the American
>Chomskyist school chould agree with you ...

OK, I'll restate my point without reference to the Classics.

If someone uses Tagalog or Mayan words as identifiers, he (or she, in
all cases) would understand his own code easily.  However, it would be
hard and error-prone for others from a typical project team to
understand it.

This is similar to someone who understands clearly what he intends the
code to do, but expresses it in a way that is not clear to a reader.

An appeal to clarity of thought won't shape up that person's code; his
thoughts are perfectly clear, just complex.

In fact, one could argue that some obscure code comes from too MUCH
clarity of thought.  When one is deeply immersed in the details of an
algorithm, its conditions and behavior are clear.  So, code can seem
clear to the writer, because it's easy to see what it's doing -- IF
you already know in detail what it's doing!

Another way to express that may be that the writer has "chunked"
together some of the complex concepts in the algorithm.  (I'm using
the term loosely.)  So from his point of view, he's expressing a few
simple ideas in the code.  But the reader, not having those "chunks"
already in mind, has to interpret the full complexity of the code.


>It is much more to the point that language is an instrument which 
>*construes reality*. It is quite inapropriate to claim that thoughts can
>be organised outside of the semiotic systems that construct it.

Well, I certainly can't argue with that!  I can't even follow it.
Let's see if my understanding is within a furlong of your intent.

I think the difference is that the coder typically constructs his
thoughts in one semiotic system: a combination of diagrams, native
language, and code fragments.  Then he expresses them in another:
compilable code.  The reader, to really understand the code, must then
rebuild something equivalent to the original construction before the
code makes as much sense to him as it did to the writer.

Using a constrained set of structures simplifies understanding the
code, but sometimes makes it harder to write it.  This is like to
using a limited, non-technical vocabulary when explaining things (like
linguistics).  Such a limited vocabulary would make it easier to
understand an explanation, but harder to write it.

But we're discussing structure.  Here's a better analogy.  The
previous paragraph was originally all one sentence that expressed that
complex idea.  I clearly understood what I wanted to say, but it took
me some time and effort to simplify my expression of it.

One heuristic that is often helpful in improving clarity of expression
is to break up a long, complex sequence into shorter, well-structured
components.  This is true in English and in code.

That's the central intuition of "structured programming," as I
understand the term, which is in a broad sense.  Single entry/exit,
end-exit loops, and other constraints, are specific approaches to
defining the structures to be used.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam