Homeostatic patterns waves vs. particles self-stabilizing patters It all depends on how you need to see something (If you need to see a wave, you see a wave,
Re-factoring ... ? (The fact that everything in Smalltalk (all the way down) allows for extreme flexibility like refining True and False (you will crash quickly ;) Ability to start with test code / usage and "run it" let it break, and then write the code via the "debugger". The ability to solve problems before you understand what they are. Writing interfaces as a means of understanding the shape of a system.
Decomposition: The act of figuring out the modularity of a system Decomposition --> Dependency
Frameworks vs. Scaffolding
Architecture and the relation to the software (Autocad and regular curves... Maya and blob architecture) Gehry and CATIA (software from the Aerospace / Aeronautics Industry)
% GRAFT: endurance, library, constellations > For Fuller it was a great enigma why one form > should endure while another does not, especially > because he disclaimed both the term "bodies" and > the concept of "building blocks" that lead one > to believe that it is obvious that a form will > be retained. Today every physicist affirms that > the concept of "building blocks of material" has > been rejected once and for all. > [@[p.9]krausse:2001:fuller]
% GRAFT: library, constellations > Fuller's little rubber hoses, which he introduced > into his model as the nodal connectors for the > rods, are a ridiculous detail from a material > point of view, but from a conceptual point of > view they are a firstrate tool. Flexible nodes, > which Fuller stipulated as early as 1932, make it > possible to create a model that enables the > formation of rigid "bodies" on the basis of > moveable constellations and that thinks of > stabilization as a self-stabilizing pattern. > Fuller attributes the retained form to a > recurring pattern; he defines structure as a > "locally regenerative pattern integrity." > [@[p.9]krausse:2001:fuller]
The well-publicized programming methodology of top-down, structured design produces systems that are organized as trees. Following this methodology, a system is designed as a predetermined combination of parts that have been carefully specified to be combined as determined. Each of the parts is itself designed separately by this same process. The methodology is flawed: if a system is to be robust it must have more generality than is needed for the particular application. The means for combining the parts must allow for after-the-fact changes in the design plan as bugs are discovered and as requirements change. It must be easy to substitute parts for one another and to vary the arrangement by which the parts are combined. This is necessary so that small changes in the problem to solved can be effected by making small changes in the design.
Procedural abstractions are a source of power in creating stratified designs — we build structures by composing procedures, we abstract common patterns of usage, and we build upon this framework. But for some problems the appropriate means of combination may be awkward to express as compositions of procedures; towers of abstractions may not suffice
Each of these programming paradigms is legitimate, but no single paradigm is sufficient — large systems typically have some parts that are naturally described using one style and other parts that are more naturally expressed in other ways.
Part of the wonder of computation is that we have the freedom to change the framework by which the descriptions of processes are combined. If we can precisely describe a system in any well-defined notation, then we can build an interpreter to execute programs expressed in the new notation, or we can build a compiler to translated programs expressed in the new notation into and other programming language.
