Subject: Re: How fast can lisp go?
From: Erik Naggum <>
Date: 2000/07/13
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.

  If this is not what you expected, please alter your expectations.