During the first two weeks of February a small group of students of the Ecole d’Architecure Paris-Malaquais worked on an understanding of Mathematica. Wilfried reports from the workshop.
MathematicaR is software for mathematics that also visualises the results. It allows technical computation, numeric calculation and symbolic programming. During the workshop it was utilized as a design instrument solely to be instructed in mathematics. The students were expected to come up with a project employing Mathematica by the end of the workshop. No wonder that students indicated after the workshop finished that it had been a tough course. Certainly when besides the course you are interrupted by guest speakers telling about R. Koolhaas and Photoshop, masochism and A. Loos, about Hyperbodies, software and culture, or pure mathematics. The quality of the finished projects, as presented on the final day, is only of partial importance to consider the significance of the workshop. The actual value lies in alerting the relation between the architect and his software. Or maybe that is putting it too strong and is the real point the acknowledgement of such a relation.
By not completely understanding the objective of the workshop, a group of students explicated the goal of the workshop in their final presentation for all what these two weeks have been about. This is hard to define border between programming and designing in code. With a few lines of code one can draw thousands of lines, but those lines can also be defined by co-ordinates. That is what the latter group had done. In the end, on screen there is not too much of a difference, it is just more laborious. The fundamental difference is not in the amount of work but in the conceptual aspects ; the lines defined by co-ordinates remain a couple of lines, the lines produced by the algorithm are mechanically coupled together as being part of the same sequence thus having a formal defined underlying wholeness, a logic. That algorithms are not neutral was discovered by another group who developed dissimilar programming styles, without either of them having ever programmed; personality seems to be dominantly present in code.
The theoretical and practical implications of the topic of this workshop are rooted in the question to what extent architecture is being dictated by implicit and explicit conditions of the applied software. When software influences the eventual building or perhaps the style of an architect (and we are not even speaking about the 'artistic renderings' for clients here) then a technical knowledge to overcome the limitations of the software are a significant addition to the autonomy and eloquence of an architect. In other words, if the menu does not contain the function you are looking for, either you let it be or write the function you are looking for yourself. Here is the motivation to familiarise architecture students with programming principles. Not every architect will eventually use these, but at least that is a conscious decision. At the same time the discussion about open-source and 'design for hackability' comes round, since not all software allows for such user interventions.
Modern programming languages (one should say scripting languages) have made it relatively easy to write high-grade software without a lengthy study of memory allocation and other obscure programming details. In that sense MathematicaR is a good choice since mathematics has always been an intricate part of the architectural design process. Mathematics and architecture have a long shared tradition, a tradition that is both practical and cultural; think of classics such as Pythagorean fetishism such as the golden ratio, geometric modulators and mechanical symmetric transformations. One group of students took this history as inspiration for their project by taking the Fibonacci series as their point of departure. Formal languages have always been a part of architecture; computers mechanised and made this unnoticeable. By drawing this connection from behind the graphic user interface to the foreground these remain actual.
Like most final projects these proved to be impressive half products, platforms for actual applications, and as such this workshop comes to few answers, but raised many new questions. And that is already a lot.