Automata, ConTeXt and Ruby

A substantial of my thesis wil be (actually, already is) a display of the results of the approximations methods I analyzed on a sensible set of test cases. The display will have to come in two forms, tables and graphs.

I had to tackle the problem of setting up the correct the layout and inserting all the data automatically sooner than I had expected, for two reasons.

The first, and most obvious, one was that without an extensive test suite it would have not be possible to verify the theory and check the code for bugs. However, proper layout of the data was enforced by tight scheduling of an article containing the core point of the thesis.

The scientific world has been dominated for a long time by TeX, a typesetting system that works pretty much like a compiler. TeX itself is almost never used raw, but with appropriate formats built upon it, the most common of which is LaTeX. A less common one, but still the one I now use for most of my stuff, is ConTeXt, aimed more at liberal arts content but still flexible enough to be used for scientific purposes.

Although the use of LaTeX and other TeX systems has been progressively losing ground to the more common word processing software provided by office suites, the article I needed to write, and my PhD thesis, showed brilliantly how a command processor like TeX is the tool best suited for these kind of things.

Indeed, when data changed with the new test runs (because errors were fixed, curves were added, or more data was presented) it would have been a pain to update all the tables in a common word processor with the new information: hand-editing over 50 tables would have been an extremely boring and error-prone process. Instead, since the input to TeX is plain text files, inserting the tables and figures, and moving them to the appropriate place, became a process that could be automated by a script.
Similarly, the companion MetaPost tool enormously eased the process of updating the pictures as needed, by automation.

Enter Ruby, my next best friend. Ruby is a scripting language built from the ground up with object-oriented design in mind; yet, it follows the principle of least surprise: whenever it makes sense, the object oriented approach can also be accessed wrapped in a syntax that is very familiar to those who have experience in imperative programming. This means, among other things, that coders experienced in other programming or scripting languages, like Perl or Python, will find themselves at ease in their initial approach to Ruby.

However, its the very dynamic, fully thought-trough object oriented model that gives Ruby its power and flexibility. For examples, the ability to extend built-in objects and standard methods without jumping through hoops like subclassing has allowed me to straightforwardly design new ways to output floating-point values as needed to give proper input to TeX and MetaPost for the creationg and layout of tables figures.

It's things like this that show the power of the GUI-less Unix approach —dedicated, automatable tools, each suited for a specific task and with the ability to exchange data with other tools via simple textual input and output— for large-scale projects.

Some things may be more comfortable to tackle by clicking around, but it's automation that computers were built for. Let's have them work for us, whenever possible.