Liège-Guillemins Railway Station
Original project: Santiago Calatrava
Programming Language: Julia
Algorithmic Design Tool: Khepri
Programming Environment: Pluto
The Liège-Guillemins railway station, located in Liège, Belgium, was designed by Santiago Calatrava in 1996 and inaugurated on September 18th, 2009. The station has a total built-up area of 49000 m2 and the architect's design identity statement. The project features a 160-meter-long arc-shaped dome, reaching 32 meters of height at the peak. The permeability of the roof structure that shelters the station allows the two opposing neighborhoods on each side of the station to visually dialog. The concept somewhat eludes the traditional idea of façades, presenting instead two monumental canopies, one on each side of the station.
Context
This modeling of this case study took place with the purpose of testing the Pluto
notebook and its impact on the comprehension of Algorithmic Design (AD) programs. Much
of the programming struggle associated with AD 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 and it hard to use them as design tools.
Our proposal entailed making 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
explored two ideas that facilitate program comprehension: (1) documenting and (2) liveliness.
These 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. A strategy for the integration of these concepts with
the AD workflow was outlined and evaluated using computational notebooks as the base IDE
for the experiments.
Program Comprehension 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. Documentation can be done prior, during, and after the program development.
(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. The documentation process should thus aim 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 can
manifest itself in many ways, including Live Coding (LC), interactive evaluation, and
reactivity. Given that LC tends to suffer from scalability issues, we focus on the two
latter concepts and explore their relation within the AD context.
(ii) Interactive evaluation allows a two-way ow of information between
a computer and a 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 LC, thus delaying but not
eliminating the scalability problems that tend to affect complex AD programs.
Computational notebooks
Computational notebooks have been gaining notoriety among the scientific community for
the interesting interpretation they have of the two 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.
(2) These tools also promote interactive evaluation, a workflow that greatly benefits
experimentation with data. 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. The resulting 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.
Pluto is a computational notebook
conceived specifically for the Julia programing language, with one outstanding
difference from typical notebooks: reactivity. Pluto recognizes dependencies between
cells, so that when one of them is changed, all dependent ones are automatically
updated.
Links
Pluto notebook on HTML page