Arch 486: Algorithmic Geometry in Architectural Design
aka "Computer Graphics Programming for Design" Spring, 2013 Brian Johnson
Commercial software designers have a difficult problem. They attempt to provide customers with the data elements and logic structures through which problems in some domain can be solved. The difficulty with this is that while they may know a lot about people and a lot about the domain, they do not know the particular problem you are trying to solve.
As a consequence, their solution, no matter how elegant, cheap, or popular, won't ever quite fit the problem at hand. Through skill with the software, or through an investment of time, we can learn to get quite close to what we need, but it is sometimes a fragile or time-consuming proximity.
Those who write their own software can construct a much tighter fit of solution to problem. Often, they can embed the logic of the conceptual solution directly into the software. This limits the utility of the software outside of the particular problem, while it may greatly enhance the ability of the developer to address the current problem. If you're doing commercial development, that's not good. If you're a carpenter using a jig to guide the production of unique parts for an assembly, it is routine. If you are a designer crafting a parametric solution to a design condition, it is increasingly common. If you're in this class, that's what we want to explore.
Bricolage [...] is a term used in several disciplines, among them the visual arts and literature, to refer to the construction or creation of a work from a diverse range of things which happen to be available, or a work created by such a process. The term is borrowed from the French word bricolage, from the verb bricoler – the core meaning in French being, "fiddle, tinker" and, by extension, "make creative and resourceful use of whatever materials are at hand (regardless of their original purpose)"; in contemporary French the word is the equivalent of the English do it yourself... — Wikipedia.[emphasis added]
The craft of software production does not start with smelting copper and grinding iron ore any more often than (most) carpenters grow their own trees. We necessarily use tools of mind, process and data that others have created, but we organize them to solve our unique problems. Sometimes those are ready-made parts, sometimes they look more like raw material. Assembling parts produced by others can be as hard as constructing our own parts "from scratch" but it can also save us time.
In this course we will explore computer programming, from scratch as well as through bricolage, as a means of solving particular problems, breaking free of constraints. To do this, we will have to think creatively, and learn to express ourselves clearly using a programming language. Where this is a text-based language (such as Processing), visual designers sometimes struggle with abstractions, but programmers have long used diagrams to explain and understand their craft, and new "visual programming" languages (such as Grasshopper) have emerged. We'll touch on both.