Subject: Re: Theory #51 (superior(?) programming languages)
From: Erik Naggum <>
Date: 1997/01/25
Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Message-ID: <>

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

#| -*- 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))))))

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

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.

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

| 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!"

1,3,7-trimethylxanthine -- a basic ingredient in quality software.