🚀 go-pugleaf

In article <Bw2I3B.L1n@mentor.cc.purdue.edu>
hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>Here are some examples from one of the less nasty programs, srandom.c
>
>static  long            *state                  = &randtbl[ 1 ];
>
>static  int             rand_type               = TYPE_3;
>static  int             rand_deg                = DEG_3;
>static  int             rand_sep                = SEP_3;
>
>static  long            *end_ptr                = &randtbl[ DEG_3 + 1 ];
>
>initstate( seed, arg_state, n )              
>
>if(  ++rptr  >=  end_ptr  )  rptr = state;
>
>Now possibly these long names may be of some use to someone who does not
>know what is going on and has not read the documentation, but most of it
>is internal to the program.  Now I do not suggest that only one-letter
>names be used, but I would use much shorter ones.

If you have to maintain 5000 _pages_ of program, you don't know what's
going on.  You just don't live that long.  Documentation?  What
documentation?  "We wrote something eight years ago, but we've changed
that module three times since then."  In real programming environments,
self-documenting variable names are _very_important_.  You can't have
such names in two or three characters.  I consider the above pretty
minimal.

>There are several problems involved.  For one, it is not the case that
>mathematicians, and those using mathematics, use ONLY one-character
>names for variables; at least a large number of papers, if not most,
>use subscripted and superscripted variables, and this is semantically
>the use of multi-character symbols.  Certainly to me, superscripts and
>subscripts are characters in a different font.

If I understand you, then I agree.  You can think of scripting as
"stringing" letters together to form identifiers.  The problem is that
current computing systems just don't support this notion well.

>In addition, the use of superscripts and subscripts carries the idea of
>a modifier to the variable which is the same over many variables; this
>is a structure which CAN be handled in the CS version, but not easily.

Substripts, as I've often seen them used in math, have no formal
meaning beyond just extending the symbol set.  (This excludes, of
coarse, substripts used to access vector or matrix elements.)

>It is not the same as CS subscripting, which is a form of memory
>allocation; mathematical subscripting has semantic similarity, but not
>the rigidity.

CS substripting (usually) identifies a variable among a homogeneous
set.  It has nothing to do with memory allocation (semantically, though
often in practice).  It is like the math subscripts used to access
vector elements.

>A moderate size [math] paper may very well have 100 basic symbols,
>plus subscripting.

Great, a moderate size program (as in non-trival, but a one person
project) will have well over 1000 symbols.

>Now present technology is quite adequate to have a multi-font system
>without going into contortions.  A computer which did not catch on because
>of other problems provided for 16 128-character fonts, all user-modifiable,
>and this was more than ten years ago.  Possibly the CS language people can
>have some influence on the display software and hardware people to get this
>simple thing done; not only would I like it, but I assure you that the 
>secretaries who type our papers would greatly prefer it to what we have.

There's a reason it didn't catch on.  No one wants to by a system that
isn't compatible with previous stuff.  We keyboard layouts much better
than QWERTY now too, and no one wants to buy them either.  The problems
are generally not technical feasibility (what this group can worry
about) but commercial feasiblity.  I'd change alot too, if anyone would
listen.

>There is another nit to pick.  It may be necessary to use notation different
>from what the mathematicians use, such as when Fortran was introduced, the
>use of * for multiplication and ** for exponentiation.  But the deliberate
>use of what is essentially standard mathematical notation for certain
>operations by CS people to represent other operations which also may have
>fairly standard, but different, notation should certainly be avoided.  Two
>of the Boolean operators in C, for example, are of this type.  One of them
>is even used for something different, and useful, in computer literature.

Can you be more specific?  I suspect that the problem is that the
standard boolean operators (\vee and \wedge) weren't available, and
hence they coopted other ASCII symbols that were reasonable.  Boolean
operators are more important to programming than most other
mathematical operators.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202