#dataflow programming

I have been working with Pd as the audio engine for my Android sequencer app.  Learning about the language, I find my path to understanding it is a mixed route of functional learning mixed with theory.  This blended approach to gain experience with it is the result of my passive-aggressive tendencies which produce a turbulent mix of theory and practical application.  In my youth I was of the "learn the theory then start creating" school of thought, but the gradual slide into over-saturation of information has made me at times impatient and aggressive, seeking a quick payoff for a nominal investment of time.

How this relates to Pd is that instinctively I see it as an array of functionality more than a language, and not all of the constructs that exist in the visual programming environment are at the forefront of my decisions.  A prime example is that I am at the point where I have an idea of the sort of features that I require to accomplish the tasks in my next sprint, but to sketch this out I find myself wanting to go to a chart or mindmap, something at a macro level to define the flow and subsystem requirements.  Pd though not an object-oriented programming language has methods to service this.  I can create boxes and comments around elements, and I can define hierarchical patches simply by adding the pd statement inside of an object and giving the sub-patch a name.