Subject: Re: Theory #51 (superior(?) programming languages) From: Erik Naggum <erik@naggum.no> Date: 1997/01/25 Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme Message-ID: <3063147946409477@naggum.no> * David Hanley | [Common Lisp] can come close [to C] in some cases, however. and in some cases, CL far exceed the wettest dreams of C programmers. nearly exactly a year ago, some prejudiced fool presented a snippet of Lisp code that was very slow in CLISP and blamed Lisp as such for it in a Norwegian newsgroup. I compiled his code with CMUCL, and it ran twice as fast as C. just for kicks, I've done the same with Allegro CL. my system is a 50MHz SPARC 2+, running SunOS 4.1.3_U1. the code: #| lotto.cl -*- mode: common-lisp -*- 35453.053353 |# (in-package :user) (declaim (optimize (speed 3) (safety 0) (debug 0))) ;; the following declaration helps ACL avoid boxing. (declaim (ftype (function (fixnum fixnum) fixnum) lotto)) (defun lotto (n m) (declare (fixnum n m)) (the fixnum ; same thing for CMUCL (cond ((= m 1) n) ((= m n) 1) (t (+ (lotto (1- n) (1- m)) (lotto (1- n) m)))))) #| lotto.cl ends |# /* lotto.c -*- mode: c -*- 35453.046640 */ #include <stdio.h> int lotto (int, int); int main (void) { printf ("%d\n", lotto (35, 7)); return 0; } int lotto (int n, int m) { if (m == 1) return n; if (m == n) return 1; return lotto (n - 1, m - 1) + lotto (n - 1, m); } /* lotto.c ends */ lotto.c was compiled with gcc -O3. $ time lotto 6724520 4.42user 0.04system 0:04.50elapsed 99%CPU in ACL, (time (lotto 35 7)) reports: ; cpu time (non-gc) 4,550 msec user, 0 msec system ; cpu time (gc) 0 msec user, 0 msec system ; cpu time (total) 4,550 msec user, 0 msec system ; real time 4,561 msec ; space allocation: ; 2 cons cells, 0 symbols, 32 other bytes 6724520 in CMUCL 17f, (time (lotto 35 7)) reports: Evaluation took: 2.15 seconds of real time 2.04 seconds of user run time 0.0 seconds of system run time 0 page faults and 0 bytes consed. 6724520 you can draw your own conclusions. don't blame me for the code, it was supplied by said prejudiced fool, except I cleaned it up somewhat syntactically. | Not true. If all checks are off, lisp will probably be less safe than C, | because of it's reliance on linked structures, and still not quite as | fast, for the same reason. look, "not true" and "probably" don't belong in the same sentence. if you don't know, don't pretend you do. I loathe people who *guess* and don't even know they do it, but go on with their *guesses* is if they are facts. Lisp programmers turn off checks when they have tested their code, and they get very useful debugging help if and when something breaks. if you have a type error, you can see where the problem is, immediately find the caller, edit it right away, and restart evaluation with the new code. a Lisp programmer has done all this and is moving on by the time you have started to edit your code. (some "IDE"'s for C++ offer a limited version of the same, finally catching up to Lisps of 20 years ago.) moreover, in a large system, with many strange dependencies, you will have a hard time finding all callers if you change the type of a C function. in Lisp, you don't need to change the callers, because you can dispatch on the type of the argument. if you _do_ need to change all the callers, the magical incantation can be just M-x fi:edit-who-calls RET, and the Lisp system knows where to find all callers. quite a different league from C. | Maybe he has different goals, or doesn't share your religous convictions. the hallmark of a loser is that he tries to portray an opponent as "religious" if he can't win an argument because facts don't match his own convictions. it's disgusting to behold. it's almost as bad as dragging in the Nazis, which happens _once_ in every otherwise never-ending USENET discussion. I believe the technical phrase is "to hitler a discussion". a similar term for people who think "religious" is a similarly bad name should be found. maybe "to hanley a discussion" will do for now? | It's a lot worse than C. In C, if you get your types bunged up, the | compiler will probably let you know at compile time. The same is more | true for 'better' languages like SML, Modula-3, heck, even C++. *sigh* the static vs dynamic type mythology, again. people who can't see both sides of this issue have a problem that no language can help solve. all of the Lisp systems I have used have reported conflicts if I declare the type of values I will put in a variable and I lie about it. type propagation is an important part of any good Lisp compiler. | This wories me quite a bit; I infer that speed three safety zero has the | potential of changing the behaviour of algorithms. That seems pretty | dangerous! I wouldn't trust a C optimizer that had the potential of | changing how my (correct) code behaved. hahaha! you're stretching so far it's _hilarious_. "if I drive to Boston with this safety belt on, I get to Boston, but if I don't use it, I might end up in a graveyard back home. pretty dangerous change in algorithm!" #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.