Rob; Your comments underscore the need to create a ChucK _reference manual_, even
before creating a _programmers guide_ . By definition, most ChucK users are already programmers for whom explanations of object oriented programming, inheritance and type casting is superfluous. On the other hand, being able to quickly learn the syntax for oo, inheritance and type casting is important.
I respectfully disagree. I think there is a significant audience for ChucK that knows about music, knows (something) about sound yet has never used text as a interface to controlling these and wants to try it's hand at that. Not everybody has the luxury of attending classes at Princeton or Stanford and yet these people still need a place to get started. There is no conflict here though, as the current initiative covers both introductory tutorials and a attempt at creating a exhaustive reference to all object types, methods, operations and keywords.
Give me a decent ChucK reference manual (i.e. what the heck does the reserved "pure" keyword do?), and I'll be happy to write a few tutorials for beginners.
Great! I'm in the process of writing these references and will include "pure". I'm also looking over the tutorials that are up already as I found some bits in there that I have serious doubts about. You can start adding tutorials on any topic you find lacking whenever you have the time and inclination. "pure", to explain from memory, is a keyword to mark member functions for a mother class that is just meant to be extended and not meant to be instantiated on it's own (hence this function wouldn't be called). Ge once explained that he mainly wanted to be able to write "pure fun", as in (my example) "pure fun void cheerfulAbyss()". I can't -off hand- think of a occasion where it will actually affect anything. Still, it will be documented. As will the "--poop" commandline flag, which is about as useful and as frequently used, but it exists and so it needs to be in there. I can think of even more obscure features, but I'll have to re-find the exact syntax. These things aren't either/or matters, in fact we found that some files needed to be split up because only a single user can work on a file at a time so working on more things at the same time will help make the most of the hands and eyes that we have. Yours, Kas.