On Thu, 13 Sep 2007, Chris McCormick wrote:
For example if someone is explaining about what externals are. That is a good and every-day intuitive use of the word "class" for normal people as well as being acceptable to us abnormal computer scientists (as Matju pointed out already).
I wouldn't quite describe myself as a computer scientist. I'm nowadays somewhat at odds with the computer scientist mentality. Neither could you really say that I'm not an artist: even though I only work on other people's projects, I still end up making artistic decisions.
Pd tends to attract people from the artist-programmer continuum. I don't think that it's useful to rely on stereotyping those people into two opposing clusters... People in the middle of the spectrum shouldn't have to decide whether they're an artist or a programmer.
When teaching pd, a more important "fault line" when trying to compartmentalise information and vocabulary, is whether a concept or word is of exclusive usefulness to a certain activity (e.g. such as programming C externals). If you teach how to patch, you don't want to teach proxy-inlets vs float-inlets, because they don't appear at all at the level of patching; likewise, if you teach how to write C externals, you don't want to be explaining t_bindlist because that concept is only useful in the internals of pd. (well, actually, some externals *could* mess with that, but you're not supposed to). However, distinctions between t_pd, t_gobj, t_scalar and t_object can be useful in explaining the big picture of how pd works, because each of them corresponds to a specific concept that you encounter in pd as "just a user". Some kinds of implementation-hiding are pointless...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada