Medieval cathedrals ought not to be thought of as merely primitive. Instead they are simple engineering systems, carried through to full elaboration. In this they are exemplars for all architecture and engineering.
Alexander's overall ideas or thesis seems aesthetical rather than logical, but that one phrase is amply suggestive. Think of it in the developmental biology way: forms take shape by successive alteration and refinement of previous ones.
• • •
What is falsework (a temporary supporting framework) during construction? – as in medieval cathedral building, using wood structures to then build stone structures. What is it in the sense of: how does it fit into the engineering design process?
It is not recursive (de/)composition, nor iterative development. It is almost like iteration – but it is entirely deliberate, determinate, known how it will go, what it is for.
The answer is, it is to make, or fake, a structure-preserving-transformation. A direct transform cannot be done, so a step is inserted.
• • •
With a gothic arch, the structure maintained by construction is ostensibly physical. An arch has integrity only when complete. You cannot build it just by successively putting its parts together – it collapses. The method of construction makes a wooden framework to support the pieces until complete, then it can be removed.
All construction is structure-preserving-transformation. There is the design of the intended product, but it is realised through a system of construction. Construction maintains some kind of structure from start to finish, even if it is just the abstract intent of the design.
Construction, in general, is a sequence of steps: each with the purpose of enabling the next to be taken, and the whole ending in the product.
• • •
(Logic is structure-preserving-transformation in the most abstract sense.)
• • •
So what do we do with software?
Test-driven development is not like construction: it indicates when parts or whole is complete, but that is not the same as leading to the end point; and it does not enable and hence set a sequence of steps to follow.
Stubbing-out functions, and generated code frameworks are like construction: they create intermediate forms. But these are limited, rudimentary, and/or not consistently usual practice.
Programming incrementally and visibly with small pieces, as is the style of Lisp and and maybe Smalltalk, also resembles construction. But it is ‘culture’ not implementation.
• • •
Software is, in a basic sense, in its most basic manual demands, just a string of bits. There is no need for construction like other mediums, because any bit and any part can be changed in any way at any time. This is a great merit of the medium, but it brings a disadvantage.
Normally, construction does another thing too. It imposes an organisation on our activity, on our control and verification of our intentions. We may not know that we need or benefit from this, but physical construction gave it anyway as a side-effect.
But with software we have lost this support. And software, in its higher senses, is not just a structureless string of bits. It is for reflecting objective algorithms and our intentions, both of which are highly structured.
• • •
Physical building-blocks constrain both the final form and the steps to reach it. But in software, the building-blocks only constrain the final form.
You can only make certain things with functions for + - * / (or more precisely, you can only make them in certain ways), but we build by editing chars in text files. It is like designing a house of bricks but building it by moving atoms.
Why is constraint valuable? Because a set of building-blocks constitutes a logical framework, and that enables understanding – it is understanding. We can understand finished algorithms, but in construction we are disordered and in darkness; we have no logical framework and hence no understanding.
• • •
What we have is the popular vague notion of ‘iterative and incremental’, what we do not have is a clear, defined, detailed set of ‘mechanisms’ at the real programming level. We could do better here. (This is related to but distinct from refactoring. That changes representation while maintaining function. This is about partly changing function while partly maintaining it.) Software development would benefit from a controlled way of moving from state to state: an appropriate set of structure-preserving-transformations.
Background: