browse lookup phenomenon - SOLVED!!!!!

[Brian K. White]

----- Original Message ----- 
From: "Kenneth Brody" <kenbrody at bestweb.net>
To: "Dennis Malen" <dmalen at malen.com>
Cc: "FilePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Friday, March 24, 2006 2:58 PM
Subject: Re: browse lookup phenomenon - SOLVED!!!!!


> Quoting Dennis Malen (Fri, 24 Mar 2006 14:24:15 -0500):
>
>> Jean-Pierre,
>>
>> See paragraph 2 for your answer. Then read the rest of my posting. It
>> explains why I use to do it.
>
> Here's a perfect example of why inline quoting, with trimming, is far
> superior to top-posting.  (Well, at least it's only paragraph 2 that
> I have to count to, rather than, say, paragraph 37.)
>
> [...]
>> > | I was always under the misguided impression that if you have a dummy
>> > | field that was already defined that the dummy field would take on
>> > | that characteristic. I not only use that concept for "rn" but for
>> > | other dummy fields. I thought it always worked.
> [...]
>
> I've read that paragraph several times, and I'm still not sure what you
> mean by it.
>
> If you give a dummy field a length and type, such as "rn(8,.0)", then
> the field will have that length and type.  If you don't give it any
> length and type, then it will take on the length and type of the value
> assigned to it.
>
> What was your "misguided impression" about this?  What did you think
> happened differently?


At the end of an audiobook recently, (Wheel of Time series, Robert Jordan) 
there was a little interview with the author and explained such an obvious 
concept when he mentioned that, and why, he listens to his own audiobooks.

Paraphrasing more in my own words,
When you write something, you always know exactly what it means.
You have some idea, and no matter how incompletely or ambiguously you 
describe it, all it has to do is not actually conflict with your thought and 
it will look fine to you.

But other people can't read your brain and so in order for the communication 
to have any value, all the details must be in the writing or be deduceable 
from it.
It's apparently a common bane of all writers and is a large part of what 
editors or for.

I'd like to think though that any technician, especially when describing 
something technical, should have developed the habit of spotting and nailing 
down every little thing that is missing or could be interpreted more than 
one way within weeks of seeing his first computer.

Writing/talking about programming really requires all the same strict 
attention to detail as programming itself does.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!