We can avoid all this contant copying and pasting, and at the same time make our programs much shorter, by storing the centred_square command into a separate module (i.e. a file containing just commands) and then loading the module into every program that requires centred squares. If an error in the algorithm is found, only the module is changed and all programs will work, because they always load the newest version of the module when they start executing.

Having one different module for each command we define is the most flexible option, so that each program only loads those commands it needs, but is a bit cumbersome. A better option is to store related commands in the same module, in order to build libraries of reusable algorithms. A program may use just a subset of the commands defined in a module. For our running example, we copy the centred_square command into a file called shapes.dbn:

// shapes library
// version 1, 30 Oct 2008, Michel Wermelinger
// centred_square command

command centred_square left
// draw a centred square, given the left coordinate
{
   set bottom left
   set centre 50
   set distance (centre - left)
   set right (centre + distance)
   set top right

   line left bottom right bottom
   line right bottom right top
   line right top left top
   line left top left bottom
}

In file tunnel.dbn we replace the centred_square command definition by  DBN’s load command.

// the tunnel
// version 4, 30 Oct 2008, Michel Wermelinger
// put command in external library

load shapes.dbn

line 0 0 100 100
line 0 100 100 0
centred_square 20
centred_square 40

To recap, this and the previous two lessons introduced three different fundamental programming concepts, all relating to abstraction:

• variables allow us to abstract concrete values into general concepts
• sub-programs (called commands in DBN) allow us to abstract sequences of computational steps into named algorithms
• modules allow us to abstract related commands into reusable libraries

In the next lesson we get back to drawing: we introduce the use of grey scales to reinforce the notion of distance.

command NewCommand V1 V2 ...
{
 // algorithm's steps
}

states that NewCommand is an algorithm that requires the concepts V1, etc. to execute the steps that are within the braces. Each concept is a variable that will be used by the algorithm’s steps.

After defining the algorithm, it can be used as a new DBN command, by simply writing NewCommand E1 E2 ... The value of each expression will be computed and assigned to the corresponding variable, and the algorithm will be executed. If more or less expressions are given than needed by the algorithm, an error message will be issued. For example, the same error will occur if we provide more or less than four expressions for the line command. Rewriting our program to abstract the execution steps into a named command should make clear how commands are defined and used in DBN.

// the tunnel
// version 3, 9 Nov 2008, Michel Wermelinger
// define a command for drawing centred squares

command centred_square left
// draw a centred square, given the left coordinate
{
   set bottom left
   set centre 50
   set distance (centre - left)
   set right (centre + distance)
   set top right

   line left bottom right bottom
   line right bottom right top
   line right top left top
   line left top left bottom
}

line 0 0 100 100 // left bottom corner to right top corner
line 0 100 100 0 // left top corner to right bottom corner

centred_square 20 // near square
centred_square 40 // far square

Note that the algorithm’s steps have been indented to show they are within a command. The DBN programming environment provides a button to automatically layout the whole program.

Note also how the program has become succinct while remaining clear. The algorithm’s steps have been written once and used twice. As a simple exercise, try to further reduce the length of the program by simplifying the computation of the right variable. (Hint: Substitute the variables in the expression by their values and thereby get rid of the assignments that compute centre and  distance.)

Splitting the program’s steps into several commands (also called procedures or sub-programs in other languages) is one way of breaking a long program into simpler to understand modules. In the next post we take modularisation one step further.

1. We choose the left coordinate of our square, e.g. left = 20.
2. We know that the left bottom vertex of a centred square is on the main diagonal and hence bottom = left.
3. By definition, the left and right sides are equally distant from the centre. We know that centre = 50 due to the dimensions of the canvas.
4. We next compute the distance from the left to the centre, which is distance = centre – left.
5. We add this distance to the left to obtain the right coordinate, i.e. we do right = centre + distance.
6. We know the top right vertex of the square is also on the main diagonal and therefore top = right.
7. We can now draw the square’s four sides with the following commands, in any order:
   • line left bottom right bottom
   • line right bottom right top
   • line right top left top
   • line left top left bottom

What we have just written down is an algorithm, a stepwise procedure to obtain our intended result. The most important thing is of course to put the steps in the right order, because each step can only use the information obtained in previous steps. For example, we can’t exchange the order of steps 4 and 5, because we need first the distance to then compute where the right side will be. However, even if the order of steps is arbitrary, putting them in a sensible order will make it easier to understand how the algorithm works. For example, although the four sides can be drawn in any order because we have all coordinates at hand, drawing the sides in clockwise or anti-clockwise order, i.e. each line starts where the previous ends, makes the steps easier to follow.

To translate the above algorithm into a DBN program, we need to know one more DBN command: set N E computes the value of expression E and assigns it to the name N so that whenever the name appears, the assigned value is used instead. Whenever a new value is assigned to the same name, the previously assigned value is lost. For example, executing first set left 20 and then set left 40 means that any subsequent use of the name left refers to the value 40, not 20. In programming jargon, left is a variable, a placeholder for a value, a box for storing a value. Whenever a new value is stored into a variable, the previously stored value is discarded.

In DBN, expressions that use mathematical operators like addition and subtraction have to be written within parentheses. For example, the computation in step 5 above is written in DBN as set right (centre + distance). We can now present the whole program, which obviously produces the same picture as in the previous post.

// the tunnel
// version 2, 9 Nov 2008, Michel Wermelinger
// line command uses computed coordinates

line 0 0 100 100 // left bottom corner to right top corner
line 0 100 100 0 // left top corner to right bottom corner

// near square
set left 20
set bottom left
set centre 50
set distance (centre - left)
set right (centre + distance)
set top right

line left bottom right bottom
line right bottom right top
line right top left top
line left top left bottom

// far square
set left 40
set bottom left
set centre 50
set distance (centre - left)
set right (centre + distance)
set top right

line left bottom right bottom
line right bottom right top
line right top left top
line left top left bottom

Although the program has become much longer, it is much clearer. It shows what is constant (the centre of the canvas), what we choose (the left coordinate, which changes from one square to the other), and what are the relationships between the various coordinates. The program reflects our reasoning, the algorithm we devised. This was achieved by abstracting the concrete values of line endpoints into general concepts like ‘left’ and ‘bottom’. We also used intermediate concepts like ‘centre’ and ‘distance’ to obtain our final results. All these concepts are captured by variables, which we have named after the concepts they represent. (As far as DBN is concerned, we could have named the variables with any string of letters, e.g. blop, but that would obfuscate the concepts to the program’s reader.)

Abstracting concrete values into general concepts about centred squares has enabled us to write down an algorithm that executes always the same steps after selecting the value for the left side. Wouldn’t it be nice to write those steps only once, instead of repeating them for each square we want, as we did in the program above? We will see how to do that in the next lesson.

line X1 Y2 X2 Y2

draws a straight line from endpoint [X1 Y1] to endpoint [X2 Y2]. For example, if X1 = X2 then the line is vertical, whereas if Y1 = Y2 then the line is horizontal.

Let us suppose we are within a square tunnel, facing straight into its unfathomable end. To provide a sense of perspective, we’d like to draw the joints where tunnel segments meet. Click on the canvas to see what I mean.

How do we translate this vision into line commands for DBN to draw it for us? There are  various ways to do it, depending on the line segments we choose in the picture, and finding the best way is not always trivial. In this case, the simplest way is to draw two diagonals across the canvas and then two squares.

The diagonals are drawn with two line commands. To explain what they do, I’ll add some comments, which are bits of text that help humans understand how a program works. Computers don’t need such help when executing programs and hence resolutely ignore comments. In the particular case of DBN, a comment starts with // and goes until the end of the line.

line 0 0 100 100 // left bottom corner to right top corner
line 0 100 100 0 // left top corner to right bottom corner

Note that in DBN, each command must be written on its own separate line of the program. For example, you can’t write

line 0 0
100 100

or

line 0 0 100 100 line 0 100 100 0

Both cases will lead to error messages. Having one command per text line makes it easy for humans to read the programs and for the DBN environment to execute them, sequentially from the first to the last line of code.

As for drawing a square, if we know the coordinates [left bottom] and [right top] of its two diagonally opposing vertices, then drawing the four sides of a square amounts to writing:

line left bottom right bottom // bottom side
line right bottom right top   // right side
line right top left top       // top side
line left top left bottom     // left side

The four sides can of course be drawn in any other order. All that remains is to find out the required coordinates. Since both vertices are on the main diagonal, we necessarily have left = bottom and right = top. On the other hand, since the square is centred on the canvas, the distance from the left side to the centre (coordinates [50 50]) must be the same as the distance from the centre to the right side. For example, if left = 20, then the distance is 30 and hence right = 50 + 30 = 80.

We are now ready to write the whole program, just by choosing the left side coordinates for the near and the far squares. I have chosen 20 and 40, respectively. (Note that both left sides have to be to the left of the centre and hence must have coordinates smaller than 50.)

// the tunnel
// version 1, 30 Oct 2008, Michel Wermelinger
// line command uses concrete coordinates

line 0 0 100 100 // left bottom corner to right top corner
line 0 100 100 0 // left top corner to right bottom corner
// near square
line 20 20 80 20 // left bottom to right bottom
line 80 20 80 80 // right bottom to right top
line 80 80 20 80 // right top to left top
line 20 80 20 20 // left top to left bottom
// far square
line 40 40 60 40 // bottom side
line 60 40 60 60 // right side
line 60 60 40 60 // top side
line 40 60 40 40 // right side

Although the program does its job of producing the intended picture, shown earlier, it’s somewhat unsatisfactory, because the reasoning process that led to its construction has been lost. Anyone reading the program (including ourselves after a while!) will not understand how the coordinates for the line commands were obtained. The comments help, of course, but the generic reasoning that enables to draw any centred square has been lost.

Possibly the most exciting thing about programming is that our reasoning can be conveyed to the computer, so that the computer can apply our ingenuity over and over again to different instances of the problem. In other words: we do the creative designing part, we teach it to the computer, and then we let it do the tedious repetitive stuff at high speed – that’s what computers are good for.

In the next post we will see how to precisely and succinctly convey our reasoning steps to the DBN system, in order to turn our concrete two squares into the abstraction of a square centred on the canvas.

The DBN environment has three panes: you write the program on the right pane, press the play button on the top pane, watch the output on the left pane, and press the stop button on the top pane to stop the execution. That’s all!

When the play button is pressed, the DBN environment checks if the program we wrote has some spelling, syntactic or grammar error. If so, the line in the program with the error is highlighted and an error message appears over the right pane. Unfortunately, the message is not always clear about what the error is, and the message only appears if the mouse cursor was left over the play button after pressing it. A slight nuisance…

This tutorial will show side by side the programs and their resulting output. As said in the previous post, just click on the empty square next to the program’s code to start running it. Feel free to copy and paste the programs into the DBN environment to further tinker with them and produce your own variations. The downloadable DBN environment has buttons to open and save DBN programs, but if you’re using the applet on the DBN website, to save your changes just select and copy the program as you would do with any other text in your particular browser, and paste it into some text editor, where you can save it to a file.

Without any further ado, here’s again the program shown in the previous post, now with its code.

// attached
// version 1, 9 Nov 2008, Michel Wermelinger
// cursor is attached to origin

forever
{
   set x <mouse 1>
   set y <mouse 2>
   paper x
   pen (100-x)
   line 0 0 x y
}

The program will only make sense after a few of these tutorial lessons, but for the moment let’s use it to try out the environment. Paste the above code into the right edit pane of the environment, run the code to make sure everything’s fine, and then stop execution. Then change the two zeros to two y’s, so that it reads

line y y x y

Run the program again. You should obtain the following (click within the square):

The program’s title hasn’t been changed. This begs the question: what is the mouse cursor now attached to? It may not be immediately apparent, but part of the appeal of interactive computational art is exactly the trial and error exploration to formulate a hypothesis about the program’s logic. After a while, it should dawn on everyone that the cursor is ‘attached’ to the diagonal that goes from the bottom left corner to the top right corner.

In the next lesson we’ll look more closely at the line command that appears in the program above.

Here’s a simple example of what can be done with a handful of lines of DBN code. Click within the white square to start running the program, and then move the mouse around. To be able to scroll further down the page, click again outside the square.

DBN was initially developed by John Maeda and then further improved by his team of the Aesthetics + Computation group at MIT, in particular by PhD student Ben Fry, who then went on to create Processing.

DBN is described in Maeda’s book Design by Numbers, which is a 260 page long, very gentle introduction to computation for absolute beginners. It contains hundreds of examples of what one can do with DBN and it explains Maeda’s rationale for creating DBN and some of his ideas about design. There is a short introduction to the language available on the DBN website, but it omits all the interactive features and doesn’t contain any real examples. Furthermore, the language has evolved since the book was published. New constructs were added and existing ones behave differently: for example, variables have now to be explicitly initialized and command names can be used as identifiers.

This tutorial therefore aims to be the first complete and up-to-date, yet brief, introduction to DBN. In the next post we’ll have a look at the DBN programming environment.