When words are good and when words are bad

[David Herron, NPR Lover]

First a couple of quotes to set the stage....

In article <508 at oliveb.UUCP> jerry at oliveb.UUCP (Jerry Aguirre) writes:
> I have seen several projects coded in the "make it look like algol" style
> of programming.  They define BEGIN to be { and END to be ;}, etc.  It always
> seems to cause more trouble in the end than it saved.  By the time they
> finished the project they are usually familiar enough with the language
> that they no longer need these crutches.  Experienced C programmers get
> frustrated trying to follow the code because there is always this extra
> level of indirection that has to be verified as correct.  I have at
> times refused to help users with "C problems" because figuring out
> whether the syntax is correct requires reading a 300 line header file
> that compleatly redefines the language.

In article <2600006 at ccvaxa> preece at ccvaxa.UUCP writes:
> Unfortunately, the name 'opentest' doesn't imply that the variable
> named 'foo' has been set to the new fd and that the file is now open.
> It implies (to me, at least) a test of whether it is possible to
> open the file.  Now, if you wanted to call it "TRY_TO_OPEN", I would
> be more likely to interpret the name correctly, but some people might
> interpret that name as a Boolean indicating whether or not to try to
> open the file.  Naming is very tricky.  Doing the operation is very
> clear.

I thought this was an interesting juxtaposition of ideas.  On the one hand
we have we have this argument to make C look like C.  The idea is to
avoid using "increment(i)" because the meaning of "increment()" isn't
all too clear, and there's already an operator to do the desired
function anyway ....

On the other hand we have somebody saying that a particular word isn't
clear enough (opentest) and offering up another (TRY_TO_OPEN) saying
that his is unambiguous.  (I don't quite follow him though, since 
all EITHER open() or fopen() do is TRY_TO_OPEN a file, returning
an indicator as to their success, that the indicator is also useful
in later code isn't important).

What I think both these people are trying to say is that WORDS are
very imprecise.  Especially when asked to handle precise objects
as are found inside computers.  But then my biggest gripe about
pascal is that it's full of words.  The words get in the way of
understanding the code.

To sum up (and to get to sleep).  Why can somebody see an infinity
of additions in an integration, but it only takes up a half line
of a page?   It's the expressive use of symbols.  That's what
does it.  Or taken from another tack.  One of the neatest things
I saw when I was first on Usenet was a picture of a see ship
floating in a V shaped trough of water.  But this wasn't a real
picture.  This was a drawing on a CRT screen.  One of the lowest
resolution mediums ever available.  (Line printers are the next
lowest I can think of).  Yet somebody was able to make a believable
picture of an ocean liner floating in a gallon of water in
a huge V shaped trough.  

They didn't use words.  They used symbols.  And lines.

Why do words have to be the only medium of communication?  They aren't
y'know!  But some people act as if they were.

Now.  To bring this back down to C....

One of the BEST features of C is that 90% of the words you see
on the page are VARIABLES.  And ALL words are seperated by graphical
symbols of one sort or another.  Enabling you to quickly see where
variables are (as long as you don't name Input File as "if") and
where all the operators are.  (i.e. you don't have a = b mod c,
instead you have a = b % c).

G'night.  I'm rambling.
-- 
--- David Herron
--- ARPA-> ukma!david at ANL-MCS.ARPA or ukma!david<@ANL-MCS> 
---	   or david%ukma.uucp at anl-mcs.arpa
---        Or even anlams!ukma!david at ucbvax.arpa
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david

	"It's *Super*User* to the rescue!"