In 30th eCAADe Conference, there was a very interesting paper by Gabriel Wurzer and Burak Pak, titled: “Lawnmower”, that explains a research on an educational tool. However, their survey tells us some of the fundamental issues of dataflow programming paradigm for designers. Here is a quote from them;

…A further point not connected with the graphical representation is that of lacking comprehensibility of data flow (and therefore the call for step-by-step debugging). Data in Grasshopper is mostly exchanged via lists containing geometrical objects. These lists are used as a replacement for loops, in the following manner: Instead of building up an object iteratively by consecutively adding a point, all points are immediately generated and modified as they pass through the flow graph. Understanding the modifications on lists of objects can be hard to understand, and requires a certain amount of knowledge of set theory (e.g. when intersecting two lists). If there would be an explicit loop statement, simple data types could be used to iteratively build up an object on a point-by-point, which we find preferable for didactic purposes…

Wurzer, and Pak,  eCAADE 30, pp.655-663

Iteration constructs is a well-known problem / potential of dataflow languages since late 70s. However such problems are still unknown to educational curriculum of architecture. Researches such as this one will hopefully address these issues to make academia catch up with technology. Here is another quote from Mosconi and Porta, depicting the same problem from the perspective of computer engineering:

Many visual programming languages (VPLs) rely on the data-!ow paradigm, probably because of its simple and intuitive functioning mechanism. However, there are cases where more powerful programming constructs are needed to deal with complex problems. For example, iteration is undoubtedly an important aspect of programming, and should allow repetitive behaviors to be speci2ed in compact and easy ways. Most existing data-!ow VPLs provide special constructs to implement iterations, therefore infringing the pure data-flow paradigm in favor of program simplicity.

Mosconi and Porta, 2001

Nowadays, I feel it is best to use any tool in designing, only if it is really necessary.