From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Common LISP: The Next Generation
Date: 1996/08/29
Message-ID: <3050338193286393@arcana.naggum.no>#1/1
X-Deja-AN: 178473570
sender: erik@arcana.naggum.no
references: <sjpw4hbzvo.fsf@alfresco.usask.ca> <4vp93n$fpk@snotra.harlequin.co.uk> <3050214712631064@arcana.naggum.no> <504oa0$1b2@zeppelin.convex.com>
organization: Naggum Software; +47 2295 0313; http://www.naggum.no
newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme


[David Boles]

|   Not at all, it [the "hello, world" test] really just measures how wide
|   a range of programming problems the language is usable for.

my argument was that the "hello, world" test only shows the ability of a
language/compiler/operating-system combination to perform well _together_,
while it does _not_ show any inherent values or qualities of the language,
such as it is interpreted to do.  in doing this under Unix, it shows that
the operating-system/language interface is such that this can be made
extremely efficiently.  this is not particularly surprising, given the
origins of Unix and C.  the exact same program compiled with the Sargasso C
compiler under TOPS-20 was horrendously inefficient and much larger than
any user programs I have seen.  the unintelligent conclusion people draw is
that because Unix and C are very tightly coupled, they can draw conclusions
about one of the tightly coupled parts.

C and Unix share an "assumption space" that is so closed that any other
assumptions have a very high penalty while they retain minimal overhead.
in operating systems designed for use by multiple languages, C is no better
than, e.g., Fortran or PL/1, in fact it may be much worse, because the
assumptions made in C are so difficult to spot that most programmers don't
even realize they are there.

|   Sorry, you're not understanding the test.

really?  let's try again.

if you type "hello, world" into a Lisp system's read-eval-print loop, it
will type "hello, world" back at you.  if you write a one-line function to
do the same and invoke it, it will have much lower cost than C could ever
have in _its_ optimal environment.  if you insist on a model that is known
to favor C and Unix, you should be a little careful with your conclusions
about other languages and environments.  I repeat: all the test shows is
that Unix and C are very tightly coupled and very efficient for this model
of executing programs.  we knew that before anybody wrote the "test".  thus
is has no probative value whatsoever if used to compare _languages_.

|   These costs restrict the domain over which your language can generate
|   useful solutions for.  A language such as C imposes very minimal costs,
|   making it useful (in a runtime sense) across a much wider range of
|   applications.  While Lisp's necessarily have a higher runtime cost than
|   a primitive language such as C, it is unclear to me that these costs
|   have to be as large as they currently are.  With decent engineering,
|   Lisp's could be *much* more widely applicable.  It's sad that the lack
|   of a reasonable I/O model and typical Lisp system's poor executable
|   generation are such a drag on the language.

on the other hand, a Lisp programmer on _any_ operating system would balk
at the need to fork off a whole new process to do something as simple as
printing a line to the terminal!  the waste of system resources is
incredible for so little action!

it's pathetic how the C/Unix camp will insist upon loading the dice in any
competition among languages, and on top of it, they do not even recognize
that they have made assumptions that automatically make them win.  I'll
scratch this up to incredible well-done marketing, just like large segments
of the population will insist that Intel and Microsoft are the only viable
suppliers of basic computing power.  they are wrong, too.

#\Erik
-- 
main () { printf ("%d\n", sin ("foo")); }