Build Cycle
Volume Number: 10
Issue Number: 9
Column Tag: Inside Info
Without The Build Cycle 
Dynamic languages like Dylan™ turn the clock back twenty years
By Chris Espinosa, Apple Computer, MacTech Magazine Regular
Contributor
When we first started shipping applications from Apple in 1977, some
programmers worked with assemblers, and small bits of work were hand-coded in
machine language using the built-in mini-assembler in the Apple II, but most of the
software products we shipped in 1977 were written in BASIC.
Though I wrote some code, most of what I did was documentation of other peoples’
programs. For me there was a certain joy to working with a program written in
BASIC. First, I could read the code. Everything shipped in source-code form, and if a
program had a bug, I could list the offending lines, fix the value of a variable
interactively, and run from a given line number. When I called the programmer to
discuss the bug, I could help isolate it to a specific line, make the change myself, and
save the fix permanently in my copy.
Programmers had similar power, to stop an application, interactively examine
the values of variables, and resume. When I went to college and learned FORTRAN and
Pascal, I wondered why we were being forced to take a step backwards! All my
programs could do is execute or abort. I couldn’t examine variables or program state
from the shell. I couldn’t list the program as it was in memory; I had to go to a
separate source code file, which the compiler may or may not have been interpreting
in the way I expected it.
Because I wasn’t writing anything that demanded great speed, I didn’t appreciate
the value of using a compiled language versus an interpreted one. All I saw was the
distance that the compiler put between me and my code.
The whole build cycle I saw as a mixed blessing. Yes, it introduced more delays
and complexities into the process. But with build files and version control, people
could manage much larger projects than could be put together with modules of BASIC
programs. One of the last large programs I worked on was the interactive demo for the
Apple ///, which was composed of a number of Business BASIC programs chained
together. They had to be split up to be manageable, but doing so created a configuration
nightmare.
Today static compilation is the reality that most programmers live in. Build
systems have their own complexities and problems, of course, and the debate between
project-based systems like Code Warrior and Symantec and script-based systems like
MPW and UNIX will probably not end soon. But both systems have built up collections
of auxiliary tools, common practices, and years of lore to build large projects with
them.
In many ways the shape of a software engineering organization and product
schedule is determined by the build cycle. The edit/compile/debug rhythm of the
individual programmer is echoed in the develop/integrate/test cycle of the project,
which itself drives the alpha/beta/final cycle (and in many ways runs the progress of
successive generations of upgrades). The belief that product evolution is divided into
distinct phases grows naturally out of a software development technique that is divided
into similar phases: plan, implement, process, evaluate.
Given this, what happens if the build cycle is eliminated? Dynamic languages
like Dylan™ turn the clock back twenty years, back to the interactive character of
BASIC programming, but with the efficiency of compiled code. With a dynamic
language, the programmer is able to examine live variables, execute code to evaluate
expressions, or even change source code while it’s running. In a completely dynamic
development environment, it’s conceivable that once a programmer gets the
superstructure of the application running, it wouldn’t be necessary to quit it to
develop more code. The development environment and the application would run side
by side as separate processes, and the development environment could add new objects
and methods to the application as it runs.
In this kind of environment there would be essentially no build cycle. You’d test
and integrate each piece of functionality as you wrote it, method by method. Planning,
implementation, and evaluation play tag with each other; you can hop from one to
another at whim. Bugs wouldn’t pile up through the testing cycle, waiting for the next
major build; they’d be caught and fixed then and there (and the side effects of their
fixes would be noticed sooner).
What happens to the release cycle when the need for a big integration build is
reduced? What happens to the separation of engineering and testing teams when testing
can conceivably work on the live code as it’s written? How do programmers step back
and get perspective on a program, when the environment gives them instant
gratification for incremental evolution?
We can look at the ungainliness of HyperCard stacks, and the proliferation of
“drop-in” architectures (like Photoshop plug-ins and Mac control panels) to get some
warnings about what might happen in a more dynamic world. When programmers have
more freedom and faster turnaround, they don’t necessarily use it to make things
simpler or clearer. To the end user, the dynamic programming revolution could be
seen as a maze of organic, ever-changing entities, assembled without planning or
foresight. (Kind of like the Internet).
To be most useful, dynamic programming environments will have to be
approached very carefully. Rapid turnaround has the power to make programming
more fluid and free-form, and eliminate the artificial discipline of the build cycle. We
may have to learn new disciplines, however, to make sure that the programs resulting
from dynamic development are clear, simple, and straightforward to end users.