6. dubna 2006, 20:06:09, Bill: >> What are your plans for the future of CLM?
BS> Gah! I try not to look ahead at all. I no longer enjoy working on the BS> Common Lisp version -- the various FFI's are horrible, and debugging BS> is impossible. Whenever I'm goofing around with it, I use Snd and BS> Guile/Scheme, even for with-sound stuff (it's only a factor of 2 or pi BS> or something-like-that slower than the compiled CL version, and BS> I don't think fast anymore anyway). I'll certainly keep the CL version BS> going even if Fernando and Chris decide to use something else BS> for the introductory classes here. Rick suggested making the current BS> CL-CLM a pure lisp program, but that slows it down by a factor of BS> 30 to 50; adding all the type declarations (much worse in CL than BS> in C because every damned expression has to be wrapped in "the") Interesting. I'm just CL newbie, sometimes I read discussions on newsgroups about CL optimizations, where different people claim one can also use CL for fast code. Problem with unreadable code with declarations is often mentioned as one that is possible to overcome by some simple macros. Your complaints sort of support image of CL better suited for high-level tasks here... BS> makes the code unreadable, so why use Lisp at all at that point? BS> This sounds more negative than I mean for it to -- no big changes BS> are in the works, as far as I can plan ahead. BS> If it had worked out as I originally hoped it would, composers would BS> be developing complicated instruments using new synthesis methods, BS> but the energy now seems to be back in what I'd call music concrete! BS> Maybe it's a big circle... BS> _______________________________________________ BS> Cmdist mailing list BS> Cmdist@ccrma.stanford.edu BS> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist -- Frantisek Stafek. _______________________________________________ Cmdist mailing list Cmdist@ccrma.stanford.edu http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
