RE: ++CD-ROM drive

["Jonathan Shore" <jshore@example.com>]

> >>>>> "Jonathan" == Jonathan Shore <jshore@example.com> writes:
>
>     >> From: Stephen J. Turnbull [mailto:turnbull@example.com]
>
>     >> Lisp.
>
>     Jonathan> Hmm, he did mention *efficient* here - maybe lisp
>     Jonathan> qualifies by another standard.
>
> "Efficient" is relative.  All procedural languages suck compared to
> listing up all possible inputs in a hash table.
> As for "efficient as C or C++", well, I'll leave that for another
> bridge....  But don't believe that all FUD originates in Redmond.
> Plenty comes out of Murray Hill, too.  For starters:

No fan of C++ myself - definitely better stuff out there in terms of !/$
even considering efficiency.  Unless I missed something in the last 5 years
since I was involved with lisp, never ran across a lisp implementation I
would use for device drivers or the like (ok lisp machines aside).

> http://www.ai.mit.edu/docs/articles/good-news/good-news.html
>
> Yeah, it's ten years old.  But if Common Lisp implementations were
> beating C back then, there's no reason why they won't still beat it.
>
>     Jonathan> Last time I checked the lisp/scheme groups they were
>     Jonathan> still talking about GC algorithms (and that after 10+
>     Jonathan> years).  Interesting topic but it gives you an idea of
>     Jonathan> some of the problems with the language.
>
> [Speaking of Java, Perl, and Python ....]
>
> Get eddicated: http://www.jwz.org/doc/gc.html
>

Big problem is the volume of cons cells which typical lisp programs generate
(and dispose of).  Not saying that GC is bad.  Know that you can avoid this
and there are some great GC and blocking hacks ...

JS