Subject: Re: How fast can lisp go?
From: Erik Naggum <erik@naggum.net>
Date: 2000/07/13
Newsgroups: comp.lang.lisp
Message-ID: <3172468985275952@naggum.net>
* Martin Cracauer
| That only applies when the playback may be some time behind the
| availability of the unfiltered stream of video or audio.
So you want hardware solutions. Using software will out of
necessity take non-zero time for non-zero efforts.
| It doesn't work that way when you produce contents that must be
| synchronized with real events, i.e. audio for computer games can't
| build buffers, the action of the player is supposed to be spiced
| with a BOOM or whatever immediately.
I'm so glad we're in this negative mood where the purpose of this
whole crappy exercise is to find ways Lisp will fail. Is it any
wonder Lisp has a bad reputation? Even Lispers you'd think would
have an interest in finding ways to solve the goddamn problems waste
their time finding cases where they think it won't work. I have to
wonder: Are you this bad an engineer?
| In practice, C++ programs tend to do a lot of unneeded copying, but I
| have to rate all of them into pilot errors, where programms use
| objects in a way that copies them, while a copy-free mechanism would
| be available to the programmer.
And now, apologia for C++!? Christ. C++'s lack of GC has one very
important consequence: It has to has to have an ownership protocol
for its allocated objects. Ownership protocols are very interesting
because the are extremely complex. Since the likelihood that they
could be mastered by the kind of people who choose C++ is so close
to zero only number theorists would find anything in that space, the
easy way out is to create a new object with known owners and let the
owner of the original take care of it. Writing C++ is bad enough,
but copy-free C++ is a lot harder than consing-free Lisp.
#:Erik
--
If this is not what you expected, please alter your expectations.