Fig. 7 A simple computational design model implemented in an Imperative style of programming.
Fig. 8 A simple model implemented in an associative style of programming. Notice the reduction in the number of lines of code compared to the equivalent imperative code version. This is due to the use of ‘replication’ to handle the building of the collections of construction geometry rather than the use of iteration with ‘for’ loops found in the previous Imperative style of programming.
5 Hybrid Associative-Imperative Programming
DesignScript integrates both associative and imperative programming. In the following example (Fig. 9) the associative code (lines 32-56) are embedded in an imperative while loop. This effectively implements a simple solver which will re-compute the associative code, increasing the value of a driver variable (xHeight) until a test condition (volume <10) has been reached.
This example illustrates some important aspects of DesignScript. The designer can implement the same model building design logic in either imperative or associative code, but by harnessing the concept of replication associative code is often more compact and readable. However, a design computation system which only implements graph-based associative programming has difficulty expressing the concept of feedback, or iterative refinement and requires the use of specialised solver nodes. The disadvantage is that these solver nodes are not accessible or programmable by the designer and he cannot simply add his own solver, in an exploratory style of programing.
By contrast, DesignScript implements a hybrid imperative-associative approach to programming where code blocks from one style of programming can be nested within code blocks of another style of programming; both, associative blocks can be nested within imperative blocks and imperative blocks nested within associative blocks. This enables the designer to use and combine each style of programing where its unique strengths are relevant to the representation and execution of his design. In this example, associative programming has been used for model building, while imperative programming has been used for design iteration. Effectively, the designer has built his own custom design optimisation system.
Fig. 9 Associative-imperative programming, where the associative ‘model building’ code has been embedded within the Imperative ‘design iteration’ code.
6 Object-Oriented Programming, with User-Defined Classes
A further progression in sophistication is to create a solution space of design alternatives. In this example, the compact, associative model building code has been repackaged as the constructor of a user defined class (Fig. 10) and this class has then been instantiated with different values for two-driver variable, with the resulting design alternatives output as a 2D array (Fig. 10). This process of repackaging of existing code or code refactoring is itself an interesting example of the progression the designer may make. Starting initially with a more open-ended and exploratory style of programing, the designer can progress to a more formal software engineering approach which may be more suited to design documentation and re-use.
Fig. 10 The original associative ‘model building’ code is re-used as a constructor for new class
Fig. 11 A solution space has been generated by instantiating a user-defined class with a range of values for two different driver variables (number of columns in X and X height) to create a 2D solution space.
7 Conventional Imperative High-Level Languages, to Implement External Analysis and Simulation Tools
DesignScript is a .Net application, which allows any existing .Net library to directly instantiated in DesignScript. This allows the user to access existing analysis and simulation library or to build his own library of tools (Fig. 12).
Fig.12 An example of a multi-disciplinary design model created with DesignScript, using a mix of simulation and analytical techniques provided by the different available plug-ins, including: form-finding (with SmartForm), structural analysis (with Robot) and insolation on the shading devices (using Performative Design). The colour coding on the structural members indicates structural utilization, while the colour coding on the shading devices represents insolation. Note: the structural nodes on the periphery are fixed, the ones in the centre are free to find their correct position.
8 Conclusions
At the Design Modelling Symposium Berlin in 2011 [7], we presented (1) the concept of DesignScript as a “domain specific, end-user, multi-paradigm programing language” (2) that one of the programming paradigm would be new type of associative language acting as a human readable text based notation for data flow programing (3) the idea of a learning environment for design computation. This paper reports further progress in these directions. It is, however, very important to understand that it is not being suggested that associative programing is universally more advantageous than imperative programming. There are, however, two specific advantages where associative programming can contribute as part of a comprehensive computational system:
First for the novice programmer: The associative language offers a direct notational equivalent of a data flow graph node diagram and (via the node to code conversion] a way for the novice programmer to make the transition from data flow programming to text based programming as part of a design computation learning curve.
Second for the experienced programmer: There is the advantage of being able to choose between two different types of programme execution, either associative or imperative. Each is equally valuable and each may be appropriate in different contexts.
In fact, the example scripts (in Figs. 7-9) exactly illustrate a key idea that different programming paradigms match different ways of design thinking. On the one hand designing is characterised by the relationships between different aspects of the design, which can be expressed through a graph-based associative language, and on the other hand designing often involves a process of iterative refinement which can be represented by conventional imperative programming. Any serious design activity is quite likely harness both ways of thinking. Therefore if such a design activity is to be assisted by computational means then the two styles of programming and program execution are also required to be combined.
DesignScript is the integration of some original and some familiar computational ideas and forms of interaction, with the aim of providing a comprehensive learning environment for design computation.
Acknowledgements
DesignScript Development Team, Autodesk Singapore Research & Development Centre
Buro Happold for the SmartForm and Robot plug-in’s for DesignScript
Andrew Marsh for the Performative Design plug-in for DesignScript
References
1. http://en.wikipedia.org/wiki/Imperative_programming [08.08.13].
2. Green, T.; Blackwell, A., 1998: Cognitive Dimensions of Information Artefacts – A Tutorial, Version 1.2 [www.cl.cam.ac.uk/~afb21/CognitiveDimensions/CDtutorial.pdf 08.08.13].
3. http://en.wikipedia.org/wiki/Dataflow_programming [08.08.13].
4. http://cycling74.com/products/max/ [08.08.13]
5.