new@ee.udel.edu (Darren New) (06/18/91)
In article <ADRIANHO.91Jun14213017@barkley.berkeley.edu> adrianho@barkley.berkeley.edu (Adrian J Ho) writes: >> Scheme seems to share much of its syntax with >>Lisp, which tends to be a "write only" language. >Hardly true of Scheme/Lisp. The only language that might be truly >said to possess this characteristic is APL, and only because of its >infernal character set. (Because of this, APL is the one language >I've encountered in my life that I've never _wanted_ to master.) >Substituting each APL operator with a descriptive name would certainly >go a long way towards making it less of a "write-only" language. 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? :-) :-) Food for thought, so your brain doesn't starve... -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+ Nails work better than screws, when both are driven with hammers +=+
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (06/19/91)
In article <56569@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: > >>Hardly true of Scheme/Lisp. The only language that might be truly >>said to possess this characteristic is APL, and only because of its >>infernal character set. (Because of this, APL is the one language >>I've encountered in my life that I've never _wanted_ to master.) >>Substituting each APL operator with a descriptive name would certainly >>go a long way towards making it less of a "write-only" language. Easily done: A number of workers in APL design have come up with a new dialect of APL known as J. J has the following characteristics: a. Use of ASCII, rather than APL symbols, thereby ending the tyranny of the keyboard/printer. b. Simplified syntax and semantics -- a lot of the old rough edges which crept into APL have been removed, such as funnies with square brackets. c. First-classness of objects. d. New versions of J include control structures for DO UNTIL, CASE, Recursion, as well as generalized reductions. This will appear in "Gerunds and Representations", in press - ACM SIGAPL APL91 proceedings, R. Hui and R. Bernecky. e. ABility to call J from C and vice versa. Articles on J appear in APL90 (Hui, Iverson, et al), recent issues of SIGAPL Quote Quad, Vector(British APL Society), and in an article which appeared in SIGPLAN Notices Feb 1991: "Fortran 90 Arrays", by yrs trly. J is available as shareware through a number of bulletin boards (watserv1 is one of them), and from Iverson Software Inc, 33 Major St. Toronto. ($24 for the pc version. Not sure about other versions). Regarding Character Set Theology: See my article in SIGAPL Quote Quad, Septmber 1990: "Quad av considered Harmful -- still". ps: These articles all have the WRRONG email address for me, due to my inability to type. See below for the correct one(s). the rbe@yrloc... is preferred. 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
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (06/19/91)
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
wdr@wang.com (William Ricker) (06/25/91)
[ I suggest we Follow-up-to: alt.folklore.computers; this is getting afield] rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes: >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. I'll agree with that. To a large degree, readability is a matter of discipline in the code's author (& manager & architects). I've written unreadable code in many lanugages and readable code in as many -- the same ones. It depends on attitude and taking the time to do it right the first time, because code you think you'll throw away you won't be allowed to, or later wish you hadn't. To call a language write-only because the non-writers can't read the code of the users is parochial; To call a language write-only because writers without style can't read their own code is to inadequately share the blame. The author and designer of code should always, no matter whether in Knuth's WEB or an APL workspace, plan the presentation of their code and comments, or rather, of their comments and code. We can blame a generation with lousy penmanship and arithmetic skills on Bic Ballpoints, Smith-Corona portable electric typers, and TI calculators, or we can blame an attitude of quick and shoddy is good enough. Certainly in the spirit of Don Norman's /Psychology[Design] of Everyday Things/, [s]he who designs a hard-to-use tool deserves as much blame as [s]he who [ab]uses it. Designers of languages *or* the frontend utilities (like editors & compilers) should consider readability and writablitity, and be graded on same. But if it's trivial to write emacs macros that get the syntax right for you, is it fair to criticize that it's hard to type all the {}; or ((( ))) ?? COBOL and C are both civilized languages when you have the right tools; colleges with Survey Of Languages courses don't usually have a Screens Generator and a Data Dictionary to go with the Cobol compiler for the one COBOL assignement. I wish I had SABRE-C's C editor. I'll also note that most criticism of languages by those not using them regularly are usually based on the seminal documentation; no program written lately in a language calling itself PASCAL or anything listed above would compile with academic release one of the language of same name; all the recent usable releases have practical & theoretical extensions that make them usable. Like loops & if-then- -else in APL, LISP, FORTRAN, COBOL; standardized I/O in Pascal; Data Dictionaries to write the boilerplate COBOL automagically, etc. I've seen incredibly legible APL, FORTH, & LISP, when the programmers raised the level of the extensible language into the problem domain; I've also seen APL, FORTH, and LISP that was as proudly obscure as anything in the Obfuscated C Contest -- and C almost as bad in products. APL got a bad wrap from the educational game of "one liners", in which one competes to invent obscure abuses to do an arbitrary task in 80 chars or fewer, or having done so, challeges colleagues to decipher same without benefit of comments or sensible variable names. This is actually an interesting exercise for learning the powerful operators inside & out -- which wouldn't occur in a language less rich in operators -- but was (a) the common stereotype of APL hackers, and (b) adopted by too many folk as the True APL Style. Large APL shops operated by Boeing, STSC, (and I assume Sharpe) etc gravitated toward a more maintainable style rapidly; Rose's books document this. I've written both readable and unreadable code in most of the so-called Write Only langauges, including several not mentioned here. My list of Write Only Languages (and which version I used) APL 370,5110,J Assembler 370,PDP11,MASM BASIC EduSystem-8,-11 C Unix PWB,7,III,V.*,4.*,MS5.10 COBOL + TOPS-10 FORTH MMS on TRS-80 FORTRAN-II,IV EduSystem-11/L (II); IBM G,H; TOPS-10; Pr1me [57]50 LISP (before SCHEME) Franz SNOBOL * ** TECO macros ++ TOPS-10 *** * begat Icon, alegedly readable, which begat Pearl. (I fear if I looked at Pearl I might decide it was WO also, and then I'd have missed two.) I've heard a deck of blank cards attacked by a lunatic with an icepick would have been a valid Snobol program which would produce output; I'm not sure if this is true, but ... ** only one I've Missed *** heard of a fellow at same site who implemented bubble-sort in TECO. I used TECO macros as equivalent of AWK/SED/TR command pipes. + I've written so few lines of COBOL, I think all 3 lines were readable. ++ I doubt I wrote any readable TECO macros! But RMS's mock-lisp for the TECO-implementation of Emacs would count as having seen some. Flames to /dev/null, historical oriented followups to alt.folklore.computers, please. --- bill [gee, am I getting to be as old as this sounds? ack! ] -- /s/ Bill Ricker wdr@wang.wang.com "The Freedom of the Press belongs to those who own one." *** Warning: This account is not authorized to express opinions. ***