🚀 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.

Huh. "Studies show", incidentally, that it is HARDER to debug a programe
after you have read the documentation - strange but true. The reason is
that once you have read the author's description of what s/he THINKS a
programme does, you are no longer in a position to spot errors in the
code: you are no more useful to the maintenance effort than the original
author was. Other terrible things in the code above are the use of the
technical word "type" in a context where some generic notion of "kind"
is presumably intended, the use of "deg" and "sep" which are utterly
opaque, and the choice of a namespace, "rand_", which is GUARANTEED to
collide with other things in the system....

Actually what is needed is to totally decouple the *reader's* choice of
identifiers from the writer's and the linker's. A german speaker should
be able to open a view on your code with german language identifiers -
why not? And languages like C that are constantly forcing you up against
the inane 32-character identifier limit just so that you can be
tolerably sure your names won't collide are absurd.

My point: this just isn't a problem that can be solved on the "paper
model" - the environment MUST take an active role in displaying source
code. Even if it were merely a matter of personal preference this would
be true - reducing the amount of time spent reformatting code so that
you can read it is laudable in its own right. But since it really
*matters* whether code is being subject to a casual reading or a serious
debugging session, it seems unavoidable that the problem must be
addressed directly.

[someone else said:]
|>Trying to find one notation that serves such diverse environments is
|>not easy.

Making compilers support Unicode *now* would be a big help! ASCII is
dead....

|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.  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.  It is not the
|same as CS subscripting, which is a form of memory allocation; mathematical
|subscripting has semantic similarity, but not the rigidity.  In a draft
|paper of mine, I have three such modifiers on one variable, and this is
|not unusual.  Papers in relativity use tensors of order 4 in a routine manner.

It's function application. Said it before, say it again, that "memory
allocation" issue is none of the programmer's fooking business and
arrays are just functions that (unfortunately) happen to return mutable
values. It's all categories, you know?

|In addition to the number of variables, there are typically constants
|which are given names.  Pi, Euler's constant, Catalan's constant, the
|Bernoulli numbers, the Euler numbers, the symbols for such things as
|the set of real numbers, the set of integers, spaces such as L_p (L sub p),
|etc., occur.   A moderate size paper may very well have 100 basic symbols,
|plus subscripting.
|
|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.

It's there in Emacs (though a bit of a hack); it's there in WordPerfect.
All it takes is some tweaking in the scanner. Unfortunately Unix (tm) is
Perfect (tm) and all text must be flat ASCII (or haven't you heard?)....
I think it's some kind of religious law.

|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.

Sadly, the alternative (if we're strapped with ascii) is to use things
like :^ and :v which are at best only slightly better. There's a dire
shortage of suitable operator characters in ASCII - or have you never
sat down to work out an alternative?
------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------