Firstly, the language comparison is with C++, Java and SML as well, all of
which have multiple implementations. Indeed, two implementations of SML are
already on the language comparison. Secondly, of the languages you listed,
at least Perl and Python have multiple implementations. Finally, the number
of implementations is irrelevant.

I'll have a look at Lispworks...

When I was younger (now I am 31) I also believed benchmarking is a
must. However, in the meantime it is even this: if your ray-tracer in
OCaml were 100000 times faster than the Bigloo-Scheme version I would
not opt for OCaml quickly. Perfromance is important, no question, but
in a code project it is a rather tiny part.

I agree that in most problem domains, constant time speed factors are
pretty much irrelevant for 95% of code, and we should be very skeptical
about judging "language speed" by simple benchmarks like this, because
an easier to program language, often leads to better algorithms, as well
as a lot less programming time (and less downside variation in program
speed -- cf: Erann's lisp-java-c experiment: the fastest C programs just
beat the fastest lisp programs, but many of the C programs were *much*
slower than the slowest lisp programs).    

But those tradeoffs aren't the same for all problem domains.  In those
rare problem domains where there's always lots time to optimize relative
to the runtime available, bare speed matters.

The problem is that it's still hard to tell the difference between a
faster language and better writers of optimized code, as the almabench
thread demonstrates.  How much time do you spend on optimization before
you abandon the project and say "It's easier to make this fast in X".
And obviously some things will be easier to optimize in language Y than
others.  All this makes any given benchmark or set of benchmarks suspect
as an absolute measure of speed, but it doesn't completely invalidate
their potential usefulness, as long as one understands what they mean
and what they do not mean.

However, LOC overly penalises Lisp and Scheme, IMHO. Specifically, Lisp and
Scheme programs are virtually unreadable unless the parentheses are
staggered by spreading expressions over several lines and using an
automatic indenter. So if I were to put a Lisp implementation of the ray
tracer on my site then I'd either state that, or I'd give results using
some other measure of verbosity, like characters. I do think Lisp deserves
to be somewhat penalised in this way, but LOC goes too far.

In contrast, my ray tracer involves integer and floating point arithmetic,
3D vectors, trees, tagged unions, recursion/iteration, naturally functional
(e.g. vector ops and ray_sphere) and imperative (e.g. for loops) style. So
it tests quite a lot using very little code and it is fun to play with.
This diversity also makes the collection of ray tracers a better
educational tool - people can glance at the code and see how different
things are implemented in different languages.

token count probably would be better

; Jon Harrops little raytracer
; With bits from Jan Van Lint's version and Nathan Baum's version
; Currently not working

(defconstant delta (sqrt long-float-epsilon))
(defconstant infinity most-positive-long-float)

(defun v* (s r) (map 'simple-vector #'(lambda (x) (* s x)) r))
(defun v+ (a b) (map 'simple-vector #'+ a b))
(defun v- (a b) (map 'simple-vector #'- a b))
(defun dot (a b) (apply #'+ (map 'list #'* a b)))
(defun unitise (r) (v* (/ (sqrt (dot r r))) r))

(defstruct ray orig dir)
(defstruct sphere center rad)
(defstruct group sphere scenes)

(defun ray-sphere (ray sph)
  (let* (t1 t2
         (v (v- (sphere-center sph) (ray-orig ray)))
         (b (dot v (ray-dir ray)))
         (disc (+ (- (* b b) (dot v v)) (expt (sphere-rad sph) 2))))
    (if (minusp disc) infinity
      (progn (setq disc (sqrt disc))
             (if (minusp (setq t2 (+ b disc))) infinity
               (progn (setq t1 (- b disc))
                      (if (plusp t1) t1 t2)))))))

(defun intersect (ray scene)
  (labels
   ((lp (hit scene) ; car hit is a lam, cdr a simple-vector normal
        (if (sphere-p scene)
            (let ((lam (ray-sphere ray scene)))
              (if (>= lam (car hit)) hit
                (cons lam (unitise
                           (v- (v+ (ray-orig ray) (v* lam (ray-dir ray)))
                               (sphere-center scene))))))
          (if (group-p scene)
              (if (>= (ray-sphere ray (group-sphere scene)) (car hit)) hit
                (reduce #'lp (group-scenes scene) :initial-value hit))
            (error "not a group or sphere in intersect")))))
   (lp (cons infinity #(0.0 0.0 0.0)) scene)))

(defun ray-trace (light ray scene)
  (let* ((hit (intersect ray scene))
         (lam (car hit))
         (normal (cdr hit)))
    (if (= lam infinity) 0.0
      (let (g (dot normal light))
       (if (plusp g) 0.0
         (let ((p (v+ (v+ (ray-orig ray) (v* lam (ray-dir ray)))
                      (v* delta normal))))
          (if (< (car (intersect (make-ray :orig p :dir (v* -1.0 light))
                                 scene)) infinity) 0.0 (- g))))))))

(defun create (n c r)
  (let ((obj (make-sphere :center c :rad r)))
    (if (= n 1) obj
      (let ((rt (* 3.0 (/ r (sqrt 12.0)))))
        (labels ((aux (x z) (create (1- n) (v+ c (vector x rt z)) (* 0.5 r))))
          (make-group :sphere (make-sphere :center c :rad (* 3.0 r))
                      :scenes (list obj (aux (- rt) (- rt)) (aux rt (- rt))
                                    (aux (- rt) rt) (aux rt rt))))))))

Hmm.  What would you (JH) be measuring here?

a) Keystrokes required to produce the code (see below, though)
b) Some kind of 'intrinsic verbosity', which would require some *serious*
thinking about idiomaticity, relevance of formatting and massive, massive
sampling to make it statistically relevant.

Oh, and all the ')))))' you see probably didn't get typed by hand (
<META-RET> closes all open parens).

Consider the example:

(defun fib (x)
          (if (<= x 2)
              1
              (+ (fib (- x 2))(fib (1- x)))))

In ML this is:

let fib x = if x<=2 then 1 else fib(x-2) + fib(x-1)

That may be easier to parse for the machine (I don't think it is though) but
maintainability is about how easily a human can parse it.

(defun fib (x)                              
  (if (<= x 2)                      
      1                              
      (+ (fib (- x 2))(fib (1- x)))))

and the code obeys more of the conventions: it is much easier to read.
(Still not perfect, because there should be a space between the "))"
and the "(", but good enough).

If you are counting or reading brackets manually when writing lisp
code, you are doing something wrong.

/Jon

When the lisp reader sees the first paren above it begins a new list,
and puts each symbol it meets in the list.  When it hits a closing
paren it closes the list and goes back to the previous one it was
processing.  There are a few exceptions, but this is generally how it's
done.

In BNF this can be represented like this:

s_expression = atomic_symbol | "(" s_expression "."s_expression ")" |
            list
list = "(" s_expression < s_expression > ")"

There are many list functions that handle the language.  Of those there
are 3 main ones:
* "read" brings the textual form into memory (s-expressions -> trees)
* "print" does the reverse, (trees-> s-expressions)
* "eval" interprets code, executing the functions specified in the
trees

This has some interesting repercussions.

Firstly, at the language level, since everything - data and code - is
represented as above the language becomes more amenable to automatic
operations.
Some examples:-

1. If I load my buggy version of your raytracer into lisp and do:

(setq foo (ray-sphere ray sph))

foo now contains a huge tree.  Should I want this tree in the future
(for more debugging f.e.g) I can print it to a file with print, then
later read it back with read.

2. Emacs does not have to guess things about lisp.  With other
languages it occasionally has to guess, because it cannot understand
the syntax in reasonable time.  When it tells you all the parens match,
they match.

3. In a place (a fearful place :) ) that doesn't have emacs all is not
lost.  If lisp can read the code it can print it.  So, I can quote the
list with a quote mark*, and watch it:

'((defun fib (x) (if (<= x 2) 1 (+ (fib (- x 2))(fib (1- x)))))

It will then spit it back with whatever default formatting the lisp
printer uses for lists (there may also be an option for printing
functions in the printer).  The formatting may not be very nice, but if
the code is truely hairy it will be more understandable than it was.
You can use this sort of this to do things like substituting sub-trees
in your code.
(* quote marks are one of the few true bits of syntax)

4. It makes macros easier to understand since they act on trees.

All of the above describes benefits in automatic formatting, not
readability.
Some people find it readable, some don't.  I personally don't find it
very easy or very difficult.  There are a number of tricks to reading
it and writing it.
What I find most effective is to do this:

When reading this for example:
(defun fib (x)
           (if (<= x 2)
               1
               (+ (fib (- x 2))(fib (1- x)))))

The meaning of the first line is fairly simple, as are the next two.
The problem is the last line.  "fib" is obviously called recursively
twice and the results are supposed to be added, but are they?

The easiest way to find out is to delete all the closing parens at the
end with Emacs.  You then replace them one by one, the cursor will
highlight the opening paren as this happens.  You can then watch them
and check they go in the right places.  Once you've finished closing
the parens on the line you're on, the rest should match on the lines
above to each left-most paren.

Occasionally I do spend a minute or so staring at the parens and
wondering what's wrong with them though.  It's not perfect for my own
reading.

There are a few other reading advantages that come with abandoning
syntax though.  For example you don't have to worry where in the manual
it is described, there's no page 53.  I've always had this problem with
Perl, I know something's wrong with it, but I can't remember the place
in the manual that explains it.  For a lisp the manual/standard need
only describe forms and what they do.

(defun fib (x)
  (if (<= x 2)
      1
      (+ (fib (- x 2)) (fib (1- x)))))

Now consider the following transformations:

(defun fib (x)
  (if (<= x 2)
      (+ (fib (- x 2)) (fib (1- x)))
      1))

(defun fib (x)
  (+ (fib (- x 2)) (fib (1- x))))

I can perform both of those with one command (both three keystrokes in
this case) in Emacs, and without marking any extents at all.  How many
keys must you hit in your editor to perform the equivalents, and does
your editor understand enough of the syntax to figure out what the
extents of the if and else cases are without you explicitly marking
them?

(If this seems trivial, which it is in this case, consider that it can
work on any size and complexity of expression.)

Also, I consider the reformatted Lisp to be more readable than the ML,
but then, it's what I'm used to.

  (defun fib (x)
    (+ (if (<= x 2) 1 (fib (-x 2))) (fib (- x 1))))

But the fact that I have to think about that just makes me wish for
some easy to understand and maintain Lisp code. ;-)

-Peter

P.S. Which is not to say that the mental effort of dealing with
precedence rules is overwhelming--just that it's another cost that (to
me) is higher than the cost (if any) of dealing with parens (which
also come with lots of other benefits, as others in this thread have
pointed out.)

Compare:

(defun foo (some-number)
  (list (1- some-number)
        some-number
        (1+ some-number)))

with something like:

int* foo (int num) {int* temp = (int*)malloc(3 * sizeof(int); temp[0] =
num-1; temp[1] = num; temp[2] = num+1; return temp; }

Example 1 has 2 LOC.  Example 2 has 1 LOC.  Does this mean C 'wins' here?

At 2am I can understand MULTIPLE-VALUE-BIND better than MVB.  Verbosity is
good.

Difficult to explain really, but I get a visceral sense of 'stack pop' as I
type the closing parens.

This is probably due to Emacs highlighting each open-paren that my typed
close-paren balances.

What I am trying to say is that I get this feeling for the *whole* language,
whereas with C, i see curly braces, square brackets, periods,
hypen-greater-than, ampersand, etc, etc.

My thinking goes "erm-close-squre-bracket erm-close-paren erm-semicolon"
instead of "done-done-done"

Of course, it would be absurd to suggest that C code is less maintainable
because of all that _syntax_...  Wouldn't it?  :-)

Jamie

* This is a lie: sometimes I just stare at it for hours, because I am still
adjusting to the CL way of thinking.  But this happens less and less often.
If I compare with the transition from C++ to C# (the most recent addition, I
guess), I am winning *big time* with Common Lisp.

For example, nobody in their right mind would consider writing production
code in Whitespace or Brainf*** because they are clearly less readable and
maintainable, even though it is subjective. That is a clear-cut case, but
with Lisp vs ML it is not so simple, IMHO.

Additionally (pun intended), we were all taught operator precedences in
conventional mathematics at a very young age. It seems at best odd and at
worst stupid to disregard this.