SPRING 2020: This quarter we're all in for a new experience. Due to the coronavirus outbreak, this class is being offered online for the very first time. Further, this is the first time I have offered any class that way. While I have developed a suite of online tools that I think will be of use to us, including this website, I see learning as a very personal experience and really depend on being able to look my students in the eye, during both lecture and tutoring. I am acutely aware that many mistakes are due to executing the correct action in the wrong context; asking what you "did" elicits a description of the action, while watching you do it allows me to see the context. That's going to be harder to do but I think we can manage if we communicate frequently about what is working and what is not.
Data + Algorithm + Craft = Problem Solution
All computer programs combine data (facts, such as numbers, letters, etc.) with algorithms (computational sequences applied to the data) to solve problems. They are authored by someone who understands the problem, thinks about the available data, and investigates available algorithms to find a viable solution.
Commercial software designers have a difficult problem. They attempt to provide customers with the data and algorithms through which problems in some domain can be solved. The difficulty with this is that while they may know a lot about people in general 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 all problems encountered. 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—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 Role of Craft
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.
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.
Often the difference between a weak and an elegant solution lies not in the data or algorithm, but in the way the parts are assembled. The many steps in a complex algorithm may be clumped into logical parts, and the parts described with (non-functional) notes. The data can be carefully named and organized, and limitations in the approach may be described, or not. These things characterize the craft of coding, but they don't change how, or how well, a particular bit of code works. They change how well a subsequent user can understand, use, and change it.