Visualizing a Hybrid Application

Details vs Abstraction

In the C programming world, one can be lulled into thinking that there are just two levels of permanence in a program. The code and certain data are ``concrete,'' never changing (at least not without a recompile). Input data and run-time data are ``fluid,'' changing each time the program is run. But the truth is that there is a spectrum of permanence in any project. In the middle ground lies details that are neither here nor there.

In a financial program, the GUI code might be considered concrete while the daily economic data is fluid. But what about the tax code? Tax codes seldom change, but they aren't constants.

In a news aggregator application, which grabs news information from web-based information providers, the networking code might be concrete, while the daily news downloads and the hostname list are fluid. But what about the formats and protocols for downloading news? These are based on standards that are occassionally revised.

It can be good programming practice for the level of permanence of algorithms and information be related to the level of permanence in which they are encoded. Guile can provide a solution in this regard, because Guile sections of programs are more hackable, and can be more easily modified after the program is installed out in the field than a monolithic compiled executable.

Adaptability

With C programming, it is often the case that the data structures and interfaces get designed first, and then the code is filled in later. While this a direct method of tackling a simple problem, it makes it cost-intensive to modify the data structures and interfaces if they change.

Data structures and interfaces should not set in stone too early. As an example, imagine a system in which time values have heretofore been given in an seconds since some start date. An unsigned long would be a nice, compact way of storing the data. But, if later during development, it becomes important to have time accurate to fractions of seconds, every interface, every function call, and every printf that acts on time data will have to be changed to double or some other data structure. This is an example of how setting a structure too early can make rework difficult.

Guile can help in this regard. First, since Guile is a weakly typed language, much of its input/output and math routines are less sensitive to the structure of the input passed to them. It will happily convert between integer and real numbers as is appropriate. Second, the Guile aggregate data types, like a list, can be of varying length and varying type. Functions passed list data can be written so as to be indifferent to the exact structure of the list being passed to it, allowing the programmer to leave final decision on data structures to later in the development cycle.

Low-level, High-level

Code can be easier to debug when it is coded in levels of abstraction. At the top level, programs should read almost like an outline, clear enough that even a non-programmer, like your boss, can have some clue as to its purpose. Programs should avoid mixing low-level grunge code, like hardware I/O or memory allocation, and high-level function calls in the same function. It makes the program hard to debug.

While this is a general statement about programming, and doesn't require a scripting language to put into practice, a scripting language can be helpful in this regard. C could be used to create blocks of functionality, and Guile could be used as the high-level ordering and control of these blocks.

This is the route taken in the AI scripts for games. At the C or C++ level, the programmers have created an API of actions that a game character could do or information that a game AI could know, and then the AI scripting determines how to put these pieces together into a character's behaviour. In chapter ?, I describe how to create new Guile functions from C, which would be an essential step.