Building blocks? Bucky Ball 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, http://activearchives.org/wiki/Lisp:_A_Language_for_Stratified_Design 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) http://pipelines.local/images/Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg dependency? ---- % 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. *Source: http://pipelines.local/bibliotecha/AIM-986-LISPALanguageForStratifiedDesign.pdf Modularity as a saver for programmer time. Study on relationship between the structure of organisations / and the structure of the code they produce. Modularity and Division of labour in programming % GRAFT: distribution of work, separation, TODO Rule of Modularity -> Rule of Separation Internal coherence vs. external legibility / communicability APIs are counter-revolutionary (Amazon's API -- there's only a single provider) You really want protocols Twitter API / APIKey Taina Bucher Objects of Intense Feeling: The Case of the Twitter API http://computationalculture.net/article/objects-of-intense-feeling-the-case-of-the-twitter-api http://pipelines.local/bibliotecha/CC_Objects_of_intense_feeling_The_case_of_the_twitter_API_Bucher.pdf (How the shifting API can be used tactically to lock in developers -- already the opposite of a standard that is about stability that allows multiple implementations) APIKey as epitome of singularity (legal agreement) Protocols are all about Independent implementations Is search an un-decentralizable problem? (Gopher -- decentralized search?) https://en.wikipedia.org/wiki/Gopher_%28protocol%29 https://en.wikipedia.org/wiki/Wide_area_information_server#WAIS_and_Gopher Refactoring: Relation of inside to outside. (relation to product design)