Comprehending Algorithmic Design

Abstract

Algorithmic Design (AD) allows for the creation of form through algorithms. Its inherent flexibility encourages the exploration of a wider design space, the automation of design tasks and design optimization, considerably reducing project costs and environmental impact. Nevertheless, current AD uses representation methods that radically differ from those used in architectural practice, creating a mismatch that is further exacerbated by the inadequacy of current programming environments. This creates a barrier to the adoption of AD, demotivating architects from its use.

We propose to address this problem by coupling AD with adequate representation methods for designing complex architectural projects. To this end, we explore three essential concepts: storytelling, interactive evaluation, and reactivity. These concepts can be both complementary and mutually exclusive, which means compromises must be made to accommodate them all. We outline a strategy for their integration with the AD workflow, highlighting the advantages and disadvantages of each one, and pinpointing their intersection. Finally, we evaluate the proposed strategy using computational notebooks as programming environments.

1 Introduction

Algorithmic Design (AD) defines the creation of designs through algorithmic descriptions, i.e., computer programs with instructions for the machine to perform [8]. Despite its numerous advantages, there is a comprehension barrier demotivating many architects from its use. The goal of this research is to make AD a more accessible design process, allowing the industry to benefit from AD’s potential to combine design creativity and design optimization. In order to do so, we will dive into program comprehension research, identifying strategies that aid the construction and comprehension of AD programs.

1.1 Algorithmic Design

AD allows the designer to delegate repetitive tasks to the computer, accelerating the production process and reducing human errors [8]. It also supports rapid change with little effort, providing considerable cost savings to the industry [51].

Another important advantage is AD’s influence on performance-based design [20], which is gaining ever more emphasis with the growth of climate change awareness and cost-reduction needs. While the incorporation of analysis data in early design stages alone already helps architects achieve better performing solutions, the connection between AD and simulation tools opens the door to much faster optimization processes [34].

Despite the numerous advantages AD presents to the process of architectural creation, it relies on algorithms, written using programming languages. This representation method radically differs from the ones traditionally used in design and is therefore difficult to use by professionals of creative fields [32].

Visual programming languages present a friendlier approach to AD that simplifies the learning process and offers more adequate graphical features for the task at hand. However, they also lack scalability [7], meaning that as programs grow in complexity they become hard to understand and navigate [9, 11], hindering their use in large-scale projects [28].

Additionally, and in either case, AD programs (visual or textual) frequently turn up to be the unstructured product of successive copy&paste of program elements, which result from the experimentation process that characterizes design thinking [51]. Hence, programming architects find it difficult to understand AD programs that represent complex designs, particularly those developed by others [30] or by themselves in the past. This research targets the development of AD programs that describe complex 3D models, hence we focus on text-based AD.

1.2 Integrated Development Environments

Much of the programming struggle mentioned above can be alleviated with an Integrated Development Environment (IDE): a computer application that aims at facilitating the programming task. Sadly, existing IDEs are tailored for traditional software development processes. As such, architects find it hard to use them as design tools.

We propose to make AD more akin to the traditional architectural practice by integrating more adequate methods of developing and maintaining algorithmic representations of complex architectural projects in current IDEs. To that end, we explore two ideas that facilitate program comprehension: (1) documentation - the task of explaining a project to facilitate its comprehension; and (2) liveliness - the ability to live test the program as it is being developed or modified to facilitate comprehension of the impact of changes.

Documentation and liveliness are two very broad concepts, which we further subdivide to better suit architectural design. More specifically, we explore: (i) storytelling, (ii) interactive evaluation, and (iii) reactivity. These three concepts contribute to the comprehension of AD programs in very different ways and they can be both complementary and mutually exclusive. In this article, we outline a strategy for their integration with the AD workflow, which we evaluate using computational notebooks as the base IDE for the experiments.

2 Related Work

The difficult task of understanding computer programs is far from being limited to the architectural community. Research in the field of program comprehension has long aimed at modeling a cognitive theory on how programs are understood [48]. The following sections present some of the theories developed over time.

2.1 Program Comprehension

This section addresses two main branches of program comprehension: the understanding of computer programs through explanatory human-readable text and the use of graphical representations to illustrate programs’ structure and behavior.

Program Documentation. In 1984, Donald Knuth proposed Literate Programming [25], a system that encourages users to build programs as a structured web of ideas, that is, by creating program parts and stating the relationships between them as they go, in whatever order they find best for the comprehension of the work. The problem with this solution is the perceived lack of efficiency: having to explain, in advance, the intended program, delays the programming task. Documentation is generally agreed to be one of the most useful, yet dreadfully tiresome parts of the job, and consequently one of the most avoided [5].

Naturally, given its importance for software maintenance, automatic documentation tools have also been developed [16]. Machine learning techniques, such as neural networks, in particular, are currently achieving considerable success in the automation of documentation [21, 36]. However, for the specific case of architecture, traditional program documentation fails to ensure program comprehension, as it is geared to the production of hyperlinked texts. In AD programs, documenting complex geometry requires not textual explanations, but rather the equivalent sketch translation.

Bret Victor [50] argued that, when designing, artists think visually. However, when writing code, they must think linguistically. Not only is this translation process hard on design ideas, but most often it is also impossible to convey the entirety of artistic meaning with words. He also states that just as we created writing to make thoughts visible (a user interface for reason), or mathematical notation to make mathematical structures visible (a user interface for algebra), we must also develop IDEs that can make our designs visible [49] (Fig. 1).

Fig. 1.

Bret Victor’s Inventing on Principle: from a simple code editor (left) to an enhanced IDE (right) providing an “immediate connection" to what is being created (adapted from [49]).

Program Visualization. This specific branch of program comprehension research focuses on the use of graphical systems to facilitate the comprehension of programs. It began to have some expression in the ’60s to help programmers deal with the complexity of (what was then considered) modern software [2]. The proposals included the use of various diagrammatic techniques to explain programs [18, 22, 33] (examples in Fig. 2).

As technology evolved, so did the aspirations of the scientific community [12] and the availability of better displays, colors, and, later on, 3D representations, motivated a growing emphasis on animations over static representations of programs. Early on, Brown developed several systems that offered programmers dynamic displays of the program’s fundamental operations [6].

Fig. 2.

A - Goldstine and von Neumann’s flow-diagram [18]; B - Jackson diagram for a process payment program [22]; C - Nassi-Shneiderman diagram for the factorial function [33].

Naturally, different programming paradigms motivate different types of visualization. For instance, declarative programming visualization requires presenting what the program does, while imperative programming also requires visualizing how it does it. Following this line of thought, different authors focused on different aspects of program visualization. Myers [32] classified program visualization systems according to what they illustrate (data, code, or algorithm) and how (statically or dynamically). Price et al. [40] further subdivided the field into a more hierarchical taxonomy, and many others followed [4, 43].

Diehl [12] stressed that it is not only important to comprehend what a program does and how it does it, but also how we got to that point in the development process. The current widespread use of version control systems for both individual and collaborative work stands as proof to this, although their reliance on purely textual mechanisms hardly places them within program visualization.

A program visualization feature that fully exploits the visual nature of AD is traceability, that is, the identification of which parts of the model correspond to which parts of the program, and vice-versa [29]. This connection established between the program and respective result is of utter importance for the comprehension of AD programs [49], and several AD tools offer it already, e.g., Dynamo and Rosetta [29].

2.2 Liveliness

The dynamic component of program visualization introduced terms such as liveliness, interactivity, or reactivity, which became the main agenda for IDE developers invested in program comprehension.

Live Coding. The introduction of live coding blurred the lines between programming and explaining, advocating a real-time connection between program and result [42]. Live coding is frequently described as a creativity technique centered upon the writing of interactive programs on the fly [42]. In many cases, the liveliness requirement addresses the timing needs of live performances, such as musical ones [47]. However, its application to the programming task also helps users relate the changes in the program to their respective impact on results, thus aiding program comprehension.

In the case of AD, live coding requires the model to be quickly recomputed for every change applied to the program, which can be difficult to ensure when the program generates a complex model. For simple cases, however, there are already competent solutions integrated with AD, such as Grasshopper and Luna Moth [1].

Interactive Evaluation. Another perspective on liveliness that also aids comprehension without implying a scalability issue is interactive evaluation. By opposition to batch-evaluation, where the entire program must be loaded prior to execution, interactive evaluation motivates users to test small program fragments, debugging the program as it is being constructed [23]. It is frequently used for exploratory programming [42], a workflow typically employed when the requirements of the program are not fully defined. Hence the programming task becomes more of an exploratory experiment, a common scenario in AD.

Despite the advantages, there is a catch, particularly for beginners. Interactive evaluation promotes ad-hoc program construction that can introduce confusing bugs for developers unfamiliar with the obstacles of program state [15]. Experienced programmers avoid this by using a batch-oriented style in interactive systems, resetting the program after any major change, an approach that is enforced by some pedagogical IDEs [14, 15]. Once more, the programming paradigm used is also relevant, as declarative programming languages minimize the negative effects of program state when compared to imperative ones.

Reactivity. Reactivity is another take on liveliness that also advocates exploratory programming. However, the focus lies on tracking the dependencies in the program so that any change updates the entire state, as it happens in spreadsheets, for instance. The central idea is to have the system automatically manage dependencies to free the user from such burden [3]. With reactivity, since any change to the program triggers the re-evaluation of all dependencies, the program state is always consistent. As such, this paradigm also provides an alternative solution for the state problem introduced by interactive evaluation.

The data flow paradigm [27] is a good example of reactive programming. Here, programs are described by graph structures with nodes representing the functions and the wires that connect them representing the data that flows between components whenever something changes upstream. Most visual programming languages used in architecture, such as Grasshopper, are literal interpretations of this paradigm (Fig. 3). Note, however, that in what regards program comprehension, the data flow paradigm is flawed, since the node structure hides program complexity instead of explaining it, while also promoting program fragment repetition.

Fig. 3.

Grasshopper diagram from [45].

3 The Program Comprehension Dyad

To promote the use of AD, we propose a new design medium that allows for the creation of algorithmic descriptions in a live and documented way, making the task of understanding and changing AD programs easier for both the creator and others. To this end, we explore a program comprehension dyad: (1) documentation and (2) liveliness. These are two very broad concepts, which we fine-tune for an ideal IDE for the development of AD projects. Documentation is narrowed down to the concept of (i) storytelling, and liveliness is subdivided into (ii) interactive evaluation and (iii) reactivity. The following paragraphs summarize the definitions we consider for each of these concepts.

(1) Documentation, in the programming context, refers to the task of explaining the program, to facilitate later comprehension to the authors and other readers. The concept encompasses most of the research made under the program comprehension and visualization umbrellas, with emphasis on static visualizations. Documentation can be done prior, during, and after the program development, and it can also be internal and external to the program.

(i) Our proposal for the integration of documentation in the context of AD narrows this concept down to storytelling: the creation of a tale for the program’s evolution. Storytelling thus contemplates internal documentation done while programming and aims at creating a narrative of the program development history, with program and respective documentation intertwined.

(2) Liveliness is the ability to live-test programs. Liveliness accommodates the dynamic or animated part of program visualization and subsequent branches. Liveliness can manifest itself in many ways, including live coding, interactive evaluation, and reactivity. Given that live coding tends to suffer from scalability issues, we focus on the two latter concepts.

(ii) Interactive evaluation allows a two-way flow of information between the computer and the user. With the user controlling just how lively a system is, the scalability problem becomes less relevant, although it increases the risk of program state inconsistencies.

(iii) In the context of AD, we consider reactivity as an automatic response that maintains state consistency by reevaluating all program parts that depend, directly or indirectly, from a part that was changed. This is more efficient than reevaluating the entire program, as is typically done in live coding, thus delaying but not eliminating the scalability problems that tend to affect complex AD programs.

Storytelling, interactive evaluation, and reactivity intersect in many ways. They can both complement and hinder each other. In the following sections, we explore this relationship and point out mechanisms to elude possible conflicts. Two case study project adaptations will be used to illustrate the proposed concepts: BIG Architects’ Business Innovation Hub for the Isenberg School of Management in Amherst, Massachusetts (Fig. 4, left); and Santiago Calatrava’s Liège-Guillemins railway station in Liège, Belgium (Fig. 4, right).

Fig. 4.

Case study projects: Isenberg on the left and Liège-Guillemins on the right.

3.1 Storytelling

In an ideal IDE for AD, designers should be allowed to keep the artifacts produced along the design process in an organized fashion, explaining and documenting the resulting program. Storytelling intends to transform the program into a creative journal of the design’s development that includes not only textual documentation but also sketches the architect made during a creative sprout [13]. Drawings are “essential to both public discourse about architecture and the development of the architect’s thinking" [46, pp. 58]. Following this reasoning, we argue that the drawings produced when idealizing the design and the way it translates into a program (Fig. 5) can help document the program’s evolution and expected outcome.

Fig. 5.

Sketches made while developing the Isenberg school program.

Static images of the program’s output, such as snapshots or renders of the generated model, are also relevant for the comprehension process. Very frequently, we introduce bugs in the program without noticing. Having a correct version (or a version of what the author considered to be the proper behavior of the program) available for comparison, may prove vital in debugging.

Withal, it is important to note that architectural design is by no means a linear process: upon seeing the (computational) results of their designs, architects frequently step back and change the design concept, rendering much of the documentation out of date. Storytelling embraces this issue by applying Diehl’s concept of software evolution [12] to the context of architectural design: new documentation artifacts should be added whenever the program changes its intended behavior, thus keeping the history of design changes in the AD program.

3.2 Interactive Evaluation

Designers should feel motivated to construct and test their programs interactively, that is, executing programs parts immediately after (re)writing them. Interactive evaluation transforms what could otherwise be a very abstract process into a tangible and relatable one.

Interactive evaluation of AD programs typically produces visual results, which can become documentation artifacts. Given the proposed storytelling approach, we adapt our take on liveliness to accommodate the narrative style as well. Figure 6 presents the interactive development process of the slabs in the Isenberg project: an initial iteration of the slab function creates the intended contour; modifications are applied to contemplate the ground-floor exception; and later iterations convert the contour into 3D objects distributed along the height of the building. Each change is followed by a test that produces these visual results and the entire process is kept and documented in the AD program.

Fig. 6.

Interactive test results from the Isenberg slab function evolution process.

Nevertheless, there are two major setbacks to this intersection of interactive evaluation and storytelling: (1) the resulting verbosity, and (2) the aggravated state problems.

(1) The step-by-step development process often results in an accumulation of localized tests and repeated or scattered program fragments. Refactoring and outlining techniques can help architects rearrange some of the scruffiness to obtain a cleaner and more intelligible program in the end.

(i) Refactoring is commonly defined as the process of improving the structure of existing programs without changing their semantics or external behavior [17]. There are several semi-automatic refactoring tools [31] that can be adapted to an AD context. Of particular interest to the case are those that help the programmer join scattered code in summarized functions.

(ii) Outlining techniques, i.e., the structuring and identification of what each part of the program is or does, may also serve to hide parts of the program for particular audiences and/or purposes. For instance, an outlining mechanism that identifies the tests the user wishes to activate or deactivate in any run considerably improves the program’s performance and allows the same program to serve multiple presentation purposes. This goes farther than the outlining system typical of visual programming languages, such as Grasshopper (which allows readers to deactivate individual nodes on demand), by supporting a structured system of goal-oriented active/deactivated groups of program fragments.

Naturally, by using these mechanisms to reorganize the program, we are partially relinquishing the development history. However, we believe this is a necessary trade-off, since the order in which we create a story may not necessarily correspond to the order in which we wish to tell it to others.

(2) State inconsistency is a direct consequence of the use of interactive evaluation, which gets further exacerbated by the permanence of repeated definitions in the program. Outlining may ease part of the problem by deactivating outdated definitions. To avoid it entirely, we propose reactivity, which is discussed in the following section.

3.3 Reactivity

AD programs are systems of hierarchical relations between parts of the design. The functions that compose the separate parts of the building are interdependent so that the entire ensemble can function as a whole. Consequently, all building elements should morph appropriately when design parameters are changed (Fig. 7).

Fig. 7.

Liège-Guillemins project: three possible variations of the model with different lengths, widths, and height for the central hangar.

This workflow essentially means that changes to the program frequently influence more parts of that program, other than the one we are modifying. As such, interdependencies must be considered when applying changes. However, in large programs, keeping a mental track of this system of relations is close to impossible. Hence, the program should make these relations visible for designers.

This can be achieved, for instance, by having the entire set of active tests in the program reacting to the changes that are being applied. If we can immediately visualize the impact of the changes all over the program, we are more likely to succeed in maintaining the necessary interdependencies in the AD project. Doing so in an interactive manner, using user-friendly mechanisms, such as buttons or sliders, to explore the influence of design parameters in the project’s design space, further adds to the comprehension layer.

Reactivity offers this capacity by keeping track of dependencies in the program. Any change to the program triggers a reevaluation of the dependent parts, ensuring state consistency. Naturally, this means there can be no outdated definitions in the program. Once more, users must resort to outlining and refactoring to deactivate old versions of existing definitions or relinquish storytelling all together for reactivity to work. Furthermore, while reactivity does not necessarily imply the regeneration of the entire model, it does imply the constant re-processing of the dependency graph, which can become computationally intensive in large programs. Liveliness always was and will continue to be a double-edge knife. Hence, it should be used in accordance with the compromises it offers.

4 Exploratory Application

In this section we elaborate on a practical implementation of the proposed concepts in an AD workflow - storytelling, interactive evaluation, and reactivity - using computational notebooks as the base IDE for the experiment.

4.1 Computational Notebooks

Many of the problems described above are shared by the scientific community. In science, reproducibility is critical but the increasing specialization of the different areas is making it hard to reproduce published scientific results. To address this issue, the scientific community is embracing new methods of experimentation that rely more and more in computational simulation and analysis of different phenomena.

Computational notebooks have emerged in this context, promoting method transparency and data availability in the form of “executable papers" [26]. By supporting the description of computational experiments and the analysis of simulated or experimental results in an explanatory and reproducible way [44], they became a critical tool in science [24, 37], not only to understand the scientific breakthroughs being presented, but also to reenact them. The following paragraphs describe computational notebooks’ interpretation of the dyad concepts: (1) documentation and (2) liveliness.

(1) Computational notebooks were designed to support computational narratives, allowing users to simultaneously execute, document, and communicate their experiments through the intertwining of code and textual and visual documentation. The same notebook can serve multiple purposes, such as tutorial, interactive manual, presentation, or even scientific publication [26, 38].

(2) These tools also promote interactive evaluation, a workflow that greatly benefits experimentation with data [38]. This is typically achieved with the input and output cell system: users write a fragment of code in a cell and run it immediately after to observe the result. The cell layout provides a half-solution to the heavy computation agenda of liveliness, since the code lodged in each cell is only run at the user’s request.

However, interactive evaluation in notebooks motivates exploratory programing and, in this paradigm, the hunger for immediate results frequently overpowers the interest in organizing the program. Developers can add cells in a non-linear order, definitions can be intertwined with tests in the same code cells, and repeated code bits can be spread along the document. This disarray creates a complex dependency net with hidden program state, whose results frequently confuse the developer. This fact has been identified as one of the major pain points in the use of computational notebooks [10, 19] and reactive notebook solutions have also been put forward to respond to the criticism [35, 39].

Given the above-mentioned benefits and burdens of the use of computational notebooks as comprehensive IDEs, we propose to explore their use in the context of AD to evaluate storytelling, interactive evaluation, and reactivity. To that end, the two case studies presented above were developed in two different notebooks: the Isenberg School model in Jupyter [41], and the Liège-Guillemins station model in Pluto [39], both using the Julia programing language and the Khepri AD tool [45]. Both projects relied on notebooks’ natural tendency for documentation and liveliness, yet the implementation of the three sub-concepts had to be adapted to each notebook, as they operate very differently.

Jupyter [41] is an open-source and web-based notebook. Although it was originally developed to support the programming languages Julia, Python, and R [38], nowadays, Jupyter not only offers a wide range of programming languages but it also allows users to mix them in the same notebook. Jupyter is based on the input/output cell approach and it supports repeated definitions, which allows us to easily apply the storytelling strategy.

Pluto [39] is a computational notebook conceived specifically for the Julia programing language, with one outstanding difference from typical notebooks: reactivity. Pluto was inspired by Observable [35], a reactive computational notebook for JavaScript. Both recognize dependencies between cells, so that when one of them is changed, all dependent ones are automatically updated. This means there can be no repeated definitions, which renders storytelling difficult without outlining mechanisms.

4.2 Storytelling

Storytelling defends program documentation as a way to embrace the tale of the program’s evolution. When organized chronologically, the artifacts we produce to document our programs can tell the narrative of the design development process for a better comprehension of the final design solution. Figure 8 presents the modeling history of the Liege-Germmins’ project.

Fig. 8.

Liege-Germmins’ project development history: modeling sequence.

To tell the tale of design development, instead of building on existing definitions, storytelling states that developers should consider keeping the definition history intact. In the Jupyter notebook, used to develop the Isenberg project, consecutive versions of the same functions were kept in the document in chronological order. For instance, the project is composed of C-shaped slabs, as shown in Fig. 6. All versions of the above-mentioned slab function were kept in the notebook, properly documented, textually and visually.

In Pluto, the same effect can only be obtained if we give each version of the function a new name, or if we deactivate old versions (by commenting them or using other outlining techniques). Being a reactive notebook, Pluto needs to maintain state consistency. Hence, it does not allow for repeated definitions.

Regarding the integration of artifacts in the program, computational notebooks have several mechanisms available. For textual documentation, we can use markdown, which can help both explain and structure the program (Fig. 9 left), and simple code comments to explain things inside function definitions (Fig. 9 right). Markdown also supports mathematical notation, which is one of the best ways to describe parametric shapes. Figure 9 presents, on the left, part of the Pluto notebook, where the sinusoidal function parameters are explained. This function defines the shape of the station’s roof and arches.

Fig. 9.

Pluto, on the left, exploring and explaining the sinusoidal function. Jupyter, on the right, illustrating Isenberg’s tilted façade panels’ function.

Visual documentation can be added via HTML or through IPython’s display package for Jupyter and PlutoUI for Pluto. This type of documentation can consist of drawings created during design development that reveal the author’s intention towards the program’s expected behavior and results (Fig. 9 right) or images generated for the sole purpose of explaining parts of the program. The latter case includes snapshots and rendered images of the generated model. These images are useful devices to make sure the program is producing the results it should. Figure 10 presents some of the snapshots saved in the Jupyter notebook after running test cells on the Isenberg program that generate isolated elements or the building as a whole.

Fig. 10.

Snapshots of function tests run from the Jupyter notebook, saved as documentation in the Isenberg program.

4.3 Interactive Evaluation

Computational notebooks natively promote interactive evaluation as a form of liveliness controlled by the user. Immediate visual results can be obtained by running cells that produce geometry whenever the user wishes to test a particular code snippet. Ideally, this occurs after every new definition. Figure 11 presents an application of the interactive evaluation workflow to the the train station in Pluto: (1) the programmer (re)defines the canopie_bars functions, (2) implements a test case, (3) runs the test, and (4) saves the visual result as documentation in the program. Steps 1 and 3 may be retaken several times until a satisfactory result is achieved. Only then, should the user move on to step 4.

Fig. 11.

Pluto notebook: interactive evaluation applied to the canopie bars’ function in the Liege-Germmins’ project.

In this case, the user improved the resulting snapshot by identifying each bar in the image with the corresponding name in the function definition. The drawing thus became a more relevant piece of documentation, not only because it shows what the expected result of the test is, but also because it visually explains the body of the function it illustrates.

Both Jupyter and Pluto provide sets of commands to move cells up and down, and merge and split cells. These can be used for refactoring purposes. As for outlining, we developed two different mechanisms of identifying test cells in the notebooks. In Jupyter, since cells only run at user request, we simply wrapped all test examples with an outlining mechanisms that bound them to a global variable. The state of this variable defines what happens when a test cell is run: it either produces results, or the test is ignored. For Pluto, separate variables manage the state of each test, else the dependency graph would have them all running simultaneously. These variables are presented using PlutoUI’s checkbox widget (Fig. 11). Checking a test box will prompt a test cell to run. While the box is checked, the test cell will re-run if any change in the program affects the code within it.

4.4 Reactivity

Reactivity means keeping track of dependencies in the program, so that immediate feedback on results can be provided whenever a change occurs. This is essential for users to understand program dependencies and guarantee consistency in exploratory programming. In the context of AD, reactivity is particularly useful for parametric manipulation (Fig. 12).

Fig. 12.

Isenberg model test with sliders binding the building’s parameters. Four variations: 3 to 5 floors variation vertically, and 10 to 15 tilted beams variation horizontally.

Our implementation relies on two extensions of the chosen computational notebooks: Interact for Jupyter and PlutoUI for Pluto, which allow the use of sliders, toggles, and other widgets to visually manipulate data. However, the core difference in the nature of the two notebooks means reactivity is used very differently between them.

In an innately reactive environment like Pluto, widgets bound to global variables provoke immediate updates on dependent cells. This means that in the example shown in Fig. 9 (left), when the sliders bound to the sinusoid parameters are changed, the graph shown beneath is immediately updated, as will be other cells in the notebook that are dependent upon these variables. If they are not specifically signaled as ignorable, they will render new results at any change in the sliders. When one dependent cell causes side-effects, such as the creation of architectural objects that is typical of AD, the cell’s reevaluation needs to undo the previous side-effects to avoid accumulating them.

To best adapt reactivity to AD, we modified the Pluto notebook to track down not just cell dependencies but also their side-effects. As such, the notebook’s dependency graph knows which geometry was affected by each change, so that it can be selectively deleted and regenerated, maintaining state consistency with good interactive performance.

In Jupyter, we cannot hope to achieve reactivity at the level of the notebook. Since cells are only evaluated on user demand, we may strive for partial reactivity. Interactive features, in this case, are best used for particular tests inside one cell only. Figure 12 presents an example: the widgets are bound to local variables in a test cell used to generate the Isenberg model. Any change to the sliders will prompt the regeneration of the model in that test cell.

5 Conclusion

In this paper, we explored the program comprehension dyad - documentation and liveliness - as a means to improve the comprehension of AD programs. We proposed the integration of more adequate methods of developing and maintaining algorithmic representations of complex architectural projects by fine-tuning the two concepts to better suit the architectural scenario. Three ideas emerged: (1) storytelling - explaining the program through human-readable text and meaningful imagery, intertwined with the code itself to tell the narrative of design development; (2) interactive evaluation - a scalable way of incorporating liveliness in programming, providing feedback on program results upon user demand; and (3) reactivity - a systematic approach to liveliness, which offers immediate feedback on program changes and reveals program dependencies. We proposed to incorporate the three concepts in an AD workflow and we evaluated their application using computational notebooks as the base programming environment.

The three ideas intersect in many ways, starting with interactive evaluation and reactivity being two different ways of applying liveliness to the programming task. Interactive evaluation offers a more scalable option, albeit with program state issues, whereas reactivity resolves any state problems and promotes a more interactive workflow, however, failing to scale to large projects without proper outlining mechanisms. A trade-off is needed between efficiency and consistency, but reactivity in itself will always suffer from scalability issues.

Both interactive evaluation and reactivity promote exploratory programming, which can cause program disarray. Storytelling, on the other hand, defends an organized approach to the programming endeavor, which means refactoring mechanisms must be used for the three approaches to co-exist.

Storytelling also appeals to the preservation of the development history as part of the narrative. This directly conflicts with reactivity’s requirements for a consistent program state. The two can only operate simultaneously if outdated definitions are disabled. Interactive evaluation, in turn, greatly contributes to storytelling by producing artifacts that can be used as documentation, namely tests results in the form of imagery.

In sum, the three ideas provide different sets of advantages and trade-offs to the process of developing AD projects. Their integration in the AD workflow requires support from the programming environment according to the architect’s own needs at any stage of the development process, as well as considering the ultimate goal for the program. AD programs may be a means of attaining a single constructive goal, they may represent a set of ideas to be re-used in the future, they may serve as presentation mechanisms, etc. Taking this in mind, some of the concepts may or may not apply to each case.

As future work we plan on investigating solutions for the ever-lasting compromise between liveliness and scale. Given that architects do not need to visualize the entirety of the project all the time, nor the entirety of the project’s detail, we expect Levels Of Detail (LODs) and/or selective generation based on project areas or view cones to yield good results. This may allow architects to keep using reactive mechanisms later along the project’s development. We also plan on incorporating traceability research to the proposed methodology, studying mechanisms of integrating it with the remaining concepts in a functional workflow.