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