Newsgroups: comp.lang.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!jtsv16!blister!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Write-only languages (was Re: scheme)
Message-ID: <1991Jun19.153902.3993@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
References: <OZ.91Jun12001150@ursa.ccs.yorku.ca> <56569@nigel.ee.udel.edu>
Date: Wed, 19 Jun 91 15:39:02 GMT

In article <56569@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>
>Actually, FORTH is also an extremely write-only language.  I also find
>that Lisp is somewhat write-only when complex programs are programmed
>in a funcational style.
>
>I suspect that languages are write-only more because they lack names for 
>local variables or intermediate results that because they have unusual
>characters representing functions.  I mean, who would want to write
>out "iota" or "rho" every time you wanted an array? :-) :-)

IMHO, languages are write-only less often than applications. 
Languages may enhance or reduce the clarity of expression of algorithms
depending on the facilities provided in the languages. For example,
languages which don't supply function call by name, only by line
number (BASIC gosub 12345 is the only one I recall now) reduces
clarity of expression:

a. The 12345 possesses NO semantics content relevant to the algorithm.

b. Maintenence becomes a nightmare, because of line insertion problems.

Applications lead more often to write-only-ness because of design decisions
made (or ignored) by the application developer:

a. Use of globals rather than functional interfaces. This means that
   replacement of a functional unit with a new functional unit
   (Say a symbol table search/update routine) becomes a nightmare,
   in which you must first analyze the ENTIRE system. 

b. Use of implicit arguments. This is another globals issue.

c. Failure to write code with an eye toward maintenance and evolution.
   The "gee-whiz ain't I bright " approach to coding is fine for rec.puzzles,
   or for school coding projects or problems, but is disaster in a real
   commercial, scientific, or industrial setting.  Even something as
   simple as hand-unrolling loops for faster execution on a pipelined
   machine, such as the Cray X-MP,comes back to haunt when you try to 
   port the code to a different architecture, such as a Connection Machine.

   Better to suffer the  poorer performance on one machine for algorithmic
   clarity, and lean on the compiler writers to do it properly.

   As a concrete example, consider matrix-matrix product. Writing 5 lines
   of DO Loops in Fortran is OK, as newer compilers can figure that out.
   Calling MATMUL is also OK. In both cases, the compiler or run-time library  
   can do its thing properly for the host. However, a tangle of unrolled
   code might often run worse when a change in hardware or software
   platform occurs.

The write-only code issue is NOT a language issue nearly so much as it
is an issue of attitude and adherence to principles of maintenance.

Bob











Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
