by Tuğrul Yazar | July 31, 2014 20:54
This is the introduction chapter of my latest paper presented at the Nexus 2014 Conference, in Ankara. The paper will be published in the 2015 issue of Nexus Network Journal.
Generative algorithms have been integrated to design in a sequential form where text-based scripting languages are accepted as mainstream tools. This approach to design scripting originated from “control flow”, the dominating paradigm of programming languages. Methods of control flow eventually lead designers to seek secondary syntactic mechanisms in order to control program states, such as iterations, branchings, and conditionals. Developing sequential executions of such statements mostly created a cognitive layer in design praxis, and an esoteric skill for design research. In some cases, this leads to the suppression of other design domains and even becomes the de facto purpose of a design process at. Moreover, it might be argued that control flow computing has inevitably become the primary conception upon which a whole body of knowledge generally known as “Algorithmic Architecture” [after Terzidis 2006] was constructed.
For less than a decade, casual coders of architecture and design are experiencing a different way of planning and writing algorithms [Çolakoğlu and Yazar 2009]. Pioneered by Grasshopper for Rhinoceros, and later Dynamo for Revit, the new generation of Visual Programming Languages (VPL) transferred an alternative approach to design scripting. The collective social network of design computing reacted to these tools and methods faster than academia, where the novelty of this approach did not attract much attention. Among a few publications about design VPLs, [Leitão and Santos 2011] explain fundamental differences between textual and graphical approaches in scripting, and compare them according to usability in various design conditions. [Celani and Vaz 2011] also study VPLs in order to compare different scripting languages for design education. Both of these studies concluded with an argument that the visual construction of algorithms is perceptually limited, thus they are more successful in relatively simple and pedagogical uses. The discussion of design education via VPLs is further extended by [Wurzer and Pak 2012], who present the first cognitive surveys about VPLs in design, stressing the necessity to develop tools and methods for its education.
Perceptual limitations of VPLs (generally called the “Deutsch Limit”) is a controversial argument as even extreme modularity (or clustering) could be implemented in visual interfaces just as effectively as in textual ones. The cognitive qualities of VPLs and their comparisons with other programming environments have been a research topic of computer science for at least 35 years. Readers are referred to [Myers 1989], [Nickerson 1994], and [Menzies 1998] for in-depth studies and bibliographies about visual programming, program visualization, and related studies. Today, most of the experiments about the use of VPLs in architecture and design are conducted by the collective social network of design computing mostly via workshops. The expansion behavior of this network is a significant subject to study in order to understand (non)academic development of the field; which is out of the scope of this particular paper. This study focuses on the education of the computational model underneath the VPLs mentioned above. It is not only textual or graphical interfaces, but the concept of “dataflow” make such languages exceptional and more exploratory for designers. After the definition of dataflow from the perspective of design research, various educational experiments are introduced in this paper, categorizing them according to causal connections called as pedagogical patterns.
Since its definition as a novel computational model in the mid-1970s, dataflow has found use in a wide range of programming languages. From a broad perspective, dataflow represents a deterministic solution to the abstract modeling of concurrent systems, offering an alternative to traditional von Neumann machines and languages [Agerwala and Arvind 1982; Davis and Keller 1982]. The concept of dataflow is generally originated in William Sutherland’s [Sutherland 1966] Ph.D. dissertation, in which he describes graphical representations for algorithms [Sousa 2012]. The term dataflow is also used in other fields such as business management and finance when there is a need to model relationships that include parallel events. Although dataflow is generally related to parallel computing research on computer hardware, [Ackermann 1982: 15] argues that many of its properties existed long before dataflow computers were conceived. The bibliographic work of [Johnston et al. 2004] explains the development of the dataflow concept; started as a study on computer architecture, and evolved as a programming language and compiler research until today. Dataflow programming is alternatively called “stream-based programming” [after Uustalu and Vene 2005: 135] and “program graph execution model” [after Najjar, et al. 1999: 1907]. This paper focuses on the dataflow programming environments utilized within the VPLs mentioned in the previous section.
In their article titled, “A Diagram is (Sometimes) Worth a Thousand Words”, [Larkin and Simon 1987] describe forms of representation as constructive components of the knowledge itself;
“…the fundamental difference between our diagrammatic and sentential representations is that the diagrammatic representation preserve explicit information about the topological and geometric relations among the components of the problem, while the sentential does not. A sentential representation may, of course, preserve other kinds of relations, for example temporal or logical sequence…”
[Larkin and Simon 1987: 66]
In control flow programming, the idea to represent algorithms in two dimensions is generally realized by flow charts which are used to explain the order of functions to be executed; whereas dataflow programming treats these charts beyond representational, but generative. [Johnston et al. 2004] describe dataflow in a different relationship with its representational medium, stating;
“…the name dataflow comes from the conceptual notion that a program in a dataflow computer is a directed graph and that data flows between instructions along its arcs…”
[Johnston et al. 2004: 1]
This description shifts the focus of flow charts from process management to the evolution of data itself. While looking at the graph, it is expected to comprehend the flow of information between the nodes via arcs, but not the sequential order of functions to be executed. Below, [Davis and Keller 1982] are clarifying the same idea from the opposite direction;
“…this flow concept gives data flow languages the advantage of allowing program definitions to be represented exclusively by graphs…”
[Davis and Keller 1982: 26]
The graphs mentioned above are mostly directed and acyclic diagrams, preferably similar to Petri Nets commonly called “dataflow diagrams” (DFD). This diagrammatic representation reveals a design continuum that creates a suitable environment to work directly on the evolution of the design itself, rather than the secondary mechanisms; “the code” that generates designs. This alone introduces a different understanding of solution spaces in architecture and design. The concept of dataflow is effectively utilized within VPLs of architecture and design today as they allow the creation and manipulation of formation processes via DFDs.
[Agerwala and Arvind 1982] define two fundamental characteristics of the classical von Neumann model of computation that are distinctive from the dataflow model; which are the lack of global updatable memory, and a single program counter. Below is a brief explanation of these two characteristics from the perspective of VPLs of design;
NO GLOBAL UPDATABLE MEMORY
“…Professional programmers with years of experience in writing Fortran code have become very good at writing Fortran-like solutions to problems. The change to Algol, Cobol, Pascal, etc., is not a large conceptual step, in that the structural styles of these languages are not radically different from Fortran’s. However, data flow languages require and support very different styles. Programmers trained only in conventional languages might be unwilling to try problem-solving techniques based on graphical or even functional program structures…”
[Davis and Keller 1982: 40]
In today’s control flow scripting, designers are expected to create “variable containers” to use and transfer data. These variables should be carried over each code line in a sequence, which is defined by strict syntax rules of the language; therefore has side effects on the overall running of the algorithm. The design process is likely interrupted by optimization, and/or error-catching activity, or becomes one of them literally. In the dataflow approach, designers are expected to deal with the evolution of data itself, but not the data containers. Hence a designer does not need to plan variable names, he/she directly controls how data streams should flow along the functions, transform into different forms, and fire different branches of the graph, further re-forming itself in order to achieve a desired solution space. A number, a coordinate, a shape, or a sound can be defined as a reference to one another, or transformed into geometric forms with desired complexity. This formation process can be expanded or contracted by joining or cutting parts of the DFD, or creating clusters. As each node of the DFD is working independently without side effects, the flow of data can easily be re-directed to another path to extend the exploration. This is why dataflow algorithms can easily be composed into larger ones, or manipulated in real-time to test different solution spaces. In design VPLs, this characteristic encourages designers to sketch directly on the geometric formation process, giving an opportunity to develop parametric design systems in real time.
NO SINGLE PROGRAM COUNTER
“…in dataflow programming, there is no locus of control, nothing corresponding to the program counter of a conventional sequential computer … the dataflow model describes computation in terms of locally controlled events; each event corresponds to the “firing” of an actor … in a dataflow execution, many actors may be ready to fire simultaneously (locally controlled by their operand availability) and thus these actors represent many asynchronous concurrent computation events…”
[Najjar et al. 1999: 1907]
Dataflow does not have a single program counter that manages the execution of algorithms in a sequential manner. It is described as a data-driven process continuously fired by interconnected events, re-calculating its branches only when any related input is changed by another event. This creates a naturally optimized workflow, enabling real-time running. Designers do not hit a “run” button to see the result of an algorithm, instead, he/she manipulates an already running process, seeing the outcomes of the actions immediately. This results in a closer relationship between the subject and designer, resembling a cycle closer to a form of “reflection-in-action” [after Schön 1983]. However, the lack of a sequential program counter has its own disadvantages. Logically, an acyclic DFD can not execute iterative or recursive events by nature, where data is expected to feed back to itself. [Mosconi and Porta 2001] explain various iteration constructs for dataflow languages, and their most addressed disadvantages compared to control flow counterparts. (…)
Source URL: https://www.designcoding.net/design-of-dataflow/
Copyright ©2024 designcoding unless otherwise noted.