Path: utzoo!mnetor!uunet!husc6!bbn!rochester!PT.CS.CMU.EDU!cadre!pitt!jonathan
From: jonathan@pitt.UUCP (Jonathan Eunice)
Newsgroups: comp.lang.misc
Subject: Re: Readable names
Message-ID: <3125@pitt.UUCP>
Date: 24 Mar 88 13:19:46 GMT
References: <2857@enea.se> <2779@mmintl.UUCP> <2899@enea.se>
Reply-To: jonathan@pitt.UUCP (Jonathan Eunice)
Organization: University of Pittsburgh Computer Science
Lines: 46
Summary: Compactness != efficiency

Erland Sommarskog wages a reducing-to-absurdity argument against
heavily truncated and abbreviated names of programming objects.  Ed
Biagioni replies "natural language needs its reduncancy, to avoid
misunderstandings," and more to the point, "there are many more compact
ways of of writing our thoughts down, but very few better ways of
communicating our thoughts."   

Exactly!

If your aim is to be precise, symbolic notation wins every time.  But
when your aim is to communicate, to be understood, then including the
redundancy is a Good Idea.  Not just in natural language, mind you, but
in programming, mathematics, logic, and so on.  The shortest statements
can take the longest time to read, because the reader must figure out
what it means, must translate or interpret it at read-time.  Isn't this
why math, logic, and some C programs are so hard to figure out?  It's
the classic space-time tradeoff: represent more compactly, but then you
must spend more time generating the desired information or details upon
retrieval.  Efficiency of reading should be measured by how long it
takes to understand the material, not how long it takes the eyes to
scan it.  When evaluating a notational scheme, such as a programming
language, it's the time-to-understanding figure that's important.

Writing programs is a form of communication, with the machine somewhat,
but with yourself and other programmers, moreso.  You must understand
your own code/theorems/methods to use/revise/prove/improve them, and
this is not as easy as it seems.  That's often why bugs creep in --
don't tell me you don't have bugs, even in the most precise symbolic
notation -- we often do not fully understand the
effects/side-effects/implications of our own code/decisions/methods.

Of couse there are things like COBOL at the other end of the world,
where the information conent (ratio of information to bulk) is so low
that it is difficult to put the information together in a coherent
fashion.  (Please, no COBOL-IS-OK-FLAMES.)

You can't have Too Much or Too Little, it's got to be Just Right.  This
is somewhat a stylistic issue, so not something that's really
"solvable" in an objective sense, but it's important to see the
tradeoffs involved, not just run a "my style is better" flame war.

------------------------------------------------------------------------------
      Jonathan S. Eunice                    ARPA: jonathan%pitt@relay.cs.net
   University of Pittsburgh          UUCP, CSNET: jonathan@pitt
       Computer Science                   BITNET: jonathan@pittvms
        (412) 624-8836