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