Incremental systems and programming
Purpose
This essay puprorts to extoll the virtues of interactive development environments in contrast to non-interactive environments.
Terminology
- Interactive development
- An interactive development environment is an environment where one can interact with the programming language. A classic example is a basic interpreter, where you type statements (either program line definitions or simple statements) and get immediate feedback. In my case, I primarily interact with Common Lisp environments and most (though not necessarily all) things are compiled, to one degree or another. An interactive environment makes incremental development much easier.
- Incremental development
- Incremental development is where your program grows stage by stage, possibly with stubs for some intermediate functions. This is much easier to accomplish in an interactive environment.
- Non-interactive development
- What most people think of when they hear "programming". You have an editor, where you change your source code. Once in a while, you start a compiler, check for any and all error messages and when things compile, you can test-run your binary. If you're lucky, you have a debugger available. Maybe even a debuggger that can interact with your editor, so you can get a tighter coupling between what you see in your editor and the program code.
Advantages of interactive development
In an interactive environment, you can test things piece-meal. You (usually) have access to global program state and can interrogate this. It's usually easy to whip up small helper functions to make (some) routine test s easier to make and you can exploratively extend your program in the direction it should grow.
This approach is quite useful when you're getting to grips with new technology.
Case Study - X11
I had great success getting to grips with X11 programming using Common Lisp and CLX (the CL library for the X11 protocol), since this meant I could interactively create windows, try different drawing operations and get to grips with how X11 programming worked in practice. I'd looked at it before, using C (and Xlib) as my exploratory "vehicle", but the edit-compile-run cycle was long enough that it was harder to get to grips with how things should be done in the most efficient way. It was also harder to see what functoins returned and the whole experience didn't encourage exploring as much as it encouraged reading maual pages and try to figure out the ground rules of this unfailiar territory.
Once I started off writing actual X11 applications, it was also quite helpful to be able to change widget locations, colour schemes and the like in running code, without having to lose internal program state. As I was interacting directly with CLX, rather than using a window programming toolkit (like Motif/Lesstif), this meant that I could comfortably ignore the lack of UI editors, since changing widget layout was easy.
Case Study - Linux joystick interface
As part of my game development interest, I decided that having an API for joystick devices would be nice to have. Time for some more exploratory programming and documentation reading. The low-level interface is a sequence of 8-bit and 16-bit values, read from a device file (one file per joystick). I have, at the moment, ignored calibration, as teh boot-time calibration support is sufficient for my needs.
Initial development quickly had me at a point where I could successfully read and interpret the joystick byte-stream. However, at this point, I was pondering a better interface for joystick positional data. The low-level values are all 16-bit signed integers, but to me it makes sense to have a floating-point representation, as this allowed me some extra functionality in converting from the (essentially linear) low-level representation to game-exposed information.
I also made it possible to use the library in two subtly different modes, either threaded (at least under SBCL, if threading is enabled) or synchronous. The main difference is that the non-threaded version checks the status as and when you ask for it, whereas the threaded version monitors the joystick data continously and only converts from internal to program-usable information when you ask for it.
Total time elapsed from "this might be handy" to a working implementation was on the order of a few hours (I didn't time it, but I started the work late one night, hacked around for maybe an hour and finished it off between ca 06:30 and 07:30 the following morning).
Case Study - OpenGL
I have recently started playing around with OpenGL, since it's a better way to generate 3D traffic than writing my own 3D primitives (as seen in Panzer). This started with me reading through several OpenGL tutorials and then I started playing. The important part is that once I had enough code to open an OpenGL window, I could then interactively play around with generating GL scene data and simply play around with it, without a time-consuming edit-compile-run cycle (I could also keep the data used to generate the scene in the running dev environment, meaning I didn't have to implement a way of loading and saving scene data; in some cases this would, however, be necessary).
Non-interactive development
I have, in the past, written a fair bit of code in C. The general development cycle is "write code", "compile code" (iterate these two until you get a clean compile), "run code, observe test cases" and "interact with a running image through a debugger", with possible returns to the "write code" stage.
While quite survivable, this model has a longer time elapsed from "write code" to "test/debug code", making the barrier for "small changes" higher and not encouraging testing different ways of handling internal data, because the cost of changing things is much higher. In short, it encourages making larger changes every time you change things and makes it harder to play around with different algorithms or data patterns, because doing so entails losing program state and a round-trip thropugh the compilation cycle.
I am aware that some dev environments now have artial compilation available, lessening this round-trip time.
This is one of Ingvar's essays