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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
