>
> ok, I've seen common music talked about for a long time, but never
> tried it b/c it always seemed "wizard-like," and yet your code looks,
> errm, easy? elegant is a better word...it's pretty and
> understandable. is all common music code like this? supercollider
> always confused me because it looked too much like code, but this cm
> stuff looks not like code, but like words, and that is something I
> feel I can learn.
>
>
The chief thing here, I think, is names for variables. The example code here
uses good and clear names for variables (that the programmer can pick
himself) and so it becomes easy to read. I would say that this is more up to
the individual programmer than to the system but sadly some systems have a
culture around them of trying to put everything as compactly as possible,
partially to cut down on the typing needed but probably also to make the
programmer look like the "wizard" you mention.
Good Lisp looks narrative and indeed obvious, like everyone could easily do
it, like you could simply re-state the problem in detail and expect that act
in itself to solve it for you (which is true, actually, but it will take
some experience to get to that stage). It's sad that so much example code is
seemingly intended to be be a example of how clever the programmer is
instead of a example of a strategy to solve problems. Worst there, IMHO, is
Perl where many examples look to me like somebody trying to pick a strong
password by bashing the keyboard yet some Perl code exists that can be
understood quite easily.
My personal favourite property for example code for creative systems is for
it to invite you to change parts to see how that will affect the result. For
me that factor will make or break my experience in the first 5 hours; good
manuals are important but if I don't get that experience then I will never
get round to the manual. This too differs per person; some people prefer to
first read a whole manual.
Yours,
Kas.
Received on Mon Jan 25 2010 - 23:22:20 GMT