Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP Path: utzoo!linus!decvax!tektronix!hplabs!sdcrdcf!sdcsvax!davidson From: davidson@sdcsvax.UUCP (Greg Davidson) Newsgroups: net.lang,net.lang.lisp Subject: Re: Using LISP for scientific programming? (gasp!) Message-ID: <1071@sdcsvax.UUCP> Date: Fri, 30-Aug-85 00:51:15 EDT Article-I.D.: sdcsvax.1071 Posted: Fri Aug 30 00:51:15 1985 Date-Received: Mon, 2-Sep-85 08:55:36 EDT References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> Reply-To: davidson@sdcsvax.UUCP (Greg davidson) Distribution: net Organization: EECS Dept. U.C. San Diego Lines: 129 Keywords: LISP, FORTRAN, C, Ada, Forth, Syntax, Efficiency Xref: linus net.lang:1549 net.lang.lisp:478 Summary: Syntax and Efficiency contrasted across FORTRAN/C/Ada/LISP In Charley Wingate's reply <1418@umcp-cs.UUCP> to my earlier article <1057@sdcsvax.UUCP> he makes several points I agree with, but also spreads some typical myths and misunderstandings about LISP. Let me set the record straight on two points. The first has to to with language syntax, the second with language efficiency. 1. SYNTAX > Obviously you've [I've] never used an HP calculator, which are > very popular among engineers and other physical science types. Indeed I have used them, and I prefer their RPN (Reverse Polish Notation) for arithmetic calculation. However, RPN is not the same as the CPN (Cambridge Prefix Notation) used by LISP. In RPN, the expression _____________ [1] | 2 - b + \| b - 4 a c ________________________ 2 a might be entered as [2] b neg b sqr 4 a * c * - sqrt + 2 a * / with perhaps 29 content keystrokes (depending on lexical syntax). I find this notation easy to enter but hard to read. I also find it error prone, since it lacks clear syntactic grouping. I consider it a poor general purpose notation, and criticise its use for such in the language FORTH. Cambridge prefix (the *default* input syntax in LISP) would enter expression [1] as [3] (/ (+ (- b) (sqrt (- (sqr b) (* 4 a c)))) (* 2 a)) using perhaps 42 keystrokes. This is more readable (when you're used to it) and much less error prone (due to explicit grouping and checkable redundancy). The typical algebraic language would enter this expression as [4] ( - b + sqrt( b**2 - 4 * a * c ) ) / ( 2 * a ) using 27 keystrokes. Thus, Charlie correctly notes: > Lisp also has the disadvantage of requiring more keystrokes, on > the average, and this is not an unimportant consideration in a > world where typing skills are generally poor. However, CPN is only LISP's *default* syntax. Any LISP system using lots of algebraic expressions would define a domain specific syntax. For example, the Macsyma front end (which is just LISP with some syntax macros) allows you to enter expressions in form [4], and prints them back at you in form [1], which I think you'll agree is the most readable; yet Macsyma stores expressions internally in form [3] (as lists). In fact, algebraic languages like FORTRAN, C and Ada do have a general purpose notation which is used in expressing datatypes not built into the language. Its called functional notation. Writing expression [1] in functional notation yields [5] divide( plus( minus(b), sqrt( diff( sqr(b) times(4, times(a, c))))), times(2, a)) which is somewhat more combersome than CPN in reading and writing. It is to the credit of Ada and LISP that they are not stuck with this notation for programmer defined datatypes. FORTRAN and C make programmers reluctant to define their own datatypes because of the resulting syntactic clumsiness. This has a very bad influence on the efficiency and overall quality of programs in those languages. Of the languages I've mentioned, only LISP gives programmers the ability to build a notation tailored to any job. And only LISP lets programs compute with expressions *as* data as well as evaluate them. Yet the design of LISP is very different from the similar designs of FORTRAN, C and Ada. Learning LISP is particularly hard for FORTRAN programmers. 2. EFFICIENCY > Well, the problem comes down to this: most really high speed > computers are much more like Fortran than Lisp. Actually, really high speed computers are parallel (usually vector) machines, which are more naturally programmed in pure-LISP (LISP without side effects) than in Fortran. Typical FORTRAN compilers first turn FORTRAN into a LISP-like tree form, then analyse it to find pieces which obey pure-LISP-like semantics and can be done in parallel. > Fortran tends to be faster, even in the face of compiled, > optimized Lisp. Agreed. This is because more effort is put into the efficiency of Fortran compilers on numerical code than any other language, including C and Ada as well as LISP. This is despite the poor correspondence between Fortran and modern computer architectures, not because of it. > the obvious retort is "well, why shouldn't I pick the language > which is at least as fast as Lisp, and often much faster?" Indeed. FORTRAN is the most used language, hence gets the most attention from compiler writers, hence is usually the most efficient language, hence continues to be the most used. How can we break this vicious cycle of mediocrity? > In an interactive debugging mode, Lisp is almost always much slower. In interactive debugging, LISP is almost always faster, since Fortran programmers are trapped in the slow and expensive edit/compile/run cycle. A typical Lisp system's mixture of interpretation or compilation (often incremental compilation as a third alternative) is much more efficient of both machine and human time. > Save Lisp for the applications in which it really shines: > symbolic manipulations (like MACSYMA). Indeed it does shine. Let people know about this. Use tools like Macsyma when you can get them, and use LISP whenever suitable. As LISP has been getting more attention lately, better compilers have appeared. As good compilers become available and LISP becomes better understood, it will displace FORTRAN, C and Ada; unless and until something even better comes along. _Greg Davidson Virtual Infinity Systems, San Diego