Nowadays I plan to enter Rhinoscript, Python, and DesignScript back again. However, I can’t leave Grasshopper3D without mentioning the “cognitive shift” it pioneered in the design computing community. Here is a phrase from a famous special issue of “Computer” Journal, published in 1982 with Tilak Agerwala and Arvind’s editorials;

Data flow languages form a subclass of the languages which are based primarily upon function application (i.e., applicative languages). By data flow language we mean any applicative language based entirely upon the notion of data flowing from one function entity to another or any language that directly supports such flowing. This flow concept gives data flow languages the advantage of allowing program definitions to be represented exclusively by graphs… There are many reasons for describing data flow languages in graphical representations, including the following:

(1) Data flow languages sequence program actions by a simple data availability firing rule: When a node’s arguments are available, it is said to be firable. The function associated with a firable node can be fired, i.e., applied to is arguments, which are thereby absorbed. After firing, the node’s results are sent to other functions, which need these results as their arguments. A mental image of this behavior is suggested by representing the program as a directed graph in which each node represents a function and each (directed) arc a conceptual medium over which data items flow…

(2) Data flow programs are easily composable into larger programs.

(3) Data flow programs avoid prescribing the specific execution order inherent to assignment-based programs. Instead, they prescribe only essential data dependencies. A dependency is defined as the dependence of the data at an output arc of a node on the data at the input arcs of the node. (For some functions, the dependency might be only apparent.) The lack of a path from one arc to another indicates that data flowing on those arcs can be produced independently. Hence, the functions producing those data can be executed concurrently. Thus, graphs can be used to present an intuitive view of the potential concurrency in the execution of the program.

Davis, A.L., and R.M. Keller. “Data flow program graphs.” Computer 15.2 (February 1982): 26

And finally, they conclude with a practical argument, from the perspective of a computer programmer. Nowadays, the same perspective is also changing “casual coder” architects’ understandings of the whole theory of algorithmic architecture. Except for the fact that it is 30 years later now.

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. Therefore, the potential gains of such techniques must be made apparent to programming management.

Davis, A.L., and R.M. Keller. “Data flow program graphs.” Computer 15.2 (February 1982): 41

There is still much to do with dataflow management in architecture and education, however as most computer scientists agree, these paradigms should also be used together with old ones, accepting their advantages. I’ll continue to work with Grasshopper3D, but also I need to give more time to new environments such as designscripting, python, and Dynamo. As my dissertation advisor Oya Pakdil says;  “neither of them, but both of them…”