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.