Читать книгу Rethinking Prototyping - Группа авторов - Страница 104

In response to the limited success of text based imperative language in design, a completely different approach to computation, called dataflow programming, has emerge. “Dataflow programming is a programming paradigm that models a program as a directed graph of the data flowing between operations, thus implementing dataflow principles and architecture”[3].

Typically, graph nodes represent operations, including the data resulting from these operations, and the arcs of the graph represent the flow of data, including the implied dependencies, between nodes. Applications such as MAX-MSP [4], GenerativeComponents [5] and Rhino Grasshopper [6] are examples of a dataflow approach to design computation.

A particular advantage of dataflow programming is that the underlying graph can be represented visually and this provides an intuitive users interface for end-users with little or no programming experience. Indeed, the success of these applications is mainly due to the way in which designers, as novice end-user programmers, have been able to express design logic without having to acquire knowledge of conventional programing syntax. Quite possibly, the designers using these dataflow applications do not even consider this to be programming.

There are two criticisms of graph based data flow applications. The first criticism is that the human use of such dataflow systems does not scale to complex problems. Of course the graph technology can deal with thousands of nodes. But a design computation application is an example of a man-machine system and the art of designing a successful man-machine system is to match the characteristics and representation of the machine component to the capabilities of the man. It is the human capacity to comprehend the graph which is the limiting factor. Therefore, what starts off as a useful explanatory tool with five to 20 graph nodes becomes unfathomable with 100 nodes. As the underlying problem increases in complexity, the graph system appears to add visual complexity non-linearly rather than to continue to provide clarity. Essentially an initial advantage of the visual graph representation eventually becomes a limitation.

Most of the data flow applications allow custom nodes to be implemented using existing high-level languages such as Python or C#. This enables the dataflow system to access external libraries and also allows the designer to implement functionality using imperative programming. This approach is particularly useful where the design logic being implemented might not be suited to data flow programming. However, a second criticism of these applications is that the gap in level of skills required between using a graph-node user interface and using high-level imperative languages is often too extreme for the novice programmers to overcome (Fig. 1).

Fig. 1 Existing dataflow applications provide an initial ease of use for novice users with simple graph-node models, but do not scale to complex problems. Essentially, there is no continuous learning curve between dataflow diagramming and programming in conventional high-level imperative languages.

The intention in the development of DesignScript is to address these two issues by providing a single, continuous and gentler learning curve between data flow diagramming and more complex forms of design computation (Fig. 2).

This learning curve represents a potential progression in skills on the part of designer, his use and understanding of progressively more powerful computational concepts and techniques. Underlying this is also the idea that the designer will be progressing from an exploratory style of programming to more formal software engineering methods, potentially leading to the development of re-usable class libraries.

Fig. 2 DesignScript introduces a number of intermediate techniques that provide a gentler learning curve for the designer who wants to progress from data flow diagramming to more forms of design computation.