Please Note: This website is currently being prepared for Spring quarter, 2020, so there may be broken links and inconsistent content as this preparation continues. These changes will be complete before Spring quarter begins at the end of March, 2020.

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 approximation.

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]


A kludge ... is a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.

An ill-assorted collection of poorly-matching parts, forming a distressing whole' ...; esp. in Computing, a machine, system, or program that has been improvised or 'bodged' together; a hastily improvised and poorly thought-out solution to a fault or 'bug'. — Wikipedia.

You may note much resemblance between the pejorative kludge and the more respectable bricolage. Both involve working with materials at hand to address a current problem. The difference, if there is one, might exist in the level of craft practiced by the individual doing the assembly&emdash;the care taken to select appropriate pieces and the fit them together well. Scripting is like that: Good scripts find use for years, while bad scripts are discarded (usually in frustration) almost as soon as they're made.

The craft of scripting 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 "scripting", a form of computer programming characterized by assembling pre-existing parts into a whole. We will work from scratch as well as through bricolage, as a means of solving particular problems, breaking free of constraints. We will have to think creatively, and learn to express ourselves clearly using a programming language (or two). Where this is a text-based language (such as python), 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.