Dear Ralf Mattes, On 29 Dec 2011, at 11:52, [email protected] wrote: > To give up all these nice libraries and be locked into a stadalone scheme > seems a high price to pay (and, most important for me: hving to give up > decades uf muscular memory (emacs as an editor) is the highest price I'd have > to pay with Grace).
I think there is some misunderstanding concerning a main goal of Rick's CM development. As I see it, a very important goal for the CM development is to have a composition system that can be used for teaching, most probably including undergraduates that do not really aim to become programmers. For such an audience, a minimal system with an easy to use text editor and a programming language with a syntax reminding standard math notation is clearly a big plus. I can confirm from my own teaching experience that such students hate Emacs (understandably, I must say, they simply do not need its power and are confused by its old-fashoined interface). Grace is much preferred by such students. Now, the downside is of course that more experienced users may feel restricted. For example, they may miss support for certain libraries, as you just pointed out. You may also miss some feature an earlier CM version had (at least I always have such difficulties, e.g., I cannot find a music representation data structure any more), and your legacy CM developments may not work anymore, because for teaching as a main goal CM does not need backwards compatibility either (see the Arno discussion yesterday -- by contrast PWGL still can load decade-old patches, as long as all required libraries are there). Anyway, I think that CM has similar pedagogic goals as Racket (http://racket-lang.org, previously PLT Scheme), a programming language (Scheme dialect) and development system designed primarily from a teaching perspective. There is research that shows student who first learnt PLT Scheme for a year and then learn Java for another year are better programmers than those students who learnt Java instead for 2 years, because many concepts are more easily understood in PLT Scheme. I assume the same may be true for students who first learnt CM and then moved on to SuperCollider, instead of learning SC from the beginning. A more advanced user may prefer SC (or a Common Lisp based system with Emacs & Slime) due to their greater flexibility/expressiveness/libraries, but CM may have considerably helped them to get there, Just my point of view... Best wishes, Torsten PS: I would have liked to see some CM integrated in Racket. For example, see how Racket allows to do graphics directly in the language (http://docs.racket-lang.org/quick/) -- you can even have pictures as part of the source code. Imagine doing that with sounds :) On 29 Dec 2011, at 11:52, [email protected] wrote: > On Wed, Dec 28, 2011 at 05:47:55PM -0600, Heinrich Taube wrote: >> this is slime nonsense, not cm. now i suddenly remember why i moved to >> c++/scheme! > > This is not "nonesense" - this is a valid error message that reports > that the versions of slime (emacs lisp side) and swank (common lisp) > don't agree. Since slime and swank's network protocol do change every > once in a while that's a warning to be taken serious. Ignoring it is > asking for trouble .... So > >>> Can't locate module: SWANK-IO-PACKAGE::SWANK-REPL >>> [Condition of type SIMPLE-ERROR]") > > is kind of expected, isn't it :-) > I hope this is _not_ the reason you moved to a insular > scheme/C++ solution. Lisp got so easy to install with the > emacs package system and quicklisp. > You need xml integration: > > (ql:system-apropos "xml") > > for a list of 32 ready-to-install systems. > OSC? > > (ql:system-apropos "osc") > > and then: > > (ql:quickload "osc") > > same with screamer ... To give up all thesde nice libraries and be > locked into a stadalone scheme seems a high price to pay (and, most > important for me: hving to give up decades uf muscular memory (emacs > as an editor) is the highest price I'd have to pay with Grace). > > > Cheers, Ralf Mattes > > _______________________________________________ > Cmdist mailing list > [email protected] > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist _______________________________________________ Cmdist mailing list [email protected] http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
