[PD] Good PD programming practice?

[Mathieu Bouchard]

On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:

> This leads me to an interesting paradox about programming that has
> stuck with me since 1993 when I was taking Computer Science in
> college. Some famous computer scientist (I forget exactly who) said
> "you have to write the program in order to know how to write the
> program." I have found that this actually makes a lot of sense, so
> when programming with Pd, first I try to whip out a working prototype,
> then start again from scratch and build it the way it should be done,
> with things nicely modularized into objects (abstractions generally).

In the "Extreme Programming" (X.P.) methodology, this is considered
perfectly normal, and is called a "spike". Then you have the choice of
rewriting it or modifying it. In X.P. there is an emphasis on modifying
code. It is common sense that doing things that way leads to spaghetti
code. However, X.P. is advocating aggressive redesign as part of the
process of modification of code, and is encouraging use of automated test
systems as a protection net (you see, reluctancy to do aggressive
redesign is usually motivated by avoidance of new bugs).

> There are a massive amount of books about programming techniques for
> procedural and object oriented languages, but there is basically
> nothing about programming techniques for patcher languages, even
> though they have been around for 20+ years and are decently widespread
> in use.

Among other things, I think it may be because patcher languages (aka
visual dataflow languages) are different enough from each other that
techniques that may apply to Max/Pd aren't reusable elsewhere, and so
on. Also, it's normally a subsegment of the programmer population that
seems the most concerned/experienced with complexity management, but most
users of those programming environments are nonprogrammers.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju