An Enhanced Programming Environment for Generative Design

An Enhanced Programming Environment for GenerativeDesign

Guilherme Ferreira

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Supervisor: Prof. Dr. António Paulo Teles de Menezes Correia Leitão

Examination Committee

Chairperson: Prof. Dr. Alberto Manuel Rodrigues da SilvaSupervisor: Prof. Dr. António Paulo Teles de Menezes Correia LeitãoMember of the Committee: Prof. Dr. Daniel Jorge Viegas Gonçalves

May 2016

Agradecimentos

Agradeço...

Pimeiramente à minha mãe pela sua dedicação e sacrifício, que mesmo passando por todas as dificuldades

diárias a que um imigrante é sujeito, acreditou no seu sonho e conseguiu proporcionar-me uma boa educação

e um futuro próspero.

À Adriana, pelo seu amor e parceria na luta diária, apoioando-me nas horas mais difíceis e fazendo-me

acordar quando já estava adormecido.

À Noire, a minha rafeira alentejana que passou a tese inteira a fazer-me companhia, ressonando enquanto

eu escrevia.

Aos meus amigos Bruno Fernandes, Aldemiro Costa, Rafael Baltazar, Samuel Coelho, Marcus Gomes, Se-

bastião Maya e André Rodriques, pelo apoio e companheirismo.

À Fundação para a Ciência e Tecnologia (FCT) pelo apoio financeiro para o desenvolvimento do projecto.

Ao Professor Dr. António Leitão pela sua grande sabedoria, honestidade e orientação, especialmente a

partir do momento em que comecei a minha vida profissional. As suas críticas muito asssertivas e as suas

sugestões inovadoras, foram um dos motivos pelos quais este trabalho conseguiu atingir o seu objectivo. Mais

que um professor, um grande amigo.

Ao Robby Findler pela paciência e interesse em ajudar-me, mostrando que um bom âmbiente de progra-

mação não se faz pelas suas ferramentas mas sim pelas pessoas que se dedicam ao seu desenvolvimento.

Ao Fábio Pinheiro e ao Rafael Reia, companheiros do INESC que passaram horas comigo a descutir e a

solucionar muitos dos meus problemas.

Ao Bruno Ferreira pela amabilidade de dividir a sua bolsa comigo nos primeiros meses da tese.

Ao gupo GAC, particularmente à Inês, à Renata, e à Sofia que aceitaram participar na avaliação do meu

trabalho e também ao Pedro Alfaiate, Artur e Guilherme Barreto pelas suas valiosas críticas e sugestões.

Para finalizar, aos meus familiares que acreditaram em mim e deram-me a força e motivação para atingir o

meu propósito, em particular aos meus tios, Joel, Rita, Juliana e Cristina, à minha avó Marly e à minha prima

Maria José.

“The best way to predictthe future is to invent it.”

– Alan Kay

Abstract

Increasingly more architects are moving from the traditional architectural processes and the classic forms of

architectural coding to a modern area called Generative Design. Generative Design (GD) is the application of

computational methods to design architectural structures or objects. In this area, designers write programs

that when executed produce geometric models. This movement is clearly visible both in the academia, with

current architecture curricula adopting programming courses, and in the industry, with design studios re-

placing traditional processes with computer applications. However, for the most users, the transition from

computer-aided design (CAD) applications to GD methods can be quite significant. Therefore, it is important

that GD systems encourage users to learn, giving them the necessary support to evolve their knowledge and

strategies. Unfortunately, the most used systems are not capable of responding to this need because they

are old or obsolete, or they do not enforce any good principle of software engineering such as document

code. To overcome this problem, this thesis proposes two programming tools for GD systems, namely (1)

sketch-program correlation tool that allows architects to use sketches and combining them with code, and (2)

immediate feedback tool that accelerates the effect of actions in the program output. We found that while the

first tool turns program documentation in a less tiresome task, consequently minimizing the lack of documen-

tation in the GD programs; the second tool enhances the program visualization, creating a new medium that

helps people to design programs. This thesis uses Rosetta tool to implement and validate the proposed tools,

clearly showing the advantages of this modern programming environment over the most used systems for GD.

Keywords: immediate feedback; image correlation; DrRacket; Rosetta

Resumo

Nos dias de hoje verifica-se uma clara evolução nas ferramentas utilizadas pelos arquitectos, havendo uma

substituição dos processos arquitectónicos tradicionais e das codificações arquitecturais clássicas para uma

nova área denominada Desenho Generativo. Desenho Generativo (DG) consiste na aplicação de métodos

computacionais na geração de objectos arquitecturais. Nesta área, designers escrevem programas que quando

executados produzem modelos geométricos. Este movimento é claramente visível tanto a nível académico,

com o actual currículo de arquitectura que adopta cursos de programação, como na indústria com ateliers

de design a substituírem os processos tradicionais por aplicações informáticas. No entanto, para a maioria

dos utilizadores, a transição dos processos tradicionais para os métodos de desenho generativo pode ser sig-

nificativamente difícil, pelo que é importante que os sistema de DG encorajem os utilizadores a aprenderem,

dando-lhes o suporte necessário para evoluirem o seus conhecimentos e estratégias. Infelizmente, a maioria

dos sistemas não é capaz de responder a esta necessidade por serem tecnologias antigas e obsoletas ou que

não imponhem qualquer bom princípio da engenharia de software, tal como a documentação do código. Para

ultrapassar este problema, esta tese propõe duas ferramentas de programação, nomeadamente (1) uma ferra-

menta de correlação-programa que permite aos arquitectos combinarem código com esquissos arquitecturais

e (2) uma ferramenta de feedback imediato que acelera o efeito das acções feitas no cógido mostrando-as

imediatamente no output do programa. Verificámos que a primeira ferramenta torna a documentação do pro-

grama numa tarefa menos cansativa, minimizando a falta de documentação dos programas de DG e que a

segunda ferramenta melhora a visualização do programa criando um novo meio de auxílio que ajuda o desen-

volvimento de programas. Esta tese utiliza a ferramenta Rosetta para implementar e validar as ferramentas

propostas, mostrando claramente as vantagens deste ambiente de programação moderno sobre a maioria dos

sistemas utilizados.

Palavras-Chave: feedback imediato; correlação com esquissos; DrRacket; Rosetta

Contents

List of Tables xii

List of Figures xv

Acronyms xix

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 5

2.1 A Programming Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Coding in Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Related Work 7

3.1 Programming System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 General-purpose systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2 LightTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Teaching systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1 LOGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.2 SmallTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.3 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.4 Fluxus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.5 DrRacket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.6 PythonTutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.7 YinYang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Empowering Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 DesignScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.2 Monkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.3 Rosetta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.4 Grasshopper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.5 Dynamo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.6 Mathematica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.7 IPython . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.8 MathCAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

xi

4 Designing a Programming Environment for Generative Design 25

4.1 Design Principles: a recurring need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Program Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Tools for documenting software programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2 Tools for documenting Generative Design programs . . . . . . . . . . . . . . . . . . . . . . 29

4.3 An approach for documenting Generative Design programs . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Sketch-program correlation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Dealing with images resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.3 Automatically binding code with images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.4 Designing a fallback mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.5 Presenting binding associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.6 Strategies to improve the usability in the source code editor . . . . . . . . . . . . . . . . . 36

4.4 Immediate feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 Immediate feedback in Generative Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.2 Immediate feedback tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.3 The activities of program experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.4 Improving program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.5 Program experimentation in Generative Design . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.6 Inline sliders mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.7 An inherent problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.8 Adaptive sliders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.9 Dealing with errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Implementing Programming Tools for Generative Design 43

5.1 Rosetta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 DrRacket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 Implementing the proposed tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.1 Program-sketch correlation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.2 Immediate feedback tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.4 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.1 General architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.2 Binding association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4.3 Image-data-snip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4.4 Auto Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Practical Experiments 59

6.1 The experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Program-sketch correlation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Immediate feedback tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7 Conclusions 67

Bibliography 69

xii

List of Tables

2.1 A programming framework. This framework summarizes the relationships between some issues

relating to programming. It should be read mainly by rows, that is, knowledge of planning

methods (required to design a program). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 System attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Time (in milliseconds) needed to update the generated geometry . . . . . . . . . . . . . . . . . . 45

xiii

List of Figures

1.1 An architectural sketch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1 Eclipse Integrated Development Environment showing Java perspective . . . . . . . . . . . . . . 8

3.2 LighTable interactive development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 LightTable real-time debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Directing the “turtle”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Smalltalk user interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 Fluxus engine being used as DrRacket module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.7 Typical DesignScript programming environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.8 Associative interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.9 Rosetta programming environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.10 A program in Grasshopper that computes the 3D coordinates of a conical spiral. Each time the

left sliders are dragged a new coordinate is calculated. . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.11 Dynamo search tab. Searching for a component, highlighted in red. . . . . . . . . . . . . . . . . . 20

3.12 Mathematica notebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.13 IPython browser-based notebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Javadoc generation of a HTML page from a documented Java method. In the left is the source

code commented with the opening tag /**, in the right is the generated documentation page. 27

4.2 Example of media-rich annotations supported by code editors. On the left is Barista editor

showing a Java method with richer annotations including images. On the right is the Codelets

implementation showing the inline helper with icons defined for mobile buttons. . . . . . . . . . 28

4.3 Typical example of sketches made during architectural design phase. . . . . . . . . . . . . . . . . 29

4.4 A real sketch of a chair seat. In this sketch, the seat is parametrized with some geometric

variables. Some of them are intuitively noticeable, e.g. the angle symbols δ, θ , and β , but rest

of them are not because they have its meaning embedded in the problem context. . . . . . . . . 30

4.5 A programming environment that helps in the program readability. On the left, is a sample

of code, written in the Processing language, that creates a green circle and rectangle. On the

right, is the result of this code. Each element of this program, including the functions and its

arguments, are labeled, so when the user points the mouse over an item its label appears in the

text editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 Sketch-program correlation tool showing how to combine fragments of the program with sketches.In

this example, all the function parameters are linked to a symbol in the sketch that illustrates its

meaning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.7 Opening the source code in an editor that supports the inline-img annotation. . . . . . . . . 33

4.8 Opening the source code in an editor that does not support the inline-img annotation. . . . 33

4.9 The suggested architecture for integrating the optical character recognition (OCR) Engine. This

architecture presents a data flow view combining two styles: pipe-and-filter style and client-

server style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

xv

4.10 Activity diagram for generating a set of seat shapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.11 A Grasshopper program. On the left, is the program inputs connected by sliders. On the right,

are the program components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.12 A slider user interface for the draw_arrow function. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Rosetta programming system. In the left, is the program written using Racket as the frontend.

In the right, is the program output using AutoCAD as the backend. . . . . . . . . . . . . . . . . . . 44

5.2 Orthogonal Cones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Scriptecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4 Möbius Truss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.5 Rosetta traceability tool, relating program expressions to the generated shapes. The highlighted

cylinders (on the left, in yellow) are produced by the highlighted expression (on the right, in

blue). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.6 Rosetta traceability tool, relating shapes to the program expressions that generated them. The

highlighted program flow makes the highlighted cylinders (on the left, in yellow) (on the right,

using red arrows). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.7 DrRacket programming environment, showing Definitions Window and Interactions Window

(in green) where users write and evaluate their code, and (in orange) the selected programming

language and the toolbar menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.8 Relating function arguments with image. The highlighted argument (under the cursor, in green)

is illustrated in the image (on the R symbol, using blue arrows). . . . . . . . . . . . . . . . . . . . 49

5.9 Relating image with function arguments. The parameter illustrated in the image (on the c

symbol, under the cursor) is highlighted in the code (in green, using blue arrows). . . . . . . . 49

5.10 Relating code comments with function arguments. The highlighted function name (under the

cursor, in green) is linked to its definition and utilization in the source code (in green, using

blue arrows). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.11 Relating function arguments with code comments. The highlighted function parameter (under

the cursor, in green) is linked to its utilization in the code comment (in green, using blue arrows). 49

5.12 Inserting in the text editor an image with large dimensions. The function body is separated

from its head definition due the large dimensions occupied by the image. . . . . . . . . . . . . . 50

5.13 Collapsing the image and some s-expressions. The code is collapsed, tidy, and the surrounding

context is still legible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.14 After inserting, in the text editor, the first image to illustrate the function parameters. The

arrows (in blue) come from the center of the image (under the cursor) to the highlighted pa-

rameters (in green). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.15 Choosing the correct position for the function parameter p. The coordinates of the point p (il-

lustrated in the image) as well as its correspondent function parameter is shown in the graphical

user interface (GUI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.16 Showing the correct binding association of the parameter p. . . . . . . . . . . . . . . . . . . . . . 51

5.17 Finishing the process setting all the image symbols in their proper place. . . . . . . . . . . . . . . 51

5.18 Using the Auto Run tool (in dark green) when writing the factorial function. The highlighted

expression is incomplete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.19 Immediately after closing the right bracket of the highlighted expression. The Interactions

Window is shown with the function result. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.20 Using the slider widget with Auto Run tool active, to experiment some input values. The high-

lighted function call (at line 13, on the left) is being changed by the slider (over the pointer).

On the right, are the generated shapes rendered by AutoCAD. . . . . . . . . . . . . . . . . . . . . 53

xvi

5.21 Diagram for a publish subscribe view of the proposed architecture. The arrow, in red, on top of

the symbol identifier module shows the implemented architecture. . . . . . . . . . . . . . . 55

5.22 The UML diagram of the implemented class, image-data-snip%. This class extends the orig-

inal DrRacket snip class, and implements its own read syntax method. . . . . . . . . . . . . . . . 57

6.1 After inserting a sketch in the function body. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 After correcting the associations between the function parameters and its symbols. . . . . . . . 60

6.3 Correlating existing sketches with code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.4 Collapsing the sketch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.5 Changing n-spheres input to 8 spheres using a slider. . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.6 Changing n-spheres input to 11 spheres using a slider. . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.7 Changing n-spheres input to 16 spheres using a slider. . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.8 Using a slider, on the left, to arbitrarily change a number value in the program. The angle

denominator has been modified to 3, producing, on the right, the turbine shape with its fans

placed over a circumference of 2π radians. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.9 Using a slider, on the left, to arbitrarily change a number value in the program. The angle

denominator has been modified to 6, producing, on the right, the turbine shape with its fans

placed over a circumference of π radians. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.10 Running factorial function using the slider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

xvii

Acronyms

API application programming interface. 14, 26, 35, 36, 47, 52, 56

AST abstract syntax tree. 28, 35, 39

BIM building information modeling. 16, 20

CAD computer-aided design. vii, 6, 16–20, 37, 38, 41, 43–45, 52, 67, 68

ES Empowering system. 22

GD generative design. 2, 16–20, 25, 26, 29–32, 37–39, 41–44, 48, 52, 53, 59, 67

GS General-purpose system. 22

GUI graphical user interface. xvi, 40, 51, 52

IDE Integrated Development Environment. 7–10, 28

JVM Java virtual machine. 9

OCR optical character recognition. xv, 34, 35, 50, 54, 67

REPL read-eval-print loop. 10, 14

TS Teaching system. 22

UI user interface. 9, 20, 34, 40–42, 54, 65

WYSIWYG what you see is what you get. 14

xix

1Introduction

In this chapter, I introduce the problem statement and the objectives of my work.

1.1 Problem Statement

Challenges in understanding programs are all too familiar since the early days of computing. At that time we

wrote programs in absolute binary (Hamming, 2003). It is a numeric representation typically expressed by a

sequence of zeros and ones, meaning that the programs were represented as a sequence of instructions and

addresses both written in binary. To understand a program in this form is almost impossible.

Since early days, as Fred Brooks pointed out in his influential essay (Brooks, 1987), we have come to

accept that there is no silver bullet to understand a program. Fortunately, in recent years, the field of program

comprehension (Rugaber, 1995) has evolved considerably, because a program that is not comprehended cannot

be changed, shared and communicated.

The area of program comprehension has shown that to understand a program, a silver bullet may not be

required. This field came up with several theories that provide rich explanations of how people understand

programs. For instance, the top-down theory (Brooks, 1977) says that to comprehend a program, the program-

mer must create a mental model of the program’s structure and behavior. This model is a set of hypothesis

which the programmer confirms or rejects based on evidence found in the code.

In response to these theories or in parallel with them, many environments and innovative tools were

created or updated. Some of the examples are: sophisticated frameworks to support rapid construction and

integration of tools (DesRivieres and Wiegand, 2004), advanced programming environments with intelligent

user interface (Carlson, 2005; Boudreau et al., 2002; Böck, 2011; Guckenheimer and Perez, 2006), and simple

tools designed for learning environments (Papert, 1993; Kay, 1996; Reas and Fry, 2006; Findler et al., 2002;

Guo, 2013; McDirmid, 2013). In parallel to these advances, there are other fields interested in program com-

prehension. For example, in the Architecture field, new tools (Aish, 2012; Lopes and Leitão, 2011) are being

proposed to support generative design: a procedural method for generating architectural models (McCormack

et al., 2004), that also suffers from program understanding problems.

Regardless the area, people follow two basic steps to build a program: first imagining its details, then

implementing them. This is a natural process for programmers that is commonly performed in their heads.

Architects, by contrast, prefer another medium to express their ideas: diagrams/sketches (Do and Gross,

2001), because it is a compact medium to convey complex ideas. For example, Figure 1.1 shows a sketch of a

geometric model which would be more complex, if it were described in text. These drawings are also helpful

in the end of design conception, because they clearly document the design decisions, the relationship between

1

Figure 1.1: An architectural sketch.

different parts of the design, and the impact of external factors in the final shape.

The generative design programs, by definition, can itself be considered a description of a design, as it

formally specifies the modeling process of the design. However, this formal specification can only be easily

understood for simple design problems. Consequently, the situation becomes the same of any sufficiently

complex program, then it is helpful to have program documentation.

Many problems related with program comprehension could be mitigated, if the programs were properly

documented. Source code comments is the most important artifact to understand a system and to maintain,

as showed in (Souza et al., 2005). Unfortunately, writing documentation is perceived as a tiresome task and,

thus, is frequently avoided (Sousa and Moreira, 1998), which negatively affects software development. A

result of the lack of program documentation is that programmers must spend a significant amount of time

separating relevant ideas from the irrelevant ones.

We think that, by creating well designed tools, it is possible to improve program comprehension and pro-

gram documentation. We plan to address this problem in two ways: (1) minimizing the lack of documentation

in the programs, by turning program documentation in a less tiresome task, and (2) creating a new medium

to help people design programs, by anticipating the effect of their actions in the program output.

1.2 Objectives

This thesis addresses two challenges:

• minimize the lack of documentation in generative design (GD) programs.

• improve the program comprehension by facilitating program experimentation.

To overcome these challenges, we investigated the flow which people follow to design programs in GD,

analyzing better techniques to help programmers at each conceptual task of this process. The goal is to develop

and implement innovative tools which support and encourage new ways of thinking, and therefore, enabling

programmers to see more easily and understand their programs.

Our approach to achieve this objective was, at first, analyze how programming tools can improve program

comprehension. The Learnable Programming (Victor, 2014, 2012) approach has shown interesting insights

in this direction. Secondly, based on this analysis, and in order to prove our ideas, we implemented two

interactive tools tailored for generative design programs:

1. Sketch-program correlation tool, which encourages architects and designers to reuse their conceptual

2

sketches, such as that shown in Figure 1.1, to visually document their programs. These sketches are

correlated with the program source code in a way that significantly reduces the effort to read the code.

Therefore, it allows users to acquire a better mental model.

2. Immediate feedback tool, which gives a new medium for architects and designers to create new ideas by

continuously reacting with changes in their models. This tool minimizes the latency between writing

the code and executing it, consequently this encourages users to experiment ideas quickly, augmenting

their comprehension about the program.

This thesis produced the following expected results: i) a specification of each tool, its purpose and how

this tool is designed to support its purpose, ii) an implementation of a prototype, and iii) an experimental

evaluation with a comparison to other similar tools.

3

2Background

In this chapter, I introduce the context and background for subsequent chapters. The first part addresses funda-

mentals concerning on teaching programming to novice students, and the relationship between programming

and the related issues. The second part introduces the generative design area focusing on its concerns.

2.1 A Programming Framework

Programming used to be taught mainly in computer engineering courses. In recent years the demand for pro-

grammers and student interest in programming have grown rapidly, and programming have become a subject

increasingly important in several areas of study. Learning to program is hard however. Novice programmers

suffer from wide range of difficulties and deficits. It is generally accepted that it takes about 10 years of

experience to turn a novice into an expert programmer (Winslow, 1996).

Why is programming such a hard subject to learn? What resources and processes are involved in creating

or understanding a program? Since the 1970s, there has been an interest in questions such as these, and in

programming as a cognitive process. The literature relating to such topics is extensive, and it divides into two

broad categories: those with a software engineering perspective, and those with a psychological/educational

perspective.

Learning to program is usually addressed from a psychological/educational perspective. However, our

interest is in novices and in how the programming environment can provide adequate tools to support the

initial development of individual programming skills. Early learning should, of course, include the basics of

good software engineering practice such as comprehend the program structures, documenting the program,

testing and debug among others.

Before proposing any feature, it is first necessary to research what are the main challenges in this area.

In fact, programming is beyond coding; it involves knowledge about computer, programming language, pro-

gramming tools and resources, and ideally theory and formal methods. As important as knowledge is the way

knowledge is used and applied, also known as strategy. Writing a program involves also maintaining many

different kinds of ‘mental model’ which is the way programmers comprehend its programs.

Table 2.1 (adapted from (Robins et al., 2003)) proposes a programming framework that makes explicit

the implied relationships between many of the issues found by novice programming. It highlights the relation-

ship between the individual attributes with the program phases namely design, generation, and evaluation.

Undoubtedly the three stages are critical. However, is in the generation phase where the novice is starting

programming and eventually usitn programming tools. This thesis will focus particularly on practical aspects

of programming environments that can introduce novices good practices of software engineering.

5

Design Generation Evaluation

Knowledge ofplanning methods,algorithm design,formal methods

language, libraries,environment / tools

debugging toolsand methods

Strategies forplanning,problem solving,designing algorithms

implementingalgorithms, coding,accessing knowledge

testing, debugging,tracking / tracing,repair

Models ofproblem domain,notional machine desired program actual program

Table 2.1: A programming framework. This framework summarizes the relationships between some issuesrelating to programming. It should be read mainly by rows, that is, knowledge of planning methods (requiredto design a program).

2.2 Coding in Architecture

In the architecture history, coding has been a means of expressing rules, constraints, and systems, which

are relevant for the architectural design process. In architectural design, code can be understood as the

representation of algorithmic processes that express architectural concepts or solve structural problems. Even

before the invention of digital computers, algorithms were applied and incorporated in the design process, as

documented in (Krüger et al., 2011).

Computers popularized and extended the notion of coding in architecture (M Rocker, 2006) simplifying

the implementation and computation of algorithmic processes. Increasingly more architects and designers

are aware of digital applications and programming techniques and are adopting these methods as generative

tools for the derivation of form (Kolarevic and de Velasco, 2000). Even though the improvements of direct

manipulation in CAD applications led many to believe that programming was unnecessary, the work of Maeda

shows the exact opposite (Maeda, 2001).

CAD software shifts from a representation tool to a medium for algorithmic computation (Terzidis, 2003).

Although the computational approach is transcending CAD limitations (Kilian, 2006), for traditional users the

transition from CAD applications to generative design methods can be significant. Therefore, is important that

the generative design systems were prepared to encourage users to learn, giving support for them to evolve

their knowledge and strategies.

In the next sections, I review the state of the art of programming systems, including the systems used in

Architecture. Then, I describe these programming environments including their programming languages and

programming tools.

6

3Related Work

In this chapter, I summarize related research on development environments and programming languages.

Work presented here focuses on the programming tools used in distinct contexts and situations, whereas

Chapter 5 discusses technical aspects and software architecture.

My work lies at the intersection of two main research areas: software engineering (SE) and generative

design (GD). Consequently, the related work includes advances in both of these areas.

3.1 Programming System

A programming system has two fundamental parts: the programming language that users should know to

create a program, and the programming environment that is used to write and test programs. Undoubtedly,

both parts are equally important to build a program and understand it. However the boundaries between

these components can be blurred, for this reason, the related work goes beyond programming environments

including also programming languages and their design aspects.

Based on prior surveys of novice programming environments (Kelleher and Pausch, 2005), in the follow-

ing sections I divide the programming systems into three categories: (3.2) general-purpose systems; proposed

for building sophisticated software, (3.3) teaching systems; intended to teach programming, and (3.4) em-

powering systems; proposed to build programs tailored to specific needs. In each category, I focus on the tools

provided by the programming environment.

3.2 General-purpose systems

The systems in this category are built to support all, or at least a substantial part, of the software development

process. To this end, these systems suggest an Integrated Development Environment (IDE) that aims to support

the entire development process by grouping in a single environment all necessary tools.

In this section we describe, in detail, two relevant IDEs: Eclipse (open-source) (Carlson, 2005) and Light-

Table (open-source)1. Other popular IDEs include NetBeans (open-source) (Boudreau et al., 2002), Microsoft’s

Visual Studio (commercial) (Guckenheimer and Perez, 2006), or Apple’s Xcode (free but closed-source)2.

Some IDEs (eg., Visual Studio or Xcode) primarily target the environment and ecosystem of the manufac-

turer’s own programming languages. The following study use those IDEs for the sake of comparison, because

they provide similar features to Eclipse or LightTable.

1http://lighttable.com/2https://developer.apple.com/xcode/

7

3.2.1 Eclipse

Eclipse (Figure 3.1), a project initiated in 2001 and promoted by a consortium of industry leaders (Carlson,

2005), is a widely used open-source IDE. It is used mainly by Java developers, although it supports additional

programming languages such as C, C++, and JavaScript. As showed in (Murphy et al., 2006), the commonly

cited reasons for using Eclipse include rich Java development tools support and a plugin architecture, the

Eclipse Platform (DesRivieres and Wiegand, 2004), that allows steady integration of third-party functionality.

The Eclipse platform (DesRivieres and Wiegand, 2004) has a similar design among the IDEs presented in

this category. This architecture has two main components, the plugin which is the smallest unit of functionality

that can be developed and delivered separately, and the platform runtime which will discover and connect the

plugins to the platform itself. As a result, the platform integrates several tools used in distinct phases of the

software development process. Figure 3.1 shows the IDE opened in the Java perspective, suggesting a quick

fix for the error.

Figure 3.1: Eclipse Integrated Development Environment showing Java perspective

Programming is a laborious task, even worse with a verbose programming language such as Java. For

example, while the developer is writing code he usually makes some errors, from lexical errors to semantic

errors, that he will only detect after compiling the code. So, he needs to stop his primary task to compile the

code and eventually debug it. This edit-compile-debug cycle is unproductive and naturally undesired in an

industry environment.

To prevent this problem, a standard feature among IDEs is the instant feedback. This feature aims to

anticipate the state of the current program by indicating eventual errors or mistakes made during development.

To provide instant feedback Eclipse is always compiling the code in the background, and giving immediate

feedback for the developer in the form of syntax highlighting, code completion suggestions, and indications

of problems associated with various locations in a source file.

In the literature a similar concept, known as liveness (Alpern and Schneider, 1985), referring to the ability

to modify a running program. There are several levels of liveness, and this kind of tool represent the first

8

level (Tanimoto, 2013). The tools in the first levels respond after an action while the tools at the last level not

only run the program and respond immediately but also predict the next programmer action. Having those

tools in a IDE would be the ideal. However, it is far from the reality of nowadays IDEs tools.

Before to idealize new features is important to highlight the drawbacks of the existent ones. Eclipse, as

the others similar IDEs, share some problems, as for instance:

• They are incidentally complex. There is an immense amount of work to be done in those IDEs that is in-

directly related to the real problem itself. For example, until the developer gets a simple program to run,

he needs to install, configure a set of necessary software, and he also needs to set up the development

environment. These are tiresome and time-consuming tasks that add extra complexity to programming

which is already a complicated subject.

• Program execution is hard to observe, such that the only way to see how the program executes is by

a stepwise debugger. This process forces the programmer to stop the program and look at a line in a

single instant of time. Therefore, the programmer cannot see how his program is executing, nor how

his changes affect its execution.

The complexity of install and configure an IDE negatively affects the programming language itself, because

users are more interested in the capabilities of the language than the IDE. To overcome this problem, recent

programming languages, such as Rust (Matsakis and Klock II, 2014), propose an IDE on the web browser3.

So users can write programs and use the language without any previous configuration. However this web

environment is suitable only for tutorials and small examples, otherwise to have full access to the language

users must pay the price to install and configure the language and the IDE.

3.2.2 LightTable

LightTable1 is a successfully crowd-funded project that indicates that instant feedback attracts wide interest

beyond the research community. Similarly, Apple has recently integrated a feature called Playgrounds into the

Xcode IDE. Playgrounds are enabled by Apple’s new programming language Swift4 and allow developers to

edit code and immediately see the results of the execution.

LightTable is based on Bret Victor ideas which in his influential work (Victor, 2014, 2012) pointed out

serious problems with the current environments and showed, using prototypes, how the environment can

help to address those problems. LighTable is proposed to build web application, to support this process,

it provides, at least, two useful features: (1) live execution feedback, that executes the program on every

change showing the program flow, and (2) the organization of code in tables, enabling quick access to the

program documentation.

LightTable was initially implemented in Clojure5 a general-purpose programming language dialect of

Lisp that runs on top of Java virtual machine (JVM). Progressively the code originally written in Clojure was

rewritten in ClojureScript6, a scripting language that uses Clojure compiler which targets JavaScript. Due to its

implementation, in LightTable adding a new user interface (UI) element into the programming environment or

changing an existing one is doable in a short amount of time, contrary to other IDEs, such as Eclipse (Carlson,

2005), where an equivalent change requires considerable amounts of time.

3https://play.rust-lang.org/4https://developer.apple.com/swift/5https://clojure.org/6http://clojure.org/clojurescript

9

Figure 3.2: LighTable interactive development environment

LightTable provides a lateral panel for ease documentation access so that users can read any primitive

functions of Clojure or ClojureScript. This documentation is a textual description of the function parameters,

the type of return, and some usage suggestions. While looking at a program, it is helpful to have the docu-

mentation of strange primitives, such as the keyword function, shown in Figure 3.2, however, non-primitive

functions are still undocumented.

Figure 3.3: LightTable real-timedebugger.

On the other hand, programmers are encouraged to understand new

functions by seeing how the values of a function call flow through it. This

feature is based on the old idea of Lisp environments: the read-eval-print

loop (REPL) which is a prompt used to try out expressions of the language

without having to run all the code. This approach goes further by using

reflection mechanisms to trace the function call values and shows them

filled in the function template (as shown in Figure 3.3 the flow of values

produced by calling (x 3 7)).

The real-time debugger is an interactive way to debug the code and

understand the program flow. Using this feature in an arbitrarily complex

program (a program with more than 30 functions) is, however, worthless,

because, all the programmer sees is a replica of his functions filled with numbers. It is a poor representation

of flow which forces the developers to spend as much effort on this feature as without it. For this reason,

other systems, described in this report, represent the program flow using graphs which are more appropriate

in some cases, for example, to show error occurrences in the source code.

Despite providing some tools which are state of the art, LightTable remains in an experimental phase. It

has severe limitations to identify and clearly present the errors in the source code. This problem is, mainly,

related with the Clojure compiler which loses significant metadata between conversions. Consequently, pro-

grammers can spend more time and effort to find a bug using LighTable, than using the other IDEs, such as

Eclipse.

3.3 Teaching systems

Unlike the previous systems, teaching systems are designed with the goal of helping people learning to pro-

gram. Most of the systems in this category provide simple programming tools that expose the novice pro-

grammers some of the fundamental aspects of the programming process. After acquiring experience with a

teaching system, students are expected to move to a more general-purpose environment.

10

3.3.1 LOGO

LOGO (Papert, 1993) is a programming language and environment intended to allow children to explore a

wide variety of topics such as physics and mathematics. The programming language is a dialect of Lisp, with

much of the punctuation removed to make the syntax accessible to children, it uses a helpful metaphor which

facilitates the introduction of programming concepts.

In Logo, the novice programmers draw pictures by directing the “turtle”, an onscreen character which

leaves a trail as it moves (see Figure 3.4). The turtle is a metaphor that helps learners to translate their

experiences as a person into programming knowledge. That means, to figure out how to make the turtle

perform an action, the programmer can ask how he would perform that action himself as if he were the turtle.

Figure 3.4: Directing the “turtle”.

For example, to figure out how to draw a circle, a learner

would walk around in circles for a bit, and quickly derive a “cir-

cle procedure” of taking a step forward, turning a bit, taking

another step forward, turning a bit. After teaching it to himself,

the learner can then teach it to the computer.

LOGO has influenced several systems, and its principles

show how a system can be designed around the way people

think and learn.

3.3.2 SmallTalk

SmallTalk (Kay, 1996) is a programming language and environment to support children in the world of infor-

mation. The designers of this system wanted to create a programming language that had a simple model of

execution, and a programming methodology that could accommodate a wide variety of programming styles.

SmallTalk was based on three ideas: (1) everything is an object, (2) objects have memory in the form of other

objects, and (3)objects can communicate with each other through messages.

Figure 3.5: Smalltalk user interface.

Smalltalk programming environment was an

achievement with consistent improvements on its

successors. The system consisted of about 50 classes

described in about 180 pages of source code (Kay,

1996). This included all of the OS functions, files,

printing and other Ethernet services, the window in-

terface, editors, graphics and painting systems, as

shown in Figure 3.5.

In the Smalltalk programming language, the

communication through messages has a strong reso-

nant metaphor. To specify the behavior of an object,

the programmer casts himself into the role of that ob-

ject (to the extent of referring to the object as “self”)

and thinks of himself as carrying on a conversation

with other objects. This is a strong metaphor because

role-playing and conversing are innate human facil-

ities.

In fact, SmallTalk features are, nowadays, a con-

11

sistent reference for any programming system.

3.3.3 Processing

Processing (Reas and Fry, 2006) is a programming language and environment designed to teach programming

in an optic context. Processing has become popular among students, artists, designers, and architects because

it acts as a tool to get non-programmers started with programming through instant visual feedback.

The Processing programming language is built on top of Java, but it removes much of the verbosity of

Java to make the syntax accessible to novices. The language provides simple access to external libraries,

such as OpenGL, through single entry points, such as setup and draw. Therefore, this allows novices to

quickly prototype, learn fundamental concepts of programming, and, eventually, gain the basis to learn other

programming languages.

The programming environment contains a simple text editor, a text console to present errors, and a run

button. The run button compiles the Processing code and executes it. Moreover, in the default mode, the

program result is displayed in a 2D graphical window, the render can be configured to present the result in

3D, or other sophisticated methods using shaders to recur directly to the graphic board.

Actually, with a few changes, the Processing code can be exported as an application for different platforms,

such as Java, JavaScript, and Android. For example, to export a Processing program for JavaScript, it is only

necessary to create a HTML page and include the Processing code as a script of this page. Then the Processing

code will be automatically parsed and translated to JavaScript. To maintain the usual render capabilities of a

Processing program, it will use the HMTL5 canvas with WebGL.

The popularity of Processing is explained by the benefits of these features, besides of being a domain-

specific language. However, it has drawbacks that can discourage its use, such as the following:

• Weak metaphor. The Processing programming language, by contrast with the above systems, has none

strong metaphors that allow the programmer to translate his experiences as a person into programming

knowledge.

• Poor decomposition. Processing discourages the elementary approach to solving a complex problem by

breaking it into simpler problems because drawing and input events link to single entry points. Thereby

the behavior of submodules must be tangled across these global functions, making it difficult to achieve

clean decomposition.

• Poor recomposition. Processing discourages combining two programs. The designer cannot just grab and

use part of other programs because variables must be renamed or manually encapsulated, and the draw

and mouse functions must be woven together. Even worse, Processing has global modes which alter

the meaning of the function arguments. For example, two Processing programs can specify its colors in

different modes and each mode has its proper purpose of fill function arguments. Combining those

programs will be almost impossible.

• Weak readability. The syntax of a Processing program represents a significant barrier for reading. For

example, the function which draws an ellipse on screen is written as ellipse(50,50,100,100). The

reader must look up or memorize the meaning of every single argument.

• Fragile environment. The programming environment is fragile because it does not attempt to solve any

of the above issues related to the language and its implementation.

12

3.3.4 Fluxus

Fluxus (Griffiths, 2007)7 is a programming language and learning environment designed for rapid prototype

using 3D graphics and sounds. This emphasis on the primitive prototype and instantaneous feedback makes

Fluxus a tool for learning computer animation, graphics, and programming. However, most users of Fluxus

use it for livecoding, which is the act of performing coding lively to an audience.

Fluxus is mainly written in C++, and it links statically to several shared libraries, specified at compile

time. For instance, Fluxus uses jack-audio, ode, and fftw libraries to handle and synchronize the audio,

GLEW to present graphics, and racket3m to embed the Racket run-time system into the application. In this

way, Fluxus is an extension of Racket (a descendant of Scheme) with graphical commands.

Like Processing, Fluxus provides direct access to those libraries through single entry points, for instance,

start-audio connects an input audio to the application, every-frame registers a function called once per

frame, and so on. However, as stated above, it is a barrier for decomposition since the behavior of submodules

must be tangled across these global functions.

Figure 3.6: Fluxus engine being used as DrRacket module

Fluxus has its environment specifically tailored for livecoding. It has a OpenGL graphical window with a

simple text editor. The performer types his code in the editor and presses a shortcut key each time he wants

to run it. Fluxus evaluates the code through Racket run-time system, showing the result in the same graphical

window, also used as a text editor. This mechanism is valuable in a livecoding environment, because the

performer can be editing the code while maintaining at the background, the result of the previous computation.

However, if the code has any error and the performer execute it, the previous calculation disappears, and the

environment will not help to find it. In fact, this is a serious problem, especially for the Racket syntax.

Moreover, Fluxus shares with Processing similar drawbacks to those previously stated. However, Fluxus

can be used as a module of DrRacket (Figure 3.6) (Findler et al., 2002) programming environment. Fortu-

7http://www.pawfal.org/fluxus/

13

nately, DrRacket solves the above problem and many others.

3.3.5 DrRacket

DrRacket (Findler et al., 2002) is a programming environment designed to support the Racket language.

DrRacket is one of few programming environments which supports continuous learning in a more general

language from the start. Consequently, it has been widely used in introductory programming courses in several

universities around the world.

DrRacket is usually used to introduce the fundamentals of programming. To facilitate this process, Dr-

Racket provides three tools. The first is a symbolic stepper. It models the execution of Racket programs as

algebraic reductions, once Racket is implemented on top of lambda calculus. The second tool is a syntax

checker. It annotates programs with font and color changes based on the syntactic structure of the program. It

also permits students to explore the lexical structure of their programs graphically and to α-rename identifiers.

The third tool is a static debugger that infers which set of values an expression may produce and how values

flow from place to place in the source text, and, upon demand, it explains the reason of errors by drawing

value flow graphs over the program text.

Similar to Lisp environments, DrRacket provides a read-eval-print loop (REPL). A command prompt in-

tended to evaluate expressions quickly and print their results. Particularly in a learning environment, this fea-

ture makes an important connection between program execution and algebraic expression evaluation. How-

ever, the Lisp-style syntax obscures the effect of this feature. To overcome this limitation, DrRacket provides a

pretty-printer. A module capable of printing algebraic expressions in a meaningful way, as well as other

graphics elements supported by the text editor, such as images, snips, XML boxes, and so on.

More recently, DrRacket has included picture boxes for what you see is what you get (WYSIWYG) layout

of slide content that is otherwise created programmatically (Findler and Flatt, 2004). This kind of presentation

extensibility is in addition to recognizing standard Racket hygienic macros. There are several problems with

this approach. First, there is no documented protocol for creating new kinds of boxes. Second, programs that

use media-rich elements are stored as an ASCII-encoded binary which is hard to edit outside DrRacket editor.

Last, the semantics of the boxes is driven off of the display itself, rather than the persistent store; therefore, to

compile, interpret, or edit the program, a box-aware editor is required.

From the perspective of professional developers, DrRacket can be a potential target. It is useful for de-

veloping complex applications, including DrRacket itself. Moreover, it is extensible by the same application

programming interface (API) which the above tools implement. Through this API it is also possible to extend

the REPL, as in Pict3D8 (a 3D engine that integrates new graphical elements in the DrRacket environment).

On the other hand, for supporting extensions, DrRacket’s architecture has become increasingly complex. For

instance, to make a simple change in an editor’s element the developer should be able to understand several

modules, unrelated with the problem itself. This extra complexity is a negative impact when DrRacket is

chosen as the basis for new development tools.

Despite the identified advantages, DrRacket has some barriers that may discourage the learner. For ex-

ample, the Racket programming language is simple to teach, but its heavy syntax of s-expressions hinders the

student to read the program. Consequently, the learner can spend a considerable mental effort to understand

insignificant details of the language.

8https://github.com/ntoronto/pict3d

14

3.3.6 PythonTutor

PythonTutor (Guo, 2013) is a web-based program visualization tool, designed to explain how a piece of Python

code executes. It has become popular among students from introductory Computer Science courses. Using

this tool, teachers and students can write Python programs directly in the web browser and navigate step by

step throughout its execution, seeing the run-time state of data structures.

PyhtonTutor has two main modules: the backend which implements the core tool functionality, and the

frontend which presents the visualization of program’s data structures. The backend executes the input pro-

gram under the supervision of the standard Python debugger module (bdb) which stops execution after every

executed line and records the program’s run-time state. After execution terminates, the backend encodes the

program state in JSON format, serializing Python data types into native JSON types with extra metadata tags

and sends it to the frontend. The frontend renders the objects using standard web technologies: HTML, CSS,

and JavaScript. In this way, users can use the tool without installing any extensions or plugins.

A major concern in PythonTutor is security because the PythonTutor’s backend executes untrusted Python

code from the web. To prevent the execution of dangerous constructs such as eval, exec and file I/O,

PythonTutor implements sandboxing. It denies the use of most module imports, by parsing the user’s code

importing, a strict approach, but effective in this case.

The PythonTutor tool allows the programmer to follow the program execution over time, but he only

sees a single point in time at any instant. There is no visual context at all. The entire program flow shows

disconnected points in time. For example, the programmer who wants to understand a conditional algorithm,

using this tool will not see the pattern of this algorithm neither read it at a higher level.

3.3.7 YinYang

YinYang (McDirmid, 2013) is a prototype of a programming language and environment whose main feature is

the live execution feedback. That means it combines editing and debugging, where updated debug results are

conveniently visible while editing. YingYang addresses the above issue in two ways. First, just like the previous

system, it allows programmers to see single points of execution directly within the code editor (probe; precede

expressions with @ operator). Second, it has a pane aside the editor which traces execution with entries that are

navigable (trace; print-like statements). Basically, the trace is an enhanced display function which, combined

with “probes”, allows the state of previous executions to be restored. So, programmers can take in the entire

program flow at a glance and navigate trough it using probes.

YingYang uses an incremental framework as the basis of its programming model. This framework de-

composes the program execution into a tree of nodes that can be re-executed independently on code or input

change. However, this decomposition cannot be performed transparently. It requires programmers to spec-

ify how to decompose the program. To accomplish this task, one must genuinely understand the granularity

and modularity characteristics of the computations being performed by the program. Otherwise changes can

sometimes have an immense impact on program re-execution time (∼50ms). Consequently, live programming

would actually reduce programmer productivity as developers wait for slow feedback.

Although YinYang provides usable features for a learning environment, such as the live execution feed-

back, it does not have a suitable language for beginners. The language is merely experimental, and to navigate

through the program execution, developers must include probes in the code. At the end of experimentation,

the code is full of useless expressions.

15

3.4 Empowering Systems

In this category of systems, the most important aspect is to allow people to build programs tailored to their

needs. In this section, I describe how systems from two distinct areas are adapted to achieve their user’s needs.

First, I consider Architecture, where new programming languages and environments are being proposed

to support the increasing use of GD (McCormack et al., 2004). GD is a design method that uses algorithms to

generate architectural models. Usually, these models are rendered using a CAD tool.

Second, I consider Mathematics, where advanced technologies are used to approximate as much as pos-

sible the mathematical models to the ones that we can see and understand.

3.4.1 DesignScript

DesignScript (Aish, 2012) is a programming language and environment designed to support GD with textual

methods. It is mainly used by architects and designers to generate geometric models using a script. Then

when the script executes it creates new models in a CAD tool. DesignScript is an AutoDesk9 product initially

proposed to be used within AutoCAD (as shown in Figure 3.7), nowadays it provides the same functionality

on top of Revit, another AutoDesk product used for building information modeling (BIM). In short, a BIM

model is similar to a CAD model, but it covers more than just geometry. It also includes spatial relationships,

properties of building components, such as manufacturers’ details.

Figure 3.7: Typical DesignScript programming environment

The programming language is an associative paradigm. The variables are abstract types that can represent

numeric values or geometric entities. These variables are in a graph of dependencies. When a change in a

variable occurs it forces the re-evaluation of the graph, as shown in Figure 3.8, consequently variables has

always updated values. This feature is useful, especially in a modeling environment, because it provides

continuous feedback to the designer as the model is modified.

9http://www.autodesk.com/products

16

Figure 3.8: Associative interpretation

The DesignScript’s programming environment pro-

vides a text editor, an interpreter, and a simple debugger.

The language interpreter executes each time that the de-

signer clicks on the run button. Then all the script is inter-

preted, and its result produces geometric entities rendered

in the CAD. The continuous feedback feature works only in

debug mode because, in this way, the script is interpreted

line by line. Thus, each update to a variable will change its dependencies and will recompute the model.

However, in debug mode the code cannot be edited, so this feature is worthless during code editing.

In the DesignScript’s debug mode, users can inspect the variable values by adding watchers to them. A

watched variable is showed in a particular tab, as shown in Figure 3.8. In case the variable represents a

geometric model, the own design will be highlighted in the CAD when the variable is selected. It creates

a certain traceability between patterns in the CAD and code in the editor. In this way, the user is able to

correlate which model a variable corresponds. However the inverse, starting to form the model and finding

the correspondent variable, is unsupported.

DesignScript also supports a typical mechanism of live programming environments: the sliders. The

sliders are widgets which facilitate giving new values to the program input. This way, designers can create

new models reacting to these changes. However, in the DesignScript’s sliders, the changes are reflected in the

models only when the programmer leaves the slider. Until then, the designer should imagine how the model

would be with the new value, which is completely against the purpose of sliders.

Moreover the DesignScript language, despite being presented as pedagogic, has some drawbacks. It does

not carry any manly metaphor which helps beginners start with the language. Additionally, the associative

paradigm represents a barrier for sharing code: it discourages the recomposition of modules because new

modules can change the previous one. The environment provides poor mechanisms that help people to find

bugs in the code, and finally, DesignScript is confined to produce geometry in a single CAD tool.

3.4.2 Monkey

Monkey10 is a programming environment designed to support GD. Like DesignScript, Monkey is used to

edit, debug and interpreter scripts. However, Monkey uses RhinoScript as its programming language and

Rhinoceros3D11 (or Rhino for short), a lighter CAD than AutoCAD, to generate the geometric models.

Monkey is implemented as a .NET plugin for Rhino4 and provides a programming environment to write

and debug scripts. The RhinoScript is based on Microsoft’s VBScript language (a descendant of BASIC), and

like VBScript, it is a weakly typed language. One of the major drawback with this language is the fact that

users must beware with the data passed in their functions at all time because RhinoScript can accidentally

cast variables into inappropriate types. Therefore, it creates errors difficult to find, especially for people who

are learning to program.

Monkey is based on general-purpose programming environments. It provides typical features of those

environments, namely syntax highlighting, auto-completion, and error highlighting. The organization of code

into trees is also similar. However, the programming environment and language do not provide any well-

designed feature which helps beginners to start with programming. The offered features are based on general-

purpose systems, instead of being tailored for GD.

10http://wiki.mcneel.com/developer/monkeyforrhino411https://www.rhino3d.com

17

3.4.3 Rosetta

Rosetta (Lopes and Leitão, 2011) is a programming environment designed to support GD that is based on

DrRacket (Findler et al., 2002). Like Monkey, Rosetta provides its environment detached from the CAD.

Rosetta is a step forward from the previous systems, because it solves the portability problem among CAD tools.

In Rosetta a GD program can be written in various programming languages (frontends) and the geometric

models can be rendered by different CADs (backends). As a result, designers are free to write their programs

in their selected frontend which, upon execution, will generate the same geometry for the various backends.

In Figure 3.9, a program is written in Racket, and its execution produces geometry for AutoCAD.

Figure 3.9: Rosetta programming environment.

Rosetta has been used to teach programming in architecture courses. Tailored to this end, Rosetta uses

DrRacketas its programming environment. The DrRacket environment serves some functions, but the most

important are that the student can start immediately to learn to program. For instance, the environment is

set up with just three lines of code. As shown in Figure 3.9, the #lang specifies the frontend language, the

require imports Rosetta’s primitives and finally the backend names a possible backend.

The Racket language is also an advantage of Rosetta’s environment because it encourages the use of the

scientific paradigm for writing algorithms. In this way, students that learn simple programming techniques,

such as recursion, can create robust models. Additionally, as the students progress, new programming lan-

guages are also available to learn, such as JavaScript, Python, Processing, and so on.

The Rosetta’s environment provides some interesting tools for GD, such as a programming flow tracer,

similar to the DesignScript’s watcher. It highlights models in the CAD upon selection of expressions, it also

supports the inverse, selecting the mode in the CAD and shows the expression in the code editor. Another

interactive tool is the slider, an attempt to provide immediate feedback to the designers. It uses the DrRacket

slider, associating the slider callback to the function that generates the entire model, so each time the slider

change a new model will be created. However, this process must be performed manually.

18

Undoubtedly Rosetta’s environment goes further than the textual environments for GD presented in this

report. However, it presents some drawbacks which may discourage the learning in general. Beginning with

the usual programming language: Racket. The syntax of a Racket program represents a significant barrier for

reading. For instance the function which draws a circle in Rosetta is written as (circle (xy 0 0) 1). The

reader must lookup or memorize every argument. Using the Rosetta’s documentation the reader will spend

even more time because it is in a book mixed with architecture topics.

3.4.4 Grasshopper

Grasshopper12 is a programming language and environment designed to support GD using a visual language.

Grasshopper provides an alternative way to programming. By definition, it is a bi-dimensional representation

consisting of iconic components that can be interactively manipulated by the user according to some spatial

grammar (Myers, 1990). For example, the boxes in Figure 3.10 are components which receive the input (left

ports) perform some operations and return the output (right port). The components link to other elements

establishing a dataflow paradigm where the input of an element is the output of another.

Figure 3.10: A program in Grasshopper that computes the 3D coordinates of a conical spiral. Each time theleft sliders are dragged a new coordinate is calculated.

Like Monkey, Grasshopper is implemented as a plugin for Rhino11. However, Grasshopper tailors the

Rhino’s environment with specific GD tools. These tools are state of the art because they implement important

principles for design models, such as the following:

• Get immediate feedback. As the user interacts with the components, by adding and connecting them,

the result reflects immediately in the CAD model. It facilitates the design conception because the user’s

intentions are immediately visible.

• Facilitate program input. To facilitate the process of design exploration, Grasshopper provides sliders

which connect at the component input. Dragging the slider causes a change propagation through com-

ponents. The components are re-executed with the new slider value. Combined with the above feature

new models are generated immediately.

• Correlate the program with the generated elements. Like DesignScript’s watcher, by selecting a component,

its geometry is highlighted in the CAD. It allows designers to understand a program better by figuring

out the roles for each element.

• Show comparisons between models. Grasshopper provides a special component that, when connected to

the output of another component, replicates the geometry. This mechanism is useful for design explo-

ration because it maintains in the CAD’s background an old replica of the changed geometry. It adds a

context at each change so that the designer can compare the result of his change in the new geometry

based on the old one.

12http://www.grasshopper3d.com/

19

Mainly, the Grasshopper interactivity depends on the immediate feedback tool. However, this tool will

never scale for arbitrarily complex programs because the CAD’s render is not designed to process the massive

amount of information generated by GD methods. Other systems, such as DesignScript and Rosetta, improve

this problem by sidestepping most of the functionality of traditional CAD tools and focusing only on the gen-

eration and visualization of geometric models. These systems provide a backend based on OpenGL that is

independent of a full-fledged CAD application, but, in Grasshopper, there is no so backend.

Moreover, the traceability among components is just in one direction. From the designer perspective, it

would be more useful start from the geometry and find which component implements it, but it is unsupported.

However, despite the usefulness of model comparison in design exploration, this feature is also unsupported.

3.4.5 Dynamo

Dynamo13 is a programming language and environment designed to support GD. Like Grasshopper, Dynamo

provides an alternative way to programming. However Dynamo, like DesignScript, is implemented on top of

Revit, an Autodesk product for BIM.

Figure 3.11: Dynamo search tab. Searching for a com-ponent, highlighted in red.

Dynamo provides a set of tools similar to

Grasshopper, particularly a searching table, as shown

in Figure 3.11, which provides quick access to the

primitives of the language, such as the components

and widgets. This feature encourages designers to

explore the available parts and try current compo-

nents.

In general, Dynamo and Grasshopper are pro-

gramming environments and visual languages pop-

ular among novices in programming. The smooth

learning curve and perhaps the style of the UI ele-

ments are attractive for beginners. However as the

visual programs become broad and complex, it requires more time to understand, maintain, and adapt to new

requirements, than the textual programs as showed in (Leitão and Santos, 2011). Despite spending more time

and effort to learn a textual programming language, the learners have their time quickly recovered once the

complexity of the design task becomes sufficiently large.

3.4.6 Mathematica

Mathematica (Wolfram, 1991) is a language and environment built to support scientific calculation. It is widely

used in the scientific community, especially by students, because it represents programs using an abbreviated

artificial language. This language supports not just direct textual input, but also two-dimensional information,

like traditional mathematical notation.

The core concepts of Mathematica are based on the paradigm initiated by Turing’s work (Wolfram, 2003).

In this model, Mathematical processes are systematized as computations. For example, in a typical interac-

tion, the user types a mathematical expression in the Mathematica environment (i.e. notebook), then this

expression is evaluated, as shown in Figure 3.12.

A relevant aspect of Mathematica’s notebook is the immediacy that users get a response. Unlike a typical

13http://dynamobim.com/

20

Figure 3.12: Mathematica notebook

program that must be executed explicitly to get a feedback of an action, in this notebook expressions are

evaluated as soon as they are typed. It works like a read-eval-print loop. However, it has enhanced mechanisms

to present data meaningfully.

The Mathematica features are well designed to display information in a human readable form. It would

be useful for external programming languages if it could take advantage of these functions. Unfortunately,

Mathematica is closed for this end.

3.4.7 IPython

IPython (Pérez, Fernando and Granger, Brian E., 2007) is a programming environment built to support scien-

tific calculation. Unlike Mathematica (Wolfram, 1991), IPython is an open platform for extensions; it allows

external programming languages (frontends) to use its features which includes an interactive shell, and a

browser-based notebook with support for code, text, mathematical expressions, plots, and other rich media.

Like Mathematica, IPython has a notebook where users can try out expressions and immediately see its

result, as shown in Figure 3.13, however, this notebook is in a web format. IPython’s architecture is a typical

client-server, where the frontend is the client (i.e. the notebook), and the server is a language kernel (i.e. the

programming language which users interact with). The communication between client and server is through

a strict protocol that the language kernel must implement.

IPython provides a base layer for new programming environments, by exposing the major components of

its architecture. Consequently, its features are available from other systems. For example, IJulia uses IPython

interface with Julia language.

21

Figure 3.13: IPython browser-based notebook

3.4.8 MathCAD

MathCAD14 is a programming environment and language built to support scientific calculation. Like Mathe-

matica, MathCAD aims to present information in a human readable form. However, it generates live calcula-

tions with graphical plots, text, and images into a single document. This document is the program environment

as well as the final product.

The mathematical expressions defined in the MathCAD document act as an associative language. So,

when an expression changes its value is propagated through the document. This mechanism is the base of

the interactiveness. However, it represents a barrier for program recomposition, because new expressions

can change the previous ones. That means that variables have a global scope, the MathCAD document if in

somewhere a variable is changed it will be changed in every occurrence in the document.

3.5 Summary

Table 3.1 shows the presented systems based on their major design influences. The table is also intended to

address the following questions:

(1) What is the purpose of the system? We categorized three main goals for a system. General-purpose

system (GS) designed for building complex software for the industry; Teaching system (TS) designed to help

people learn how to program; Empowering system (ES) designed to help people create things that are tailored

to their needs.

(2) How does the system support its purpose? We identified the following strategies: (i) support software

development life cycle, (ii) turn programming in something more observable, (iii) create an understandable

language, (iv) combine textual programming with a visual context, (v) support gradual learning in a single

environment, (vi) show the program flow, (vii) support generative design methods, (viii) find alternative ways

14http://www.ptc.com/product/mathcad

22

Type(1) System Main feature(2)Support to understandprograms(3)

Representation of code(4)

GS

Eclipsesupport softwaredevelopment life cycle

debugger

text

NetBeansIntelliJMVS

Xcodeobservable programming live execution feedback

LightTable

TS

LOGOunderstandable language physical interpretation

SmallTalk

Processingvisual context instant visualization

Fluxus

DrRacket gradual learning debugger; stepper

PythonTutorshow program flow

navigate through theprogram executionYinYang

ES

DesignScriptsupport generative designmethods

debuggerMonkeyRosetta

Grasshopper alternative way toexpressing programs

dataflow paradigm graphical componentsDynamo

Mathematicasupport scientificcalculation

present data meaningfully mathematical formsIPythonMathCAD

Table 3.1: System attributes

for to express programs, and (ix) support scientific calculation.

(3) Does the programming environment provide additional assistance to enable users to understand the behav-

ior of their programs better? Environments in our study used several techniques to help users understand the

behavior of their programs. These included (i) a debugger which contributes to find bugs in the program, (ii)

an enhanced debugger which provides live execution feedback, (iii) languages with strong metaphor allowing

physical interpretation, (iv) instant visualization of models, (v) navigation through the program’s execution

(vi) assembling components in a dataflow paradigm and (vii) present data adequately.

(4) How does code look in the programming environment or language? The systems in our study represent

programs using text, users can type, graphical components, users can manipulate, and mathematical forms

users can fill in.

3.6 Conclusion

In the surveyed systems, the typical representation of code is textual. This representation is typically static

and, to be understood, requires the reader to know the vocabulary of the programming language. For a novice,

it is simply a barrier to learning. On the other hand, the representation of programs as graphical components

or mathematical forms lowers this barrier, because the information is visually more perceptible, but it becomes

incomprehensible as the program grows.

23

4Designing a Programming Environment forGenerative Design

This chapter presents the design of a coherent system integrating the previously studied techniques for interac-

tive programming. The first part discusses the importance of good design principles in software engineering,

highlighting the lack of tools that enforce those principles in the current programming systems, especially

in the Architecture area where programming methods are increasingly popular. The second part introduces

concrete tools for documenting a program and proposes a framework for providing immediate feedback as

the developer write his code. While the following chapter discusses technical aspects and the software archi-

tecture, this chapter elaborates on the rationale behind all design decisions.

4.1 Design Principles: a recurring need

Programming is hard to learn. Unfortunately, as shown in the previous sections, few programming languages

or environments are intended to introduce the basics of good software engineering practice. Especially in

Architecture, the environments used to support GD either they are old or obsolete, or they enforce particular

programming methods that are inadequate, or they are not pedagogic, meaning that they are not designed

for the specific programming skills of the GD community.

The literature in this area is vast, but it is clearly divided into two perspectives: software engineering

perspective, or psychological/educational perspective. Which means that systems are either designed for expert

programmers (Carlson, 2005; Boudreau et al., 2002; Böck, 2011; Guckenheimer and Perez, 2006; Granger,

Jan. 2014), or for novices programmers (Papert, 1993; Reas and Fry, 2006; Guo, 2013; Goldberg and Robson,

1983). However, in the set of systems presented in Chapter 3, is very unlikely a system that implements these

two perspectives, allowing users to evolve their knowledge about programming gradually, without having to

change to another environment. Even worst, the systems designed for novices usually offer a reduced set of

programming tools, which consequently restricts the use of many other tools potentially useful.

This problem becomes especially severe in the category of empowering systems because these systems

would encourage novice programmers to evolve, enforcing the good practices of software engineering. Un-

fortunately, in the majority of systems presented in the previous sections, this rarely happens. For example,

in Architecture area, due to the increasing adoption of GD methods, and eventually the increasing complexity

of GD programs, the implementation of a programming system that preserve these good principles becomes

crucial.

In the next sections, I discuss some design principles that improve program comprehension and also

program documentation. Most of these principles were the congruous contributions that, unfortunately, are

vaguely represented in current systems, mainly considering the methods used in GD area. For that reason,

25

I propose a generic implementation of a modern programming environment that meets the GD community

needs.

4.2 Program Documentation

Program documentation is a software requirement of the utmost importance because it is an essential factor

for understanding programs. Even the best program, the most perfectly suitable for the job, will be mostly

useless if the people who need to use it do not know what it is; cannot understand it well enough to use,

build, or modify it; or (worst of all) misunderstand it and apply it incorrectly. This means that all of the effort,

analysis, hard work, and insightful design spend to construct it will have been wasted.

Software exists for a particular reason, and documentation exists to explain this reason. Every piece

of code has its rational and a reason to be written in that way. Then, the documentation collects all these

rationales organizing them in a form of different artifacts, such as requirements description, architectural

models, data models, API documentation, flow diagrams, use case diagrams, etc. Therefore, it is, undoubtedly,

a wealthy source of information not only for the developer who did the software, but also for the developer

who will test the application, for the stakeholder who will use the application, and eventually for the developer

who will maintain that code.

In fact, software maintenance is traditionally defined as any modification made on a system after its de-

livery; this is a dominant activity in software engineering. Some reports place maintenance at 90% of the total

cost of a typical software project (Seacord et al., 2003; Pigoski, 1996). One of the main difficulties in software

maintenance is a lack of up-to-date documentation (Souza et al., 2005). As a result, some studies indicate

that 40% to 60% of maintenance activity is spent only studying existing software (Pigoski, 1996; Pfleeger and

Atlee, 2001, p. 475 and p. 35 respectively). Having an updated documentation would dramatically reduce

the effort spent in this study, helping the developer to comprehend the code and maintain it.

Unfortunately, the sad truth is that writing program documentation today is perceived as a tiresome task,

if it is done at all, is often treated as an afterthought, something people do because they have to (Sousa

and Moreira, 1998). Bass et al. summarizes many possible reasons that lead programmers to write the

documentation, and then concluded as follows:

Maybe a contract requires it. Maybe a customer demands it. Maybe a company’s standard process

calls for it. In fact, these may all be legitimate reasons. But none of them are compelling enough

to produce high-quality documentation. (Bass et al., 2012, p. 327)

Providing a high-quality documentation should be a natural developer’s attitude not because it’s “required"

but because they see that it is essential to the matter at hand. The documentation defends the developer’s job

because it speaks for him, for example in agile methods it can be used as a contract (Ambler, 2007). It also

helps developers reason about the architecture design of their programs and communicates these ideas while

the development is in progress. However, producing useful documentation is a hard task and developers have

to consider that some documentation artifacts are more important than others, where each artifact is intended

to communicate information on the software system (Forward and Lethbridge, 2002). This communication is

aimed at human readers, from the technical document delivered to the developer team, up to the user manual

provided to the users. But the central point from where the documentation comes from is the source code. As

a result, the source code is the most valuable artifact, as suggested in the following study:

Source code and comments are the most important artifact to understand a system to be main-

26

tained. Data model and requirement description were other important artifacts. Surprisingly, and

contrary to what we found in the literature, architectural models and other general view of the

system are not very important. This could simply indicate that such documentation artifacts are

used once to have a global understanding of the system and never consulted again after. (Souza

et al., 2005, p. 74)

4.2.1 Tools for documenting software programs

The importance of source code and comments is a reality already noted in the software industry. Conse-

quently, the use of automation tools to generate, verify, and maintain the source code documentation, is a

notorious practice. The most frequently cited technologies, as concluded in (Forward and Lethbridge, 2002),

are Javadoc1, and DocWiz2 to comment Java source code, and Doc++3 and Doxygen4 to comment source code

in languages such as C, C++, and also Java. These tools generate the documentation from a set of documented

source files into the selected format; the most commons are HTML, and LATEX. The comments are inserted di-

rectly in the source code between a start tag and an end tag. Typically, these tags use the language’s comment

delimiter to avoid compilation errors, as the compiler ignores any word between comment delimiters. For

example, Javadoc requires an extra asterisk, when compared with C standard comments (i.e. /∗ ∗/). So, to

generate the documentation, the comments must be inside these tags (as shown in Figure 4.1a). Additionally,

other tags are provided to document the code, for example the function parameters (@param), the function

return (@return), an exception that may be thrown (@exception, @throws), and so on. As a result, these

tags add proper information into the HTML page (e.g. as shown in Figure 4.1b).

(a) A Javadoc annotation of a Java method (b) Javadoc HTML auto-generated

Figure 4.1: Javadoc generation of a HTML page from a documented Java method. In the left is the sourcecode commented with the opening tag /**, in the right is the generated documentation page.

Figure 4.1 shows an example of Javadoc, an industry standard tool which provides interesting function-

alities for documenting Java classes. The HTML format keeps information together giving the convenience of

being able to hyperlink related documentation. As a result, programmers can easily navigate through classes

1http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/2http://docwiz.sourceforge.net/3http://docpp.sourceforge.net/4http://www.stack.nl/dimitri/doxygen/index.html

27

and their respective methods. Moreover, Javadoc provides a widely integration trough IDEs (e.g. Eclipse, In-

telliJ, NetBeans, etc) so programmers can generate automatic Javadoc comments using those IDEs. However,

this kind of tools is inadequate for another purpose.

For example, the documentation is essentially represented as rows of plain text. Despite supporting the

HTML format, the generated pages only includes text and hyperlinks; media-rich resources are unsupportable.

Moreover, the developer’s attention is taken from code into a series of static pages which might contain little

information and show less than the source code. Moreover, the automatic comments generated by some IDEs,

are usually useless (e.g. a method called getFoo() would be automatically commented as “This method gets

a foo"). Finally, these tools are more focused on creating an industry standard, than properly documentations

that effectively helps developers to comprehend the code and its architecture.

The representation of source code dramatically affects its comprehensibility and usability (Baecker and

Marcus, 1986). The idea of enhancing program comprehension and usability by improving its representation

using richer media resources is not new in the literature (Baecker and Marcus, 1986, 1982, 1983). This

research defines design principles for enhancing program visualization, showing the impact of those principles

in the readability of the code. Based on these works, subsequent investigations and implementations have

tried to keep those beliefs alive inside the academic context. For example Barista (Ko and Myers, 2006)

implements some of these principles allowing media-rich annotation in the code editor (see Figure 4.2a),

while Codelets (Oney and Brandt, 2012) focus on supporting media-rich resources in code completion by

enabling HTML icons visualization (see Figure 4.2b) helping developer to write HTML pages 43% faster than

when using a standard Web browser(Oney and Brandt, 2012).

(a) A media-rich annotation in the Barista editor (b) A Codelet inline helper

Figure 4.2: Example of media-rich annotations supported by code editors. On the left is Barista editor showinga Java method with richer annotations including images. On the right is the Codelets implementation showingthe inline helper with icons defined for mobile buttons.

Barista (Figure 4.2a), as a research project, is full of useful ideas for implementing interactive features in

a code editor. Incremental parsing and a separation of abstract syntax tree (AST) and view model of a source,

is a useful concept. Moreover, it proposes tools such as media-rich annotation of methods (including hyper-

link and diagrams inside the comments; allowing show/dismiss the comments by double clicking), readable

pretty-printed view of formulas (enabling edit of these expressions by double clicking), and so on. As an im-

plementation, however, the Barista source code (i.e. the used programming language Citrus (Ko and Myers,

2005)) is over ten years old and not maintained (Ko, 2015). On the other hand, Codelets (Figure 4.2b) uses

media-rich resources to present in a pop-up a variety of icons that develops can choose to create their web

pages. However, it is more related to code completion technologies than support program documentation.

28

4.2.2 Tools for documenting Generative Design programs

Considering the GD area, the lack of tools that accurately document a program, or automates the process of

documentation, is still a problem. The absence of such mechanism discourages the process of documenting a

program. Therefore, programs without documentation become difficult to understand, modify and eventually

reuse. Consequently, this negatively affects the entire GD community, once documentation plays a fundamen-

tal role in the development process.

Unfortunately, the support for implementing the interactive tools presented above, and many other po-

tentially useful tools, are weak or even inexistent in the majority of GD systems. For example, in Design-

Script (Aish, 2012), Monkey, and many other textual environments, the source code is visually represented as

rows of plain text, which makes difficult or even impossible the inclusion of rich-media elements (as shown,

for instance, in Figure 4.2a). In the other hand, the visual programming languages, supported by environ-

ments such as Grasshopper and Dynamo, represent the source code visually with boxes and lines. However, to

document these visual programs usually a box of plain text are provided, so that users can place it anywhere.

As a result, the documentation can be spread throughout the program, making it difficult to access.

This problem becomes worse with the growing use of GD methods to support the development of real

architectural projects. An architectural project, just like a software project, has a design phase where architects

study the problem which they want to solve, analyze eventual constraints imposed by the client or external

factors, and then define a draft of the solution. At the end of this process, several artifacts are produced, such

as diagrams and handmade sketches (as those portrayed in Figure 4.3). These sketches are commonly used

among architects since early days of architecture (Do and Gross, 2001), because they represent a compact

medium to convey complex ideas. The information generated in the design phase may be sufficient to model

the main components of the project, serving as a start point, and a basis, to the development process.

Figure 4.3, shows the importance of this phase in the architectural conception. In this example the

architect started by drawing a series of sketches annotating them with dimensional and spatial parameters

such as height (h), diameter (d), the normal vector ( ~N), and vertex points (e.g. P0, P1, P2, ...) of each shape

(see Figure 4.3). These forms are treated as small components, that further can be combined to create new,

different kinds of geometric objects. Understanding how these sketches are used in practice, is a crucial step

before proposing any possible feature.

Figure 4.3: Typical example of sketches made during architectural design phase.

By definition, a GD method formally defines a description of an architectural model (McCormack et al.,

2004). In this way, while the code defines the geometric object textually, the sketch defines it visually. Conse-

quently, the sketch is a rich source of information during the development of the program, and also after it, for

documenting the program. Differently from the typical programs in software engineering, which are purely

29

textual and may express concepts that are difficult or even impossible to represent graphically, the programs

used in GD have this capability of being able to represent its concepts through sketches or diagrams.

Moreover, illustrations and diagrams may help in the design conception because when the architect is

doing them, he is thinking about the code to find a way to model a particular shape. At the end of writing the

program, all architect’s decisions and insightful design, applied to construct the final program, are encapsu-

lated in these sketches. As a result, these sketches are also an essential artifact to comprehend the program,

especially after its release.

For example, consider Figure 4.4 that portrays a real example of a chair seat parametrically modeled. Even

the less curious reader will wonder to know what each symbol of this image means. Some of them are more

obvious than others, for instance, the angles and the differences between them. However, this diagram has its

meaning embedded in problem context. It means that those symbols in the image are variables which were

created purposely to solve the problem of setting up a different shape of seats by varying the variable values.

So the sketch proposes a parametric model of the chair seat. Additionally, it contextualizes the meaning of

each variable. Using this example, the architect can create a suitable GD method that creates this chair seat.

However, the GD approach is not so straightforward as it seems to be.

Figure 4.4: A real sketch of a chair seat. In this sketch, the seat is parametrized with some geometric variables.Some of them are intuitively noticeable, e.g. the angle symbols δ, θ , and β , but rest of them are not becausethey have its meaning embedded in the problem context.

The problem with the GD methods is that when a geometric model is translated into a programming

language, the visual information that was available is lost. That is a serious problem for architects that do not

have the same background of a software engineer, which means that visual models can be a preferred media

for them, instead of interpreting symbols.

30

For example, Listing 4.1 illustrates a function that models a chair seat with some of the parametric vari-

ables from Figure 4.4. These variables are directly translated into function arguments. Therefore, when we

look at this piece of code comparing it with the image, we understand the meaning of each variable, in the

function context. Unfortunately, in most cases the sketches are not delivered with the program, even worst,

the program is usually delivered without any documentation, or may have useless comments like that one in

the example. Therefore, it negatively affects people who need to use this program, because without documen-

tation they cannot understand the program well enough to use, or modify it, affecting the entire GD community.

1 def make_seat(smf, scf, scb, sa_d, sa_w, sa_deltawt , sa_betar, sa_betaf) :

2 "this function creates a chair seat"

3 ... # l o g i c f o r c r e a t i n g a s e a t

4 return seat;

Listing 4.1: Python function that creates a chair seat given some of the parameters of Figure 4.4

4.3 An approach for documenting Generative Design programs

As discussed in the antecedent section, the lack of documentation in GD programs negatively affects its users.

In fact, this problem is beyond the GD area; it also affects the field of software engineering. In this area, there

were attempts to improve this issue by improving the quality of program documentation, most prominently,

literate programming (Knuth, 1984). This work proposed a programming paradigm that promoted the fact

that programs are written for people first and foremost, and that documentation should be emphasized just as

much as code. Unfortunately, these attempts did not reach the intended goals, mainly because writing good

documentation takes a considerable amount of time and effort.

A more recent work (Victor, 2014) suggested that the programming environment should minimize this

tough work, required to write documentation, by automatically providing the documentation that program-

mers need when they are reading the code. In this work, Victor outlines the following idea:

The environment is responsible for making meaning transparent. The environment must enable

the reader to effortlessly read the program, to decode the code so that he can concentrate on

genuine programming concepts (Victor, 2014)

Figure 4.5 shows a prototype, presented with this work, which demonstrates how the environment can

improve the program readability. The code, on the left, is written in the Processing language (Reas and Fry,

2006), it sets the environment color to green and creates two geometric objects, visible on the right, a circle

and rectangle, using the Processing functions: fill, ellipse, and rect. This programming environment

makes the meaning of each element of code transparent, providing labels on mouse-over. For example, when

the reader points to the fourth parameter of function rect, he will know that it changes the height of the

rectangle. Furthermore, he can also point to every element of this code to get its meaning, so before he makes

any modification in the code, he will know what the code is doing.

Labeling the program elements on mouse-over indeed makes the program meaning more explicit, but

this technique does not replace the need for proper documentation. The main problem with this approach is

that these labeled functions already exist in Processing, so this feature is more intended to avoid unnecessary

searches on the Processing User Manual than to provide a way to document the program. For any user-defined

31

Figure 4.5: A programming environment that helps in the program readability. On the left, is a sample ofcode, written in the Processing language, that creates a green circle and rectangle. On the right, is the resultof this code. Each element of this program, including the functions and its arguments, are labeled, so whenthe user points the mouse over an item its label appears in the text editor.

function this feature will be useless. Therefore, the developer must take a considerable amount of time and

effort to create its documentation.

The reality in architecture is quite different from that in software engineering: it is part of the design

process to produce documentation in the form of sketches. This means that it is not necessary to write huge

amounts of textual documentation to explain a GD program. We only need to annotate the already existing

sketches and combine them with the program, thus providing visual explanations of what the program is

supposed to do.

4.3.1 Sketch-program correlation tool

Therefore, I propose a sketch-program correlation tool that shows how sketches, made in an early phase of

program design, can be combined with code to provide useful documentation for the developer. Figure 4.6

illustrates a function, called draw_arrow, that draws an arrow giving the base point P, the direction α, the

height ρ, and the width β and size σ of the arrow tip. This information is all condensed in the sketch. So, the

idea is to take advantage of this fact by pointing out what is the meaning of each function parameter, found

in the code, in the context of the sketch (and vice versa). In this way, when the user has the mouse over a

function parameter he immediately sees its illustration in the sketch, and the inverse is also valid: when he

moves the mouse over a symbol in the image he immediately sees its meaning in the code.

Figure 4.6: Sketch-program correlation tool showing how to combine fragments of the program with sketches.Inthis example, all the function parameters are linked to a symbol in the sketch that illustrates its meaning.

As research, this tool presents a useful idea, as an implementation, however, this mechanism imposes hard

challenges. For example, one of the first challenges is how to include images in the code editor. The majority

of source code editors, currently used for textual programs, do not support this feature. We are not aware

of any other source code editors, widely used, that provides such capability, except DrRacket (Findler et al.,

2002) that implements an enhanced editing mode with support for images and other media-rich elements.

32

4.3.2 Dealing with images resources

An inherent concern for supporting pictures in the code editor is how to store them. The strategy used by

DrRacket (Findler et al., 2002) is to serialize the image and save it in ASCII-encoded binary format. The

problem with this approach is that, once the developer inserts an image in his code and keeps it, he will be

unable to change its code again using a different text editor. So, this method does not provide any backwards-

compatibility with other text editors potentially useful to write programs. As a result, it makes it difficult, or

even impossible, to have portability of programs written in this programming environment with the different

text editors widely used.

I suggest a different approach to this problem that assures backwards-compatibility among source code

editors. In this way, the image is inserted inside a tag delimiter enclosed by a source code comment. For

example, Figure 4.7 shows a function, written in Python using a code editor that support images. This program

has a multiline source code comment, spanning multiple lines of text mixed with the image (starting and

ending with the delimiter �'). Inside this comment is a tag, in XML, that specifies the information associated

with the image, such as its location, its parameters, and also the place of each parameter in the picture. The

programming environment loads this information upon a picture insertion event. However, users can edit this

fields after the image is loaded.

Figure 4.7: Opening the source code in an editor thatsupports the inline-img annotation.

Figure 4.8: Opening the source code in an editor thatdoes not support the inline-img annotation.

The advantage of this mechanism is that when users open this code in a text editor that does not support

images, they can access the source code entirely, as shown in Figure 4.8. However, the images are not dis-

played. Instead, the source code comment shows the image path and associated information. On the other

hand, the disadvantage of this method is that pictures have to be bundled with the text file. Otherwise, the

text editor will not find them, consequently, not displaying.

Other systems, to avoid this incompatibility problem, convert the code, which includes media-rich ele-

ments, into a standard format. For example, Barista (Ko and Myers, 2006) saves the code in XML. However,

the presented approach goes further, because it does not impose any language specific requirement, the code

is stored as it is (ordinary plain text). So it is up to the code editor to implement suitable methods to show

the images.

4.3.3 Automatically binding code with images

Once we can insert images in the text editor, the next step is somehow associate these images with code.

Figure 4.6 shows a possible approach, where the function parameters point to the symbols in the picture.

Note that; these symbols can be words rather than a single character. Thus, an interesting feature would

33

automatically recognize these symbols, getting their optical character and respective position. Therefore,

having this information makes it possible to match the parameters found in the code, with the symbols found

in the image.

Recognizing text characters on images is an old problem. The very first attempts can be found back in

1870 (Mori et al., 1999) with the retina scanner which was an image transmission system using a mosaic of

photocells. From then, consecutive attempts were made to improve this method especially by sophisticating

the retina scanner and creating machines that became commercially available in the 1950’s. Posteriorly, HP as a

possible software and hardware add-on for HP’s line of flatbed scanners, proposed a novel open-source project:

Tesseract (Smith, 2007) OCR which aims to implement the scanner reader entirely in software. Thereafter,

this project was sponsored by Google and nowadays is one of the most accurate OCR engines on the market,

widely used in several web applications.

Clearly, the subject of character recognition is extensive, and its details are beyond the scope of this

dissertation. However, my solution for automatically recognizing text in images is based on an OCR engine,

namely Tesseract (Smith, 2007), that accepts an image as input and returns a file with the known characters

and their respective coordinates as output. However, Tesseract is a local C++ application that needs to be

installed on the user’s computer or included as an external library, which may affect the portability of the

application and its use.

To overcome this limitation, I propose the use of OCR Web Services, such as OnlineOCR5, or FreeOCR6,

as these engines provide the same functionality as Tesseract and, in fact, most of them are build on top of

it. Moreover, as web services, these systems provide a straightforward integration with external applications,

once they use standard protocols, such as SOAP, or REST. In Figure 4.9, I suggest an architecture for integrating

the OCR engine as a module of this tool. This architecture describes a data flow view, starting when users insert

an image in the editor, until the end of the process when the editor saves the image. Thus, the components of

this architecture are described as follows:

• Code Editor. It is the main UI for the programmer where he will write code and insert images. So, this

component is the initial filter of the pipe. Consequently, it starts the logic sequence flow for processing

the image.

• Image Filter. This component has two principal activities: first get the image inserted into the text editor,

and second send the image to the OCR engine through REST invocation. (Note: it assumes that the web

service provides a suitable service for this invocation, which is naturally expectable among the OCR Web

Services studied.)

• OCR Engine. It is the fundamental piece of this architecture, from where the image will be processed

and transformed into optical characters. This component is the most critical of this architecture because

the correct operation of this tool depends on how well this engine will operate.

• Meta-data Collector. This component is intended to receive the information processed by the OCR engine,

and then stores it. This information contains the recognized optical characters and, additionally, the

coordinates from where the OCR picked each symbol.

The presented architecture left several unclosed questions, for example, a clear issue is where the Meta-

data Collector will store the information received. This decision is hard to make now because it is intrinsically

5http://www.onlineocr.net/6http://www.free-ocr.com/

34

Figure 4.9: The suggested architecture for integrating the OCR Engine. This architecture presents a data flowview combining two styles: pipe-and-filter style and client-server style.

related to the way which the programming environment stores its rich-media elements. As discussed earlier,

there are several approaches to deal with it, such as serialize the items in a binary format, use standard

formats such as XML, and, our own approach: use common source code comments to wrap the media-rich

information. The strategy used for storing meta-data with the image may vary depending on the output

format chosen. What I propose is to use the last option, due to the backward-compatibility among different

text editors.

4.3.4 Designing a fallback mechanism

Unfortunately, the OCR engine uses a pattern recognition technique which is susceptible to errors. To overcome

this problem, I propose a fallback mechanism that delegates the task of recognizing symbols to the programmer.

Thus, the programmer can directly intervene in the image recognition process helping the OCR upon mistakes.

Moreover, the user input can be a rich source of information for the OCR engine because this data can be

used as a corpus of training, therefore improving its recognition capabilities. After processing the image and

obtaining the contained annotations, the next step is to present this information meaningfully.

4.3.5 Presenting binding associations

At this point, we have the code and the annotations extracted from the image, then the goal is matching them.

I propose two alternatives to overcome this problem, as follows:

1. Implement a programming environment from scratch. This option allows a high level of customization

because the environment will be built based on this requirement. Thus, adequate technologies can be

chosen purposely to deal with images in code and support the binding between code and image, as shown

in Figure 4.6. Moreover, this tool can be language-independent, to correctly operate it only requires

access to the image meta-data and the syntactic structure of the program, generated in compiling phase,

i.e. the AST. This approach can also minimize the effort to add additional features because different tools

share the same core implementation. Despite the clear advantages, it requires a huge effort to implement

such environment and, of course, a risk that this environment will be considered useless by the target

users. For example, Barista (Ko and Myers, 2006) takes this approach, providing an environment for

Java programmers. However, it is very unlikely that a Java programmer will use this tool in his daily

tasks.

2. Extending an existing programming environment. This is a more straightforward approach, based on

the fact that most programming environments nowadays provide some support for add-on features. In

this way, programmers can create new features without changing the programming environment itself

by implementing a common API. The main advantage of this approach is that we can use resources

generated by other tools without having to apply them. For example, the AST which is a rich resource

35

generated during the compiling phase, is usually provided through API methods. Alternatively, the pro-

gramming language can be used to achieve this goal; some programming languages allow the definition

of new grammar rules. As a result, a new grammar rule can be created to consider images as part of the

programming language grammar. However, this approach is extremely dependent on the language/en-

vironment support for add-ons and, therefore, of the API provided to extend the system.

4.3.6 Strategies to improve the usability in the source code editor

An important issue that affects the entire system is related to the usability of the programming environment.

Adding images mixed with code is something that can impair the usability of the programming environment

because images can occupy a considerable part of the text editor making the program readability more difficult.

Moreover, when programmers are coding, they are focusing on that task and the images might be a distraction.

This is a problem that does not have a straight solution. However, I propose some strategies to handle the

problem:

• Treat rich-media resources, including images, as text. It means that programmers should be able to

work with these resources just like they do with text so that it can be cut and paste, it can be deleted, it

can be moved by dragging and drop, and it can also be indented.

• Support text caret navigation as in a text editor. Evidence from a study of programmers’ low-level text

editing strategies (Ko et al., 2005) suggests that programmers rely heavily on the keyboard for code

navigation. Therefore, adding rich-media resources in the source code can interfere with the caret

navigation. However, treating images as text will not affect the caret navigation.

• Show or dismiss the rich-media resources by double clicking. The purpose of this facility is to avoid

distractions, so when the programmer is coding he clicks over the image, to dismiss it and focus on the

code editing.

• Add images by dragging and drop and support inline edition. It is important for the users that adding

images, or other resources, be as simple as writing code. Mechanisms such as drag and drop, edit the

picture directly in the text editor, among others facilities, should be considered. The fewer iterations are

needed to select an image, the better it will be the user experience.

4.4 Immediate feedback

Programming requires developers to maintain many different kinds of ‘mental models’ (Brooks, 1977; Robins

et al., 2003), which represents how they comprehend the code. Therefore, after writing a single line of code,

intellectual work must be done in the developer’s mind. During this phase, the developer is formulating several

theories about the program. However, he can only test these ideas when he found evidence in code. Which

means that, he needs to edit the program, compile the code and execute it to test if his theories were right or

not.

There were several attempts to facilitate this process, trying to make programming in a more concrete

task. For example, the invention of debugger tools was precisely to enable programmers to see the state

of their programs, its structures, and how the flow of information passes through it upon execution. With

successive improvements of these tools, modern systems, such as LightTable (Granger, Jan. 2014), have been

trying to anticipate as much as possible the result of a program change. This environment reduces the delay

between an edition in the source code and the visualization of its effect. Although this is a simple concept

36

in practice, it becomes popular in the academic community and even beyond it in the industry context. For

example, JRebel7 is a popular tool that allows developers to visualize changes in a web application without

stopping the application server. Visualizing changes allow programmers to test their mental models, therefore

improving their comprehension about the program.

The smaller the delay between making the changes and visualizing their effects, the better. Immediate

feedback is, thus, when there is no perceived delay between the change and the effect. Therefore, immediate

feedback accelerates the process of program experimentation so programmers can test their mental models

faster, enhancing their program comprehension.

4.4.1 Immediate feedback in Generative Design

A good practice in Architecture, however, is the use of sketches to convey ideas (Do and Gross, 2001). Sketches

are, in fact, a suitable media to experiment, and test new ideas quickly, which is a fundamental requirement

for creating novel designs. However, GD methods drastically change this reality: instead of interacting directly

with the model, as traditionally in Architecture, the architect interacts with a model’s intermediate, i.e. the

program that specifies it. Thus, any change in the model must be performed first in the code and then, only

after the execution of the program, the architect will be able to see the impact of his change in the model.

This process delays the visualization of the model, negatively affecting the design process.

To overcome this limitation, notable efforts have been made in the GD area. For example, visual program-

ming languages, such as Grasshopper (see Section 3.4.4) and Dynamo (see Section 3.4.5), provide immediate

feedback. Therefore, as the user interacts with the language components, by adding and connecting them, the

effect of this interaction is immediately available in the CAD model. However, in these visual programming

languages, as programs become large and complex it requires more time to understand, maintain, and adapt

to new requirements (Leitão and Santos, 2011). Moreover, the delay between changes and visualization in-

creases, making immediate feedback impossible. On the other hand, programming environments for textual

languages do not support immediate feedback at all.

4.4.2 Immediate feedback tool

To change this reality, I propose an immediate feedback tool aimed for textual programming languages. The

goal of this tool is to substantially reduce the time between a change in the code, and its effect in the program

execution. Therefore, architects will be able to improve their programs and see the impact of that change in

the geometric model, allowing program experimentation and, eventually, improving program comprehension.

Moreover, this tool provides a foundation for other features, which can be implemented on top of it.

For example, a useful tool that promotes program experimentation is the use of widgets to change the

program input. Moreover, using immediate feedback feature is possible to improve the autocomplete mech-

anism. In this way, and different from the traditional autocomplete tool that shows a list of options suitable

for a particular expression, this mechanism can do more, so when architects select an expression in the list

of choices, the selected expression is sent to the immediate feedback tool and its result becomes immediately

available.

4.4.3 The activities of program experimentation

However, to improve program experimentation process we need first to find the activities of this process,

especially the most time-consuming. For example, using the parametric model shown in Figure 4.4, is possible

7https://zeroturnaround.com/software/jrebel/

37

to generate a set of chair seats. To this end, the architect, using the implementation of this model, can proceed

as shown in Figure 4.10, where these activities are described as follows:

• Find places to change in the source code. The time spent to perform this task may vary substantially,

depending on the complexity of the program, and the architect’s knowledge about the program. Unfor-

tunately, these factors are not directly related to this tool; it is more associated to the tool presented in

Section 4.3.1.

• Edit the source code, choosing suitable program inputs to perform the desired action. Considerable time

is spent in this activity because architects usually need to predict the range of values that makes sense

for each program parameter. Fortunately, this operation can be improved by this tool, saving any wasted

time spent on it.

• Run the program. Depending on the programming environment this step can be a simple button click, up

to execute a command to compile, and run the program. This step can be optimized using appropriate

techniques, such as reusing the previous computation.

• Visualize the change in the model and check if it was sufficient to generate the desired model, otherwise,

repeat the process. As a result, this is one of the most time-consuming activity, because it relies on the

CAD tool to generate the model. As discussed in the previous sections, CAD tools are not designed to

process the huge amount of information produced by GD methods. Therefore, alternative visualization

devices must be considered to optimize this activity.

Figure 4.10: Activity diagram for generating a set of seat shapes.

4.4.4 Improving program execution

Base on these activities, a first approach would be optimizing the program execution. Some programming

systems, such as Impromptu (Sorensen, 2005), and Fluxus (Griffiths, 2007), attempt to address this with "live

coding" environment, where the program output updates immediately as the code changes. These systems use

a standard technique to provide this feature: a language interpreter that given an expression directly evaluates

it. Curiously, both of them use the Scheme interpreter (a Racket (Findler et al., 2002) ascendant) due to its

enhanced capability for evaluating expressions, and ease integration. For example, the Scheme runtime can

be integrated with other programming languages like C, and C++, the interpreter already provides a sandbox

mechanism, only executing code syntactically correct, thus avoiding compilation errors. However, in these

programming systems change in the code causes the interpreter to evaluate the entire program again.

An apparent gain in performance is related to the utilization of the previous computation that was un-

changed after a code edit. For example, consider the sample of code, shown in Listing 4.2, that creates a chair

given a point, the chair height and width, and the seat dimensions.

The function create_chair_obj, at line 5, does the major part of the computation, creating the chair

object, and the function move_to, at line 6, only translates the model to the given point. If the architect moves

the chair position (e.g. change it to {x=1, y=1, z=1}) is unnecessary to create another chair, once this change

38

does not affect the chair shape. In this way, the operation will be a simple translation. However, this solution

will not work in some cases. For example, the global variable offset is a constant for the program. Therefore,

a standard compiler optimization known as constant folding will replace every occurrence of that variable by

its value. The resulting program is shown in Listing 4.3.

1 offset = 50

2 def make_chair(p_center, ca_h, ca_w, sa_d, sa_w) :

3 real_p = xyz(p_center.x/offset, p_center.y/offset, p_center.z/offset)

4 # some complex computa t i on

5 chair = create_chair_obj(ca_d, ca_w, sa_d, sa_w)

6 return move_to(real_p, chair)

7 # c r e a t e s a c h a i r i n o r i g i n

8 make_chair(xyz(0, 0, 0), 20, 20, 30, 30)

Listing 4.2: Python program that creates a chair.

1 offset = 100

2 def make_chair(p_center, ca_h, ca_w, sa_d, sa_w) :

3 real_p = xyz(p_center.x/50, p_center.y/50, p_center.z/50)

4 # some complex computa t i on

5 chair = create_chair_obj(ca_d, ca_w, sa_d, sa_w)

6 return move_to(real_p, chair)

7 # c r e a t e a c h a i r i n (1 ,1 ,1)

8 make_chair(xyz(1, 1, 1), 20, 20, 30, 30)

Listing 4.3: Python program that creates a chair, after constant folding.

The problem happens if the architect decides to change the value of offset (at line 1). This alteration

will have no effect on the program output, because the make_chair is reusing a previous computation where

the offset was defined as 50, so the code must be compiled again to reflect this change. Consequently, the

technique of reusing the previous computation will be in vain.

However, there are other approaches to this technique. For example, the Design Script (Aish, 2012)

language implements a data flow paradigm, creating a dependency graph between variables. In this case,

offset will be linked to its usage (the three parameters of Listing 4.3, at line 3). So, changing its value, will

cause a recalculation of these parameters. On the other hand, YinYang (McDirmid, 2013) will compile just

the changed branch in the AST. However, these languages were tailored specifically for this purpose and are

outside the scope of this thesis.

4.4.5 Program experimentation in Generative Design

A relevant issue associated with textual programming environments in GD is the lack of tools that facilitate

program experimentation. Each time the architect wants to change a geometric model, he needs to edit the

code blindly, guessing an appropriate input for that parameter. Clearly, this is an ineffective way to test the

program, besides of being a laborious process for experimentally generating new models, discouraging the

creative work.

Visual programming languages, such as Grasshopper and Dynamo, understand this as a severe limitation

for the architectural work. They provide some mechanisms such as interactive widgets, e.g. sliders, which

facilitate the process of program experimentation. For example, in Grasshopper users can add a slider in

39

component inputs, as shown in Figure 4.11. Therefore, the slider is defined in a range of values, and each

time the user drags the slider the program is executed with that input.

Figure 4.11: A Grasshopper program. On the left, is the program inputs connected by sliders. On the right,are the program components.

A similar technique, is used in live-code environments like Fluxus (Griffiths, 2007) and Impromptu (Sorensen,

2005). Although these programming systems are associated with textual programming languages, they pro-

vide sliders to allow performers to change their program inputs. In a live code presentation, performs use

their programs to impress the audience. In this situation, sliders are crucial to change the program inputs.

Therefore, in these systems sliders are an indispensable feature, so they are part of the programming envi-

ronment. However, other textual programming systems, such as DrRacket, provides a GUI library for input

widgets, such as a slider. Therefore, sliders are create outside the programming environment, which means

that users define the slider in their source code, and upon program execution, the slider is displayed in an UI

frame.

To create a new slider, in DrRacket, users must specify a label, a max-range, a min-range, and a function

callback. The slider callback can be associated with an existing function,and each of its parameters can be

linked to a slider. Then when the slider is moved the callback executes the function with the selected values.

For example, Figure 4.12 shows the slider associated with the function illustrated in Figure 4.6.

Figure 4.12: A slider user interface for the draw_arrow function.

In fact, the UI shown in Figure 4.12 allows the function draw_arrow be executed interactively. However,

this UI only executes the draw_arrow function, because its callback is associated to this function. So, for any

different function, the user must create a new slider, defining all the required parameters again. Moreover, as

numerous are the parameters of the function, as greater will be the UI. Therefore, it can reach a point that can

disturb the developers, and, even worst, it hides the surrounding context from where the function is called.

4.4.6 Inline sliders mechanism

To overcome these limitations, I propose a slider mechanism that is integrated in the programming environ-

ment. So, it facilitates the change of each program literal individually. Instead of showing the UI with the

function parameters at once (as shown in Figure 4.12), this mechanism allows each function parameter to

40

be changed individually, creating a unique slider on top of that parameter. As a result, programmers can in-

teractively modify the program input without losing the surrounding context of the program. Moreover, this

mechanism is independent of the program execution, which means that dragging the slider will only make

changes in the code. Obviously, to have an immediate effect on the program execution, the program should

be executed at each slider change.

4.4.7 An inherent problem

Unfortunately, immediate feedback will not scale with the increasing complexity of GD programs. When the

programmer drags the slider, he is expecting to see how that alteration looks like in the model. Likewise, when

we are writing in a text editor, we are hoping to see how the words appear in the text editor. Otherwise, we

will probably think that something is going wrong. Show the program hidden states is an important heuristic,

especially in a context where users are dependent on the program result. However, implement this heuristic

in the current GD environments would be a hard challenge.

Grasshopper is a concrete example of GD system that has been facing this problem insistently. The initial

approach was execute the program at each change. When the program becomes complex, its execution time

get bigger and bigger, reaching a point where programmers become afraid to touch in the sliders to avoid

freezing. To overcome this problem, a second approach was to restrict the slider input to only accept textual

inputs. As a result, this method was highly criticized, because it was against the principles of visual program-

ming languages. Thus, a new strategy was proposed: deactivate slider dragging effect and only reproduce

the final dropped value. This strategy had a better performance, but it limits the program experimentation

to individual points in the range of the slider. Obviously, this is not exactly a solution and will not solve the

problem, only delays its onset.

Fortunately, there is a straight solution for this problem, as discussed above, which is sidestepping the

most functionalities of CAD tools, using an alternative visualization device. For the purpose of this tool, I

propose to use an alternative render device working as a kind of playground where users can create samples,

and find out the right parameters to build their models. Moreover, sliders can be used to create these models

interactively.

4.4.8 Adaptive sliders

However, sliders must have helpful values that make sense for that program input. For example in Figure 4.12,

the parameters showed have a distinct range of values, i.e. {x , y, z,σ,ρ} ∈R, α ∈ [0, 2π], and β ∈ [0,π/2].The problem is how to predict an accurate range of values for a function parameter. In principle, the program

variables declared as integer have their domain in Z, so the challenge is to restrict this domain to something

that makes sense for that particular invocation. There are several strategies used in practice, for instance

LightTalbe (Granger, Jan. 2014) shows a drop down list where the first value is a minor value (i.e. x ∈ R− :

x → −∞) and the last value is a major value (i.e. x ∈ R+ : x → +∞) and depending on the chosen value

the next drop down list shows a range of values closer to that value.

Based on live-code environments, I suggest an alternative which is to show initially a reduced range of

values (x ∈ R : x ∈ [x − 10, x + 10]) and then adapt this range of values accordingly to the user experimen-

tation. That means, initially, that the range is statically defined, and the increment between the values is also

constant. The quicker the programmer drags the slider as greater will be the increment between the values,

consequently changing the range of values. However, this approach requires changing the UI dynamically as

the user increases the sliders range. Unfortunately, considering the UI from Figure 4.12, it will not be possible,

because to change any initial parameter defined in the creation of this frame, the programmer must create a

41

new UI frame, making it difficult the process of program experimentation.

4.4.9 Dealing with errors

However, the possibility of dragging the slider through a range of values can be error prone. For example,

consider the Snippet of code 4.2, if the programmer decides to vary the amounts of offset an error will

occur when it reaches to zero because there are some division using this value. In this situation, there are

two alternatives to follow: (1) stop the experimentation and present the error, or (2) omit the error and allow

the programmer to continue in his task. I propose the second alternative, as the goal of this tool is to enable

program experimentation, in this way a proper sandbox mechanism must be implemented. However, an even

better option would be to give some visual feedback that there is an error, but allow further experimentation.

4.5 Conclusion

In this chapter, I introduced some problems associated with programming in general. Then, I focused on the

GD area, which is becoming a popular area in architecture. However, the current GD environments are not

designed to promote the good software engineering practice of program documentation, or even support user

interactions such as connecting the architects to their designs. To overcome this limitation I based my work

on Learnable Programming (Victor, 2014), Barista (Ko and Myers, 2006), and Literate Programming (Knuth,

1984), applying the ideas of these systems in two interactive tools: sketch-program correlation, and immediate

feedback. In the next chapter, I present an evaluation of these ideas.

42

5Implementing Programming Tools forGenerative Design

This chapter presents a coherent implementation of the proposed programming tools exploring the ideas

suggested in the previous sections. The first part describes the design decisions which affected the course of

development, focusing on the rationale behind them. The second part shows the achieved result, detailing

technical aspects of the software architecture. The last part describes the performed test conducted with target

users, to test the initial hypothesis.

5.1 Rosetta

Due to time constraints, among other factors, an early decision was to opt for extending an existing program-

ming environment, rather than implement one from scratch. This decision is critical due to its consequences

especially on the implementation effort. Moreover, a GD system that does not respect the main design princi-

ples discussed in this thesis can ruin the purpose of any tool build on top of it. Thus, to choose an adequate

system to extend, a comparative study was devised evaluating the potential choices in three design principles,

which I consider successful designs for a GD system. These principles are (1) portability of programs, (2) lan-

guage independence, and (3) a strong correlation between programs and models. From the set systems that

I analyzed, Rosetta (Lopes and Leitão, 2011) was the system that more strictly implements these principles.

Therefore, I chose Rosetta as a basis for implementing the interactive programming tools proposed previously.

Rosetta is undoubtedly a distinct programming system, and it provides a modern environment for GD,

designed to overcome the limitations of the most used GD systems. One of the most important limitations

concerns is the portability of programs that are written in programming languages provided by GD systems.

For example, a RhinoScript program will execute in different versions of Rhinoceros3D CADs. However, it

will not run in AutoCAD. In this case, users must translate their programs to a programming language that is

supported by the target GD system. Translating programs might be a common task for a software engineer, but

it is an ambitious and error-prone task for a designer. Unable to overcome this limitation, designers become

locked-in to a particular family of CAD applications and cannot reuse programs of different families.

Rosetta overcomes this problem by providing (1) multiple programming languages as frontends, from

where users can choose to write their GD programs; and (2) multiple CAD applications as backends, which are

used to display the geometric models. For example, Figure 5.1 shows Rosetta with a Racket program and its

corresponding geometry in AutoCAD. Using Rosetta the geometric model becomes portable, which means that

it has no dependency of any CAD application, neither any CAD particular programming language, becoming

highly customizable.

Generating the geometric models outside the CAD application, changes drastically the conventional ap-

proach of manually manipulating the CAD application, making the program a fundamental piece in the design

43

Figure 5.1: Rosetta programming system. In the left, is the program written using Racket as the frontend. Inthe right, is the program output using AutoCAD as the backend.

conception. Therefore, facilitate the adherence of novices to this new design paradigm should be a require-

ment of utmost importance. Rosetta, fortunately, presents a suitable mechanism which serves this purpose.

For example, programmers can explore different frontends and backends to find a combination that is most

appropriate for the design task. Moreover, programmers have access to various programming languages which

can be used interchangeably to write portable GD programs. Furthermore, a single program creates identi-

cal geometry in different CAD applications. This approach promotes the development of programs that are

portable across the most used CAD applications, thus facilitating the dissemination of those programs and the

underlying ideas. Finally, providing multiple programing languages creates an easy migration path for users

of other programming languages, such as, Python and JavaScript, who can find these languages available in

Rosetta.

Just as important as being able to choose among multiple frontends/backends is to connect Architects to

their design. To this end, many design tools acknowledge the usefulness of immediate feedback. Therefore,

this can be seen in the ability of some GD tools, such as Grasshopper and Rosetta, to connect program inputs

to specialized widgets, such as sliders, that react to changes by recomputing the generated design. However,

as discussed in previous sections, this re-computation process only operates in real time for the very simple GD

program. Sophisticated programs can take a considerable amount of time to recompute, and the interactive

use of input widgets can become annoying, a problem that affects any system that depends on CAD tools for

generating geometry.

Because CAD tools were not designed to process the large volume of operations generated by GD program,

Rosetta provides an alternative backend that sidesteps most the functionality of traditional CAD tools and

focuses only on generation and visualization of geometric models. This backend is based on OpenGL that does

not depend on a fully fledged CAD application. Instead, it connects, almost, directly to the graphics device of

the computer. This backend allows much faster rendering and, as a result, immediate feedback can operate

for larger inputs and a broader spectrum of programs.

For example, consider the geometric objects shown in Figure 5.2, Figure 5.3, and Figure 5.4. Using a

traditional CAD tool as a backend, would be difficult change these objects interactively because to have a fluid

feedback the response of an action cannot take more than few seconds (ideally less than 1 second). However,

44

the reaction time of a CAD application, such as AutoCAD or Rhino, can be very long.

Figure 5.2: Orthogonal Cones Figure 5.3: Scriptecture Figure 5.4: Möbius Truss

On the other hand, change these models interactively using the OpenGL backend is entirely possible. Ta-

ble 5.1 shows the time taken by different backends for updating identical geometry (shown in Figure 5.2,

Figure 5.3, and Figure 5.4). It is visible that the OpenGL backend is considerably faster than the other back-

ends. Consequently, an interactive feature that requires immediate feedback will be successful using this

backend.

Example/Backend AutoCAD Rhino OpenGL

Orthogonal Cones 1022 191 1Scriptecture 10712 2994 67Möbius Truss 24253 6094 217

Table 5.1: Time (in milliseconds) needed to update the generated geometry

Despite the promising results shown in Table 5.1, at this moment, the OpenGL backend is still being

developed in Rosetta, and only supports a subset of the functionality that is provided by the other backends.

OpenGL is a rendering library. Therefore, it provides several drawing procedures to operate in image space

but, in most cases, objects do not have a parametric representation. Thus, this makes it difficult to implement

some geometric transformations that CAD applications provide such as, loft and sweep. Therefore, it is only

one of the several challenges to support OpenGL as a backend. However, it is eventually planned to integrate

Rosetta.

Finally, the third design principle mentioned provided a strong correlation between programs and models.

That means it would be possible for the architect (1) to point to program elements to identify the correspond-

ing model elements, and (2) to point to model elements to determine the corresponding program elements.

Fortunately, Rosetta implements a traceability mechanism. Therefore, designers can use both approaches at

the same time, moving from one to the other as necessary, thus accelerating the development process.

For example, Figure 5.5 illustrates a typical scenario where the user selects an expression in his program

and Rosetta shows the set of shapes that resulted from that expression. Note that this set contains all shapes

that were created by the expression during the complete execution of the program. Figure 5.6 illustrates the

inverse scenario, in which a user selects an element of the model in the CAD application and Rosetta highlights

the corresponding program elements and control flow.

The main advantage of using Rosetta as a pillar of development is that all these features are given to

the programmers, as a "package", without any apparent effort. However, we are confined to use the current

programming environment used in Rosetta: DrRacket. In the next section, I present relevant properties of this

environment that can benefit the implementation.

45

Figure 5.5: Rosetta traceability tool, relating program expressions to the generated shapes. The highlightedcylinders (on the left, in yellow) are produced by the highlighted expression (on the right, in blue).

Figure 5.6: Rosetta traceability tool, relating shapes to the program expressions that generated them. Thehighlighted program flow makes the highlighted cylinders (on the left, in yellow) (on the right, using redarrows).

5.2 DrRacket

DrRacket, shown in Figure 5.7, is a programming environment designed to be pedagogic and to simplify the

implementation of new programming languages and tools. It provides a text editor with the standard pro-

gramming features, such as text formatting, and syntax checking and highlighting. Programs are written in

the Definitions Window and the Run button, in the Tool Bar, compiles the program and its dependencies and

initiates its execution. During execution, the Interactions Window becomes available, providing an interac-

tive evaluator which can be used to test the running program quickly, add new definitions to the session,

experiment with different parameters or, ultimately, evaluate any expression. This evaluator is fundamental

for incremental development and interactive testing, being one of the primary sources of feedback during

46

program development.

Figure 5.7: DrRacket programming environment, showing Definitions Window and Interactions Window (ingreen) where users write and evaluate their code, and (in orange) the selected programming language andthe toolbar menu.

Despite the DrRacket properties listed above, to choose DrRacket as implementation base, we on these

three main features:

• Pedagogic. DrRacket is widely used in introductory courses for programming languages. Its environ-

ment is designed to guide the student by catching typical mistakes and explaining them in terms that

students understand. It is also useful for professional programmers, due to its sophisticated program-

ming tools, such as the static debugger, and its advanced language features, such as units and mixins.

• Sophisticated editor. DrRacket fully integrates a graphics-enriched editor which supports, in addition

to plain text, elements such as images and boxes (with comments, Racket code or XML code). DrRacket

also displays these elements appropriately in its read-eval-print loop.

• Extensible. The main tools of the DrRacket environment are implemented using the same API that is

available for extension. For example, the debugger, the syntax checker, and the stepper, despite providing

different functionalities, are implemented on top of the same API.

Finally, DrRacket helps programmers to understand the syntactic and lexical structure of their programs,

because it provides a syntax checker that annotates a syntactically correct program in five categories (1)

primitives, (2) keywords, (3) bound variables, (4) free variables, and (5) constants. When the programmer

moves the mouse over an annotated identifier, the syntax checker displays graphical arrows that point from

bound identifiers to their binding occurrence, and vice-versa. However, the syntax checker ignores the category

of comments, including its visual elements such as the images. As a result, these items are uncorrelated with

the program’s structures and behavior.

47

5.3 Implementing the proposed tools

The problem addressed in this thesis is to design and implement an interactive programming environment

for generative design that covers the needs of GD community. The approach described in Chapter 4, suggests

two interactive tools: (1) program-sketch correlation tool, which correlates sketches with code, as a result, it

significantly reduces the effort to read the code, and (2) immediate feedback tool, which executes the program

upon changes, thereby creating an interactive environment to users quickly test their ideas and, eventually,

improve their program comprehension.

5.3.1 Program-sketch correlation tool

There are two ways to correlate a generative design program with its produced model. The first is using a

sketch in the program that illustrates the intended model. The second is using the generated model, correlating

the elements of the shape with fragments of the code. The first type of correlation did not exist in Rosetta,

consequently this is a contribution of this thesis.

The program-sketch correlation tool was implemented using the power of DrRacket syntax check to

bind annotated identifiers. In this way, the images resources, already supported in the text editor, now be-

comes a new category of rich-media expressions included in the syntax check annotated types. As a result,

programmers can add in their functions, images that illustrate the purpose of that function. Therefore, this

is perfectly suitable for functions used in GD programs, because usually the output of these functions can be

visually represented by a sketch.

For example, Figure 5.8 shows a typical example where the architect defines a function that creates

a cube with spheres in its vertices. In this example, the architect can start by searching for each function

argument, moving the mouse over them, to find the meaning of these arguments in code. Inversely, as shown

in Figure 5.9, he can start from the image by moving the mouse over it, to find the meaning of these arguments

in code. Furthermore, programmers can use images in their programs, and the image inserted in the function

body acts as if it was part of the program. However, internally it continues to be a mere code comment that

does not affect the correct operation of the function.

Although images are a suitable media to represent geometric objects, textual information can also be

appropriate in some cases. For example, during the development of the program, usually, several functions

are created. Consequently, the architect may not have a sketch to document them. Furthermore, the process

to draw a new sketch, import it to the computer, and insert it in the code, is clearly more laborious than writing

a simple piece of text that describes the function. Using this method he can later complete his code with a

proper sketch, but until then the function is still documented, and he can share his code without any trouble.

Thinking about this situation, I extended the program-sketch correlation tool to support also source code

comments. Similarly to the correlation with images, users can insert a string that explains the method. This

string can be annotated with special characters to correlate its characters graphically to the function identifiers.

For example, Figure 5.10 portrays a typical situation where the architect is reading the function comment and

moves the mouse over an annotated identifier (@orthogonal-cones). Thus, immediately, some arrows are

displayed that point to the definition of that function, and also to its use in the program context. Figure 5.11

shows a different situation where the architect points to a function parameter and some arrows are displayed

to the use of that parameter, including to its explanation in the code comment.

Regarding the usability of this tool, an inherent concern already noted is related to the use of images in

the text editor. As shown in Figure 5.12, images may have arbitrary dimensions and may occupy large areas

48

Figure 5.8: Relating function arguments with image.The highlighted argument (under the cursor, in green)is illustrated in the image (on the R symbol, using bluearrows).

Figure 5.9: Relating image with function arguments.The parameter illustrated in the image (on the c sym-bol, under the cursor) is highlighted in the code (ingreen, using blue arrows).

Figure 5.10: Relating code comments with function ar-guments. The highlighted function name (under thecursor, in green) is linked to its definition and utiliza-tion in the source code (in green, using blue arrows).

Figure 5.11: Relating function arguments with codecomments. The highlighted function parameter (un-der the cursor, in green) is linked to its utilization inthe code comment (in green, using blue arrows).

of the text editor, which may cause bad experiences in the utilization of this tool, affecting the readability of

the code, and, even worse, disturbing the user in his primary task: programming.

To avoid this problem, I propose a straightforward mechanism that allows collapsing the images. As a

result, images are reduced to the height of a character sentence, using considerably less space than before

49

(e.g. see Figure 5.13). Once the picture is collapsed the programmer can easily navigate through the code,

improving his awareness of the surrounding context in a file. Furthermore, this feature can be enhanced

by DrRacket collapse S-expressions tool to elide code. However, differently from moderns code editors that

collapse the code in blocks, when the architect wants to view part of the surrounding context, he either have

to over the collapsed code to show a tool tip, possibly occluding relevant code, or expand the collapsed code

possibly moving relevant code off-screen. DrRacket omits code by replacing it with "(...)", this way the

surrounding context is still legible but uses less space. Inversely, users can expand their code as well as their

images by a simple click. Note that all information placed in the picture, i.e. the annotated positions where

the arrows will point, continue as before. However, when an image is collapsed this change is not persisted in

the stored file, it just sets the dimensions ports of the window visualization. Consequently, the programmer

needs to perform this operation every time he starts a new session.

Figure 5.12: Inserting in the text editor an image withlarge dimensions. The function body is separated fromits head definition due the large dimensions occupiedby the image.

Figure 5.13: Collapsing the image and some s-expressions. The code is collapsed, tidy, and the sur-rounding context is still legible.

In order to automatically recognize symbols in images and binding them with code identifiers, the pre-

sented architecture, in Chapter 4, suggested the use of an OCR engine. Thus, the OCR engine is intended

to receive the images, process their optical characters, and return the characters found with their respective

coordinates on the picture. The first approach taken followed this description, sending the sketches, such as

the one shown in Figure 5.8, to the OCR. Unfortunately, this process was unfruitful, mainly because the tech-

nologies used in the current OCR engines have several problems to identify handwritten symbols (especially

in the case of mathematical annotations) and they fail to recognize correctly the symbols used in the sketches

in (almost) 100% of the times.

However, to finish the implementation of this tool without depending on the correct functioning of the

OCR engine, I implemented a fallback mechanism that allows users to perform the OCR work. This way, when

the first image of a function body is inserted in the code editor, it is blindly annotated with the same position

for all function parameters. As a result, DrRacket check syntax will draw binding arrows, from the center of

the image, to the function arguments, and vice-versa. For example, Figure 5.14 shows precisely this moment,

after the picture is inserted in the function body. At this point, it is up to the programmer to change the bind

50

position of each parameter to the correct position; the tool does not require this action.

Figure 5.14: After inserting, in the text editor, thefirst image to illustrate the function parameters. Thearrows (in blue) come from the center of the image(under the cursor) to the highlighted parameters (ingreen).

Figure 5.15: Choosing the correct position for thefunction parameter p. The coordinates of the point p(illustrated in the image) as well as its correspondentfunction parameter is shown in the GUI.

Figure 5.16: Showing the correct binding associationof the parameter p.

Figure 5.17: Finishing the process setting all the imagesymbols in their proper place.

Further, to finalize this process and have the right associations between image symbols and function

identifiers, an alternative method was implemented. So, if the programmer clicks in any space of the picture,

a GUI will appear showing three fields: (1) the parameter field, that is empty by default, and it is intended

to specify the name of the clicked symbol, which, of course, must match with the function parameter name;

51

(2) the x; and (3) the y fields, that defines the width and height of the coordinate respectively. These areas

are filled by default with the clicked position got from the image space. However if the user wants to specify

another value, it is also possible.

Figure 5.16 shows the effect of setting a single function parameter using this method. As we can see, the

other parameters stay in the same position. Moreover, to correct the others associations the programmer must

repeat this process for each parameter. For example, Figure 5.17 shows the final result where all parameter

is correctly identified. As a result, DrRacket can draw arrows directly to each one of them. Note that; this

process is only performed once because the information associated with the image is stored with the source

code file.

5.3.2 Immediate feedback tool

As discussed previously, despite the apparent advantages of using a GD approach to model geometric objects,

this method presents, at least, one important drawback that affects the design process. Architects cannot

interact with their models as they build it. Any change in the model must be performed first in the code, and

only after the program is compiled and executed the alterations will be available on the model. This process

apparently takes more time than the traditional approach of manually building the model in the CAD tool.

Besides, it discourages the artistic work because the changes are more costly than just manipulating a GUI

element.

In Chapter 4 we suggested the Immediate feedback tool that aims to overcome this limitation, trying

to promote the creative work in the design phase. This tool seeks to reduce as much as possible the time be-

tween a change in the code and its visualization in the model. Several techniques were suggested particularly

considering the current state of GD environments.

Regarding some of these proposed methods, and trying to put them in practice, I implemented the im-

mediate feedback tool on top of DrRacket. Once DrRacket is the programming environment used by Rosetta,

any improvement achieved in this programming environment will be useful for both systems. So, I started by

extending the current DrRacket environment developing an external tool, i.e. a plugin. The plugin was used

to access the DrRacket API without having to modify it.

Therefore, to use this tool users can install it separately, and uninstall it at any time. Once the tool is

installed, a new icon will appear on the top of DrRacket Tool Bar. This icon has a symbol (similar to the

DrRacket Run icon) and a description. However it has a responsive behavior: if the DrRacket window is too

small the description will be omitted to save space and maintain the interface cohesive. When the user clicks

on it, its color changes meaning that it is in action. Immediately after clicking, apparently nothing will occur

until an expression is ready for evaluation.

For example, Figure 5.18 shows an example where the Auto Run tool is activated and the programmer is

writing the factorial function. At each character insertion, this tools is desperately trying to execute the code.

However, to perform this action, the code needs to be syntactically correct. On the other hand, the Check

Syntax is validating the code, catching any syntax error and showing them at the bottom bar. Furthermore,

when Check Syntax finishes its validation, and the code is syntactically correct, the AutoRun tool can operate.

So it gets all the code validated previously, creates a callback, and sends it to the DrRacket evaluator. As a

result, the code is immediately executed, as shown in Figure 5.19.

Unlike the factorial function that returns a numeric output, the functions in GD return a visual object. In

this context, this tool is even more useful, because the changes made in the code causes a visual effect in the

52

Figure 5.18: Using the Auto Run tool (in dark green)when writing the factorial function. The highlightedexpression is incomplete.

Figure 5.19: Immediately after closing the rightbracket of the highlighted expression. The InteractionsWindow is shown with the function result.

geometric object. The combination of this technique with the generated objects can provide an interactive

environment, to experiment new ideas and test parametric models quickly.

However, the experimentation of program inputs relies heavily on the keyboard, breaking the fluidity of

this process. For this, I used the DrRacet a widget mechanism to provide sliders at the program input. Thus,

users can drag the slider to change the program input, rather than delete and insert a new character. Each

shift in the slider causes an execution of the program with the new slider value. In GD programs this will

generate a new geometric model. As a result, users can check if that value created the desired shape.

Figure 5.20: Using the slider widget with Auto Run tool active, to experiment some input values. The high-lighted function call (at line 13, on the left) is being changed by the slider (over the pointer). On the right,are the generated shapes rendered by AutoCAD.

53

Figure 5.20, shows the use of this tool to generate some geometric shapes. Despite the notable difference

among the created forms, the function used to produce them is the same (this function is also shown in

Figure 5.10). Therefore, the programmer can experiment several input values by just dragging the slider,

once he achieved an intended design he can copy that line of execution (as a code comment for instance) and

continue to experiment other values. The slider appears on top of a selected input number, to facilitate this

process. It has a compressed window without any extra buttons, as a way to be integrated with the text editor.

Thus, users only need to click back into the text editor to close this window and be back to edit code.

Regarding the usability of this tool, the faster will be the backend response as better will be the user’s

experience. For example, consider the function orthogonal-cones (shown in Figure 5.10), its execution

time is relatively straightforward (e.g. in AutoCAD backend it takes approx. 1 second, as shown in Table 5.1).

This is a tolerable delay between a model update, however using a more compounded geometry, such as the

Möbius Truss, in Figure 5.4, or even a complex geometry, such as a building, the execution time can grow

considerably, and the immediate feedback becomes almost impossible.

5.4 Implementation Details

5.4.1 General architecture

Figure 5.21 presents the general architecture of the solution, in a publish-subscribe view. There are two

different interactions in this architecture, the first presented by a publish-subscribe, and the second by a

client-server.

1. The main functionality of the proposed environment is made through a publish-subscribe interaction.

The DrRacket UI event manager acts as an event bus for user-interface events (such as button

clicks, character insertion, etc.). From this event bus, I subscribe only the UI events which are relevant

to the system, defining which components will handle them. It is done at load time when the event

manager reads the plugin configuration file (i.e. info file). When users are working on the editor, an

UI event is generated and dispatched via implicit invocation to the action handler objects that subscribe

to that event.

2. Despite the presented solution does not include the automatic character recognition, this module is part

of the planned architecture, and can be considered, for a future integration. Thus, a client-server in-

teraction will be needed to automatically recognize the manuscript symbols present in the image, using

to this end an external OCR engine. Thereby in the suggested architecture the symbol identifier

component calls this service to handle the recognition of symbols in the image. However, in the imple-

mented architecture this component generates by itself the OCR data and all other modules continue to

work as before.

The tool core component, in Figure 5.21, receives, three relevant kinds of DrRacket events. For each

of these events, the programming environment is changed executing the following actions:

• on-change: when DrRacket detects that the editor has been modified, it sends the contents of the edi-

tor over to action handlers. In this case, it sends this information to the online expansion handler

where the code is expanded. Executed action: sends a execute event to the editor frame, if the action

handler expanded the code successfully.

• on-paint: this event is sent just before and just after every element is displayed in the editor. Handling

54

Figure 5.21: Diagram for a publish subscribe view of the proposed architecture. The arrow, in red, on top ofthe symbol identifier module shows the implemented architecture.

this event provides a way to add arbitrary graphics to the editor screen. Executed action: sends a show

event to the editor frame, to display a slider widget when the user presses the mouse over a literal.

• on-new-image-snip: this event is sent when an image is inserted in the editor. The default im-

plementation creates an image snip which is an object with the image information, such as path and

format. Executed action: returns a subclass of image snip, containing an extra meta-data associated with

the symbols in the sketch.

5.4.2 Binding association

One of the first problems addressed in this thesis, and perhaps the most challenging one is finding an adequate

framework that facilitates the correlation between image resources and code. When we consider DrRacket

environment, this problem seems to have a straightforward resolution: DrRacket already provides support for

media-rich data, and also a syntax check mechanism that graphically shows arrows from binding variables

to their bound occurrences. Thus, the initial idea was to use the power of Syntax Check mechanism to bind

variables to image as well. However, implementing this plan was harder than expected.

Following the initial idea, the first step was finding out the internal mechanism used by DrRacket to

graphically show the arrows on mouse over. So, on each event, in the text editor, Check Syntax tool expands

the program, annotating each identifier with syntax properties. Thereafter, to draw the arrows, it will look

at a particular property added previously, named 'sub-range-binders, which contains the necessary in-

formation to draw the arrows, such as the source and target location. This property is added only to syntax

identifiers that exist in the program context. Therefore, any literal, comment, image or any other category are

ignored.

1 (define−syntax (define/img stx)2 (syntax−case stx ()3 [(_ (name param ...) img body ...)

55

4 #‘(define name

5 (lambda/point #,(map (lambda(x) ‘(,x 0.5 0.5))

6 (syntax−e #’(param ...)))7 img

8 body ...))]))

Listing 5.1: Showing the initial solution. The macro define/img receives a syntax and returns a modified

syntax, where the img is treated as an identifier associated to each function param.

To overcome this problem the decision made was to assume that the image will be inserted in the function

body immediately after its definition. In this way, a syntactic transformer, i.e. macro, was created to handle

the image, creating empty identifiers to bind its lexical context. For example, the Listing 5.1 shows a macro

that matches the pattern of line 3, i.e. it assumes that the syntax object img is inside the function body, then

it calls lambda/point to create binding associations between the image and the parameters. At line 5, the

two constants 0.5, defines the center position of the arrow in the picture space. The possibility of varying

the source position of the arrow indicators was not initially part of DrRacket API. Therefore, an additional

implementation was requested to DrRacket authors.

Unfortunately, using the previous solution users cannot change the position of the arrows to different

zones of the image. For example, the function (define/img (func foo bar baz) ...) will expand to

the code shown in Listing 5.2. As we can see, in line 1, each parameter is wrapped in a list with two values

that define a coordinate point (0.5, 0.5). This point represents the center of the image, where all parameters

are statically associated. Therefore, the parameters of function func will point to the center of the image,

being impossible to change them.

1 (define func (lambda/point ((foo 0.5 0.5) (bar 0.5 0.5) (baz 0.5 0.5))

2 img

3 body ... ))

Listing 5.2: Showing the exapansion of the macro lambda/point.

To solve this problem, the parameter coordinates previously passed as a constant were obtained during

the macro expansion. The main challenge of this solution was finding out a way to access this information

in the macro context, because the syntactic object, received in the macro, which represents the image, i.e.

img, does not exist yet. The syntax transformation is done in compile time, and this object is only completely

available at run time. Therefore, any attempt to make a function call using this syntactic object will fail. Once

the traditional methods used to access an object field does not work, other strategies were considered.

After several attempts to add extra information in a image, such as use an external tool to write in the

bitmap fields, up to use libraries that allow rewrite image metadata, the final solution was extend an existing

DrRacket class. In this way, the information required to bind code with the picture was stored in a field of

this new class. Using this class, it was possible to have control over the syntax reader process, annotating

the image with the information required by the macro at compile time. Thus, to access the picture metadata

during the macro expansion, a single line of code, as shown in Listing 5.3, was added between the line 3 and 4

of Listing 5.1. Moreover, this class implements several other facilities which are described in the next section.

(let ((metadata (syntax−property #’img ’args)))

Listing 5.3: Accessing the image metadata by reading the syntax property ’args.

56

5.4.3 Image-data-snip

The image-data-snip% class, shown in Figure 5.22, has a fundamental role in the correlation between im-

age and code. This class provides facilities such as create, read, store and access the coordinates associated to

each function parameter. Therefore, the original class used in DrRacket to display images, i.e. image-snip%,

was extended with a hash table field which contains the parameter identifiers, as a key, and their coordinates,

in the image space, as a value. Moreover, this class implements its syntax read method to provide the picture

metadata through the macro expansion.

Figure 5.22: The UML diagram of the implemented class, image-data-snip%. This class extends the originalDrRacket snip class, and implements its own read syntax method.

Because image-data-snip% is a subclass of image-snip%, it saves code and its associated metadata

in ASCII-encoded binary format. This class uses the superclass method to store the image, but the methods

for copying, reading, and storing the metadata field, were implemented from scratch. Unfortunately, the

final serialized file does not provide backwards-compatibility among other text editors. However, the effort to

implement this feature was more acceptable when considering the approach suggested in Chapter 4.

Despite the beginning effort spent to implement this class, other features can benefit from this work. For

example, the feature for expanding/collapsing images was applied on top of this class using only a few lines

of code. Once the subclass already provides a method for resizing snips, this feature does a simple, super

class call to change the size of the snip window. Moreover, this class defines a basis for other features that

manipulates, or even edits, the image inserted in the text editor.

5.4.4 Auto Run

The core of AutoRun plugin is based on the snip of code shown in Listing 5.4. This sample of code registers

a pair of procedures with DrRacket’s online expansion machinery. The first two arguments name a method

in a module that is loaded by dynamic-require. When DrRacket detects that the editor has been modified, it

sends the contents of the editor to that separate place, expands the program there, and then supplies the fully

expanded object. Then, this procedure (defined at line 4-7) gets the DrRacket editor frame (at line 6) and

executes the code in that frame using the execute-callback function (at line 7). Therefore, upon a change

in the text editor, DrRacket will execute the code immediately.

57

1 (drracket:module−language−tools:add−online−expansion−handler2 online−comp.rkt3 ’go

4 (lambda ()

5 (...) ; c o l l a p s e d code

6 (define drr−frame (send (send defs−text get−tab) get−frame))7 (send drr−frame execute−callback)))

Listing 5.4: Executing the program through DrRacket execute-callback.

When this plugin is installed, it can become quite evasive once it is running code without the user per-

mission. To avoid this situation, the plugin is installed as a button in DrRacket’s toolbar, having two operating

modes. First, it is in disabled mode, which means that users can edit the code as before, and this plugin will

have no effect in DrRacket. Second, when it is on enable mode, it tries to execute the code at each change.

However, to change the plugin methods, users must authorize it, by clicking in the plugin button.

Finally, to improve this tool an interactive mechanism to give inputs to the program was implemented,

using the DrRacket slider widget. In this way, when a program literal is selected, and a keybinding is pressed,

a slider appears on top of that literal. So, when the slider is dragged, the editor changes, which causes the

AutoRun plugin to execute the code.

Unfortunately, adapting the range of values in the slider, interactively as users drag it, becomes difficult

or even impossible to implement, using the DrRacket slider. To create a new slider is necessary to define the

range and the initial value of that slider. However, to update these initial values, after the slider window is

shown, the frame must be closed and opened again, which goes against the purpose of this tool.

5.5 Conclusion

Based on the ideas proposed in Chapter 4, this chapter evaluates them, showing a coherent implementation.

Then, it highlights the decisions made during the development of these tools, as well as the system used as a

basis for implementation. Moreover, it shows the achieved results, presenting the architecture of the solution,

the problems found, and how we overcame them. Next chapter shows a practical experiment conducted with

these tools.

58

6Practical Experiments

The previous sections described the implementation of the tools proposed in Chapter 4. This chapter completes

the implementation, evaluating these tools with practical experiments, namely using the sketch-program cor-

relation tool to illustrate GD programs, and the immediate feedback tool to interactively generate geometric

models.

6.1 The experiment

The conducted experiment started by asking a group of architects (composed by 3 architects) to install the

plugin, in their programming environment. Moreover, to facilitate this process, the source code was placed

in a repository publicly accessible. Thus to complete the installation, the users copied the repository URL link

into DrRacket Package Manager and the plugin was automatically installed. Once the installation completes,

DrRacket was able to load the implemented tools as part of its programming tools.

It is important to note that the target users that collaborated in this experiment were familiar with GD

methods. Some of them had already their GD programs documented with sketches. Therefore, to test the ca-

pabilities of these tools in real use cases, we suggested them to (1) document a function using a proper sketch,

completing the process to associate the function parameters with its illustrated symbols, and (2) explore the

immediate feedback tool, using Rosetta tool with an adequate backend, and a parametric model that produces

geometry in less than 1 minute.

6.2 Program-sketch correlation tool

Figure 6.1 shows a GD program that has their parameters illustrated in a sketch. In this example, the architect

did the design manually, using a piece of paper, then she painted the intended shape using parametric variables

to annotate it. Then, the final sketch was scanned, and inserted into the code. Immediately after this process,

she moved the mouse over the image and some arrows appeared from the center of the image to the function

parameters.

Figure 6.2 concludes the prior process showing the result of correcting the associations between the

parameters and its symbols. The architect, followed the mechanism explained in Section 5.3.1 to bind each

parameter of the function to a place in the image. Note that, in this example, all arrows are visible because

she moved the mouse over to the picture.

Figure 6.3 shows a real GD project that models each piece of a turbine. In this figure, some parts of the

program are illustrated with three different sketches. Unlike the previous example, these sketches were done

using a drawing tool. In fact, these images were already included in the program, but were not correlated

59

with the code. To use this tool the architect just moved her sketches into the function body, corrected the

binding associations, and clicked on Check Syntax button. Therefore, she pointed to a parameter of a function

fan-blad and immediately sees its meaning in the image. In this example, we can see the scalability of this

tools in a real use case.

Figure 6.1: After inserting a sketch in the functionbody.

Figure 6.2: After correcting the associations betweenthe function parameters and its symbols.

While the sketches used in the previous examples were intentionally made to illustrate the context of that

function, Figure 6.4 shows a sketch in an initial phase of design. In this example, the architect collapsed the

s-expressions and pointed to the parameter a. Then an arrow links the parameter a to the image, and other

to the s expression. On the right, the sketch was collapsed reducing the function to a few lines of code.

60

Figure 6.3: Correlating existing sketches with code.

Figure 6.4: Collapsing the sketch.

6.3 Immediate feedback tool

Figure 6.5, Figure 6.6, and Figure 6.7 show a sequence of spheres, on the left, rendered by Autocad backend

using the function n-spheres, defined on the right. In this example, the architect enabled the active mode in

AutoRun plugin and used the slider widget to change the input of n-spheres function.

Figure 6.8 and Figure 6.9 show the generation of two different shapes of turbines by varying an angle

between the fans using a slider. In this example, the architect triggered the slider widget over an angle

denominator. Then, she moved the slider to generate a new geometric model in AutoCAD.

61

Figure 6.5: Changing n-spheres input to 8 spheres using a slider.



Figure 6.10 shows an example of an architect that unable to use her preferred backend in her operating

system, decided to test the AutoRun tool using the factorial function. This example shows DrRacket running

on top of MAC OS, supporting the instant feedback mechanism. The slider was used to vary the factorial input,

displaying the result in the interactions window. As we can see this tool is independent of the Rosetta tool

and, in this example, was applied to a custom user function.

62

Figure 6.8: Using a slider, on the left, to arbitrarily change a number value in the program. The angle de-nominator has been modified to 3, producing, on the right, the turbine shape with its fans placed over acircumference of 2π radians.

Figure 6.9: Using a slider, on the left, to arbitrarily change a number value in the program. The angle de-nominator has been modified to 6, producing, on the right, the turbine shape with its fans placed over acircumference of π radians.

63

Figure 6.10: Running factorial function using the slider.

64

6.4 Conclusion

The proposed tools, namely the immediate feedback and sketch correlation program tool, were evaluated

based on two distinct forms: (1) during the development phase, and (2) after the implementation, as a

validation test performed by the target users. In the first stage, I performed a functional analysis, checking if

the added features do not interfere with the correct behavior of the programs. After concluding this phase,

the tools were ready to be tested by the final users. In the second stage, I tested these features with users and

collected some interesting feedback.

It was an interactive process, as I was receiving the users comments I was fixing the tools. For example,

some relevant comments are described as follows:

• Sketch-program correlation tool was reported as a useful tool to document programs, adding a rich source

of information for who will use the code. However, some users has trouble to use the fallback mechanism

to correct the image pointing arrows. The reported bug was that the key bindings associated with this

feature did not work on some operating systems. To fix this problem, the keybindings were changed to

a single right click to expand or collapse the images, and a single left click to set its parameters. After

this improvement, the reported user experiences were substantially better.

• On the other hand, AutoRun had no issues related to its use; it works correctly on all operating systems,

including the slider mechanism. However, a very requested feature was the adaptative slider, which

means dynamically changing the slider interval range based on the currently selected value. Unfortu-

nately, as discussed in Chapter 5, this feature is inherently limited by the used DrRacket slider UI.

65

7Conclusions

The representation of source code dramatically affects its comprehensibility and usability (Baecker and Mar-

cus, 1986). In this thesis, we found that by using image resources, namely sketches and diagrams, applied

to generative design programs it is possible to enhance the program visualization. Moreover, accelerating

the program execution allows users to test their mental models (Brooks, 1977; Robins et al., 2003) quickly.

In fact program comprehension is improved because (1) source code becomes documented with media-rich

resources, and (2) the effect of changes in the program becomes instantly visible.

Based on Learnable Programming and Literate Programming we propose an interactive environment tai-

lored for generative design. This programming environment helps the designer in establishing a strong cor-

relation between the GD program, and the geometric sketches that it represents, as a result, it eliminates the

first barriers to learning, allowing designers to read the code and to understand it at a higher level. It also

encourages the developer to test his ideas quickly, by seeing the result of his action.

Among the generative design systems which support programming in a textual form (Aish, 2012; Lopes

and Leitão, 2011), only one (Lopes and Leitão, 2011) supports other elements in the editor, besides plain text.

However, none of them associates the source code with images nor even supporting any correlation between

them. On the other hand, the only way to get immediate feedback in these systems is by a stepwise debug

which stops the entire program execution, disabling code to be edited. So in debug mode users can only

change single lines of execution, making it difficult, or even impossible, to have immediate feedback.

Immediate feedback avoids the edit-compile-run cycle, anticipating as much as possible the result of a

change in the code. When this mechanism is associated with Rosetta tool, it creates a playground where

architects can create models interactively. So, this tool promotes the essential aspect in Architecture: the

creativity. However, similar to what happens with all other GD systems, this tool will not scale for all GD

programs, due to the render performance of CAD tools. Therefore, using Rosetta architects can use a faster

backend to test their ideas, then moving to their preferred backend.

Sketch-program correlation mechanism promotes the documentation in GD programs besides it correlates

the source code with images. However, to associate images with code users must intervene in this process by

strictly identifying the symbols in the picture with the identities in the program. Integration with OCR engine is

part of the system architecture, however due to the bad experiences in using the OCR to recognize handwritten

symbols, we skipped this step in the actual implementation.

In this thesis, several features were proposed, the majority of them based on successful research projects.

For example, the idea of improving the context view of statement blocks by allowing users to focus on the

main fragment of code was proposed in Barista (Ko and Myers, 2006) project, and we used it to implement

the expand/collapse feature. Like this idea, other helpful features and strategies were discussed, such as how

67

to serialize images with code, how to prevent that images impair in the usability of the code text editor, among

others.

The implemented tools just define a first path to follow. Future work, regarding the program-sketch tool

would (1) integrate the OCR engine in the current flow, (2) provide facilities to allow users to edit images

directly in the code editor, (3) provide flexibility to bind any program fragment to any picture. Regarding

the immediate feedback tool, feature work would (1) create an adaptative sliders widget, (2) study a better

mechanism to predict the slider values, (3) implement in CAD backends the possibility to show differences

between model changes, and (4) implement the autocomplete tool that immediately executes the selected

expression in the list of options.

We believe that there is a bright feature ahead for innovations in programming environments, and we

hope that implementation programming tools like those discussed in this thesis will make such innovations

more feasible, more usable, and more useful.

68

Bibliography

R. W. Hamming, The Art of Doing Science and Engineering: Learning to Learn. Boca Raton, Florida, USA: CRC

Press, 2003.

F. P. Brooks, “No Silver Bullet – Essence and Accidents of Software Engineering,” IEEE Computer, vol. 20, no. 4,

pp. 10–19, 1987.

S. Rugaber, “Program Comprehension,” Encyclopedia of Computer Science and Technology, vol. 35, no. 20, pp.

341–368, 1995.

R. Brooks, “Towards a theory of the cognitive processes in computer programming,” International Journal of

Man–Machine Studies, vol. 9, no. 6, pp. 737–751, 1977.

J. DesRivieres and J. Wiegand, “Eclipse: A platform for integrating development tools,” IBM Systems Journal,

vol. 43, no. 12, pp. 371–383, 2004.

D. Carlson, Eclipse Distilled. Cambridge, Massachusetts, USA: Addison Wesley Reading, Feb. 2005.

T. Boudreau, J. Glick, S. Greene, V. Spurlin, and J. J. Woehr, NetBeans: the definitive guide. Boston, USA:

O’Reilly Media, Inc., Nov. 2002.

H. Böck, “IntelliJ IDEA and the NetBeans Platform,” in The Definitive Guide to NetBeansTM Platform 7. New

York, NY, USA: Springer, 2011, pp. 431–437.

S. Guckenheimer and J. J. Perez, Software Engineering with Microsoft Visual Studio Team System (Microsoft.

NET Development Series). Addison-Wesley Professional, 2006.

S. Papert, Mindstorms: Children, computers, and powerful ideas. New York, NY, USA: Basic Books, Inc., July

1993.

A. C. Kay, “The early history of Smalltalk,” in History of programming languages — II. New York, NY, USA:

ACM, 1996, pp. 511–598.

C. Reas and B. Fry, “Processing: Programming for the media arts,” AI & SOCIETY, vol. 20, no. 4, pp. 526–538,

2006.

R. B. Findler, J. Clements, C. Flanagan, M. Flatt, S. Krishnamurthi, P. Steckler, and M. Felleisen, “DrScheme: A

programming environment for Scheme,” Journal of functional programming, vol. 12, no. 02, pp. 159–182,

2002.

P. J. Guo, “Online Python Tutor: Embeddable Web-based Program Visualization for CS Education,” in

Proceedings of the 44th ACM Technical Symposium on Computer Science Education, ser. SIGCSE ’13. New York,

NY, USA: ACM, 2013, pp. 579–584. [Online]. Available: http://doi.acm.org/10.1145/2445196.2445368

69

http://doi.acm.org/10.1145/2445196.2445368

S. McDirmid, “Usable live programming,” in Proceedings of the 2013 ACM international symposium on New

ideas, new paradigms, and reflections on programming & software. New York, NY, USA: ACM, 2013, pp.

53–62.

R. Aish, “DesignScript: origins, explanation, illustration,” in Computational Design Modelling. Springer, 2012,

pp. 1–8.

J. Lopes and A. Leitão, “Portable generative design for cad applications,” in Proceedings of the 31st annual

conference of the Association for Computer Aided Design in Architecture, 2011, pp. 196–203.

J. McCormack, A. Dorin, T. Innocent et al., “Generative Design: a paradigm for design research,” Proceedings

of Futureground, Design Research Society, Melbourne, 2004.

E. Y.-L. Do and M. D. Gross, “Thinking with diagrams in architectural design,” in Thinking with Diagrams.

New York, NY, USA: Springer, 2001, pp. 135–149.

S. C. B. Souza, N. Anquetil, and K. M. de Oliveira, “A study of the documentation essential to software mainte-

nance,” in Proceedings of the 23rd annual international conference on Design of communication: documenting

& designing for pervasive information, no. 7. New York, NY, USA: ACM, 2005, pp. 68–75.

M. J. C. Sousa and H. M. Moreira, “A survey on the software maintenance process,” in Software Maintenance,

1998. Proceedings., International Conference on. IEEE, 1998, pp. 265–274.

B. Victor, “Learnable Programming – Designing a programming system for understanding programs,” Retrieved

from http://worrydream.com/LearnableProgramming, Jan. 2014.

——, “Inventing on principle,” Invited talk at the Canadian University Software Engineering Conference

(CUSEC), Montreal, Canada, Jan. 2012.

L. E. Winslow, “Programming pedagogy – a psychological overview,” ACM SIGCSE Bulletin, vol. 28, no. 3, pp.

17–22, 1996.

A. Robins, J. Rountree, and N. Rountree, “Learning and teaching programming: A review and discussion,”

Computer science education, vol. 13, no. 2, pp. 137–172, 2003.

M. Krüger, J. P. Duarte, and F. Coutinho, “Decoding De Re Aedificatoria: using grammars to trace Alberti’s

influence on Portuguese classical architecture,” Nexus Network Journal, vol. 13, no. 1, pp. 171–182, 2011.

I. M Rocker, “When code matters,” AD - Architectural Design, vol. 76, no. 4, pp. 16–25, 2006.

B. M. Kolarevic, Clayton and G. V. de Velasco, “Eternity Infinity and Virtuality in Architecture,” Proceedings

of ACADIA 2000: Eternity, Infinity and Virtuality, Washington D.C., USA: ACADIA-Association, no. 4, pp.

251–256, 2000.

J. Maeda, Design by numbers. Cambridge, Massachusetts, USA: Mit Press, 2001.

K. Terzidis, Expressive Form: A conceptual approach to Computational Design. New York, NY, USA: Spon Press,

2003.

A. Kilian, “Design innovation through Constraint Modeling,” International journal of Architectural Computing,

Multi Science Publishing, vol. 4, no. 1, pp. 87–105, 2006.

C. Kelleher and R. Pausch, “Lowering the barriers to programming: A taxonomy of programming environments

and languages for novice programmers,” ACM Computing Surveys (CSUR), vol. 37, no. 2, pp. 83–137, 2005.

70

http://worrydream.com/LearnableProgramming

G. C. Murphy, M. Kersten, and L. Findlater, “How are Java software developers using the Elipse IDE?” Software,

Piscataway, NJ, USA: IEEE, vol. 23, no. 4, pp. 76–83, 2006.

B. Alpern and F. B. Schneider, “Defining liveness,” Information processing letters, vol. 21, no. 4, pp. 181–185,

1985.

S. L. Tanimoto, “A perspective on the evolution of live programming,” in Live Programming (LIVE), 2013 1st

International Workshop on. IEEE, 2013, pp. 31–34.

N. D. Matsakis and F. S. Klock II, “The Rust Language,” ACM SIGAda Ada Letters, vol. 34, no. 3, pp. 103–104,

2014.

D. Griffiths, “Fluxus,” in Collaboration and learning through live coding, Report from Dagstuhl Seminar, vol.

13382, 2007, pp. 149–150.

R. B. Findler and M. Flatt, “Slideshow: functional presentations,” in ACM SIGPLAN Notices, vol. 39, no. 9.

ACM, 2004, pp. 224–235.

B. A. Myers, “Taxonomies of visual programming and program visualization,” Journal of Visual Languages &

Computing, vol. 1, no. 1, pp. 97–123, 1990.

A. Leitão and L. Santos, “Programming languages for generative design: Visual or textual?” in Zupancic, T.,

Juvancic, M., Verovsek., S. and Jutraz, A., eds., Respecting Fragile Places, 29th eCAADe Conference Proceedings,

University of Ljubljana, Faculty of Architecture (Slovenia), Ljubljana, 2011, pp. 549–557.

S. Wolfram, Mathematica: A system for doing mathematics by computer. Cambridge, Massachusetts, USA:

Addison Wesley Longman Publishing Co., Inc., July 1991.

——, “Wolfram research,” Inc., Champaign, Mathematic, vol. 3, pp. 375–381, 2003.

Pérez, Fernando and Granger, Brian E., “IPython: A System for Interactive Scientific Computing,” Computing

in Science and Engineering, IEEE Computer Society, vol. 9, no. 3, pp. 21–29, May 2007. [Online]. Available:

http://ipython.org

C. Granger, “Light Table – A new IDE concept,” Retrieved from http://lighttable.com, Jan. 2014.

A. Goldberg and D. Robson, Smalltalk-80: the language and its implementation. Cambridge, Massachusetts,

USA: Addison-Wesley Longman Publishing Co., Inc., 1983.

R. C. Seacord, D. Plakosh, and G. A. Lewis, Modernizing legacy systems: software technologies, engineering

processes, and business practices. Addison-Wesley Professional, 2003.

T. M. Pigoski, Practical software maintenance: best practices for software investment. John Wiley & Sons, Inc.,

1996.

S. L. Pfleeger and J. M. Atlee, Software Engineering: theory and practice (2nd Edition). New York, NY, USA:

Pearson Education, 2001.

L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice (3rd Edition) (SEI Series in Software

Engineering), 3rd ed. Addison-Wesley Professional, Oct. 2012.

S. W. Ambler, “Agile/Lean Documentation: Strategies for Agile Software Development,” IEE Computer Society,

vol. 20, pp. 307–317, May 2007.

A. Forward and T. C. Lethbridge, “The relevance of software documentation, tools and technologies: a survey,”

in Proceedings of the 2002 ACM symposium on Document Engineering. ACM, 2002, pp. 26–33.

71

http://ipython.org

http://lighttable.com

R. Baecker and A. Marcus, “Design principles for the enhanced presentation of computer program source text,”

in ACM SIGCHI Bulletin, vol. 17, no. 4. ACM, 1986, pp. 51–58.

——, “Graphic design of program text,” Lawrence Berkeley Lab., CA (USA); Human Computing Resources

Corp., Toronto, Ontario (Canada), Tech. Rep., 1982.

——, “On enhancing the interface to the source code of computer programs,” in Proceedings of the SIGCHI

conference on Human Factors in Computing Systems. ACM, 1983, pp. 251–255.

A. J. Ko and B. A. Myers, “Barista: An implementation framework for enabling new tools, interaction tech-

niques and views in code editors,” in Proceedings of the SIGCHI Conference on Human Factors in Computing

Systems. ACM, 2006, pp. 387–396.

S. Oney and J. Brandt, “Codelets: linking interactive documentation and example code in the editor,” in

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2012, pp. 2697–2706.

A. J. Ko and B. A. Myers, “Citrus: a language and toolkit for simplifying the creation of structured editors for

code and data,” in Proceedings of the 18th annual ACM symposium on User interface software and technology.

ACM, 2005, pp. 3–12.

A. J. Ko, Personal communication, Aug. 2015.

D. E. Knuth, “Literate programming,” The Computer Journal, New York, NY, USA: Br Computer Society, vol. 27,

no. 2, pp. 97–111, 1984.

S. Mori, H. Nishida, and H. Yamada, Optical Character Recognition. Toronto, Canada: John Wiley & Sons,

Inc., Apr. 1999.

R. Smith, “An overview of the Tesseract OCR engine,” in ICDAR. IEEE Computer Association, 2007, pp.

629–633.

A. J. Ko, H. H. Aung, and B. A. Myers, “Design requirements for more flexible structured editors from a study

of programmers’ text editing,” in CHI’05 extended abstracts on human factors in computing systems. ACM,

2005, pp. 1557–1560.

A. Sorensen, “Impromptu: An interactive programming environment for composition and performance,” in

Proceedings of the Australasian Computer Music Conference 2009, 2005.

72

An Enhanced Programming Environment for Generative Design

Documents

Transcript of An Enhanced Programming Environment for Generative Design