RE: ++CD-ROM drive

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jonathan" == Jonathan Shore <jshore@example.com> writes:

    Jonathan> lisp readable (if you wrote it)

Why, thanks!  I didn't know I had fans out there....

Actually, I find Lisp readable when others write it, as much so as my
own programs.  I used to think not, but then I realized that (a) I
wasn't a very good Lisp programmer, and (b) there are more correct and
elegant ways to write Lisp than one would believe.  And it's not just
a matter of whether the curly braces line up under the "if" or are
indented two spaces....

    Jonathan> You can often learn a lot about a language just by
    Jonathan> looking at what people in the community spend most of
    Jonathan> their time discussing [...].  GC is a fascinating topic

Ah, so that's what you were getting at.  Sorry, but the myth that GC
is inefficient is evergreen ... it's a natural mis-take.

    Jonathan> but one would have to wonder whether lisp's dependence
    Jonathan> on prolific garbage generation is its achilles heel.

`setcdr' is your friend ;-)

People look at Lisp programs and go, oh God that's a lot of CPU for
the algorithm.  But what's generally happening is a combination of two
things.  Side-effect-less programming, which of course involves lots
of consing and therefore gc.  The second is imperative programming
style.

Tail recursive implementations are often more time- and heap-efficient
than the equivalent loop in Lisp, even if expressed with the mapcar
primitive.  And there's a more subtle issue, that many algorithms that
C uses pointers for cannot be easily converted to use mapcar, but a
compactly, efficiently, and elegantly expressed with a tail recursion
on sublists.  (Not to mention that maplist/mapcdr is vastly
underused.)

Side-effect-less programming is much more of a tradeoff, between
safety and efficiency.

I think the fact that people discuss garbage collection is much less
of an indication of fundamental problems with Lisp (or other gc
environments such as Java (burp), Perl (cough), and Python (choke))
than you might think.  First, most implementations of these
environments use really bad gc -- the three mentioned above are even
worse than that of Emacs Lisp, which is far and away the most-used
Lisp GC (although librep and guile will probably start to come close).
Second, it's very much an unsolved problem in theory even though
practical collectors with good performance are now available, and
fascinating in itself.  It's not surprising that programmers would
latch on to it.

Sorta like the I18N thread, were we spent MB bitching about XIM when
what's really needed is an all out effort to translate message
catalogs.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."