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.