From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!macrakis From: macrakis@harvard.ARPA (Stavros Macrakis) Newsgroups: net.ai,net.lang.lisp,net.lang.ada Subject: Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Message-ID: <473@harvard.ARPA> Date: Thu, 14-Mar-85 15:50:24 EST Article-I.D.: harvard.473 Posted: Thu Mar 14 15:50:24 1985 Date-Received: Tue, 19-Mar-85 14:31:36 EST References: <470@harvard.ARPA> <308@cmu-cs-k.ARPA> <417@ssc-vax.UUCP> Organization: Aiken Comp. Lab., Harvard Xref: watmath net.ai:2623 net.lang.lisp:388 net.lang.ada:229 List-Id: I don't mean this to go on forever, but Maroney's gross distortion of my point forces me to: > That seems like some pretty dumb code to put in Lisp. Iteration, setq -- > yech! I don't think any person in their right mind would disagree that > Fortran-like or Algol-like languages are far better suited to this style of > programming than Lisp. > Now, let's see you write a recursive linked-list program in Fortran, which > doesn't have stack-based calling, pointers, or anything remotely like > structured data types.... -- Tim.Maroney@CMU-CS-K The point was simply that in fact MacLisp numeric code is not all that it's cracked up to be, and indeed if you want efficient number-crunching you use some other language. Fortran happens to be the language in terms of which the original argument was couched. Given what I know of the internals and the I/O behavior of both the Maclisp compiler and the Intermetrics AIE Ada compiler (I work part-time there), I suspect that it too will produce better numeric code but also non-numeric code (including handling recursion, linked lists, etc.) than Maclisp. Regrettably, garbage collection was not funded in the AIE. Having worked with Lisp for 14 years now, I think I have some idea of its strengths, which in my opinion are being diluted by pretending it is just a general-purpose language with a funny syntax and poor type-checking. > The most sophisticated Lisps (such as Common Lisp) include a wealth of > other datatypes intended for high efficiency in applications. -- shebs Here's an example of the `wealth' of datatypes from a member of the Common Lisp committee: "Common Lisp arrays are incredibly complex.... The resulting tangle of types...is clearly a political compromise and not something that would exist after careful design". [RA Brooks and RP Gabriel (an very experiencied Lisp implementer), "A Critique of Common Lisp", 1984 ACM Symposium on Lisp and Func. Prog.; an excellent paper, by the way] > For many years, the Maclisp compiler on the DEC-20 has produced > numerical code superior to Fortran. -- stan shebs This is not and never was true. See my previous posting. As for poor Common Lisp, "it requires either specially micro-coded machines, a fantastically complex compiler (which relies on copious declarations from the poor incompetant user), or very slow running time." [ibid] > There was an informal experiment done in the early-mid seventies at > MIT [: a] translator was written to translate (say) FORTRAN into > MACLISP.... In every case the lisp versions ran faster and took up > less memory.... The programs being used were purely [numerical]. -- > sasaki@harvard This is the same error being repeated. Fateman's 1974 SIGSAM Notes article seems to be the source. There was exactly one example given, and my previous posting discusses why it did well. Indeed, Macsyma has both a Fortran-to-Lisp translator (written by Kent Pitman) and a numerical-Fortran-code-generator. They are both useful: F-L to import numerical libraries into Lisp (unfortunately the runtime conventions apparently clashed too much to allow Fortran code simply to be linked in); Macsyma-F to use symbolic results to generate Fortran programs which were then run on other machines. Lisp is a wonderful language, but it has never run numbers fast. It is even less likely to run numbers, or anything else, fast, in its current PL/I-like phase of development. -s