Your leaking thatched hut during the restoration of a pre-Enlightenment state.


Hello, my name is Judas Gutenberg and this is my blaag (pronounced as you would the vomit noise "hyroop-bleuach").


decay & ruin
Biosphere II
dead malls
Irving housing

got that wrong

appropriate tech
Arduino μcontrollers
Backwoods Home
Fractal antenna

fun social media stuff

(nobody does!)

Like my brownhouse:
   trouble with a non-linear programming environment
Sunday, July 10 2011

Today Gretchen headed off to Phœnicia, the cute-but-somewhat-seedy village on the upper Esopus about 26 miles northwestward into the Catskills. Her mission was to housesit at the residence of a friend for a few days and hopefully take the opportunity to write some poetry. Because of her ghostwriter duties this summer, she hadn't signed up for any writers' residencies, so this would have to do.
With Gretchen gone, I had my own little pseudoresidency, but of course the difference was that every few hours I'd have to give Marie (aka "the Baby") her wet food, and every morning I'd have to walk Eleanor. But the most immediate goal of my pseudoresidency was to get my brain around iPhone/iPad development using Xcode4, a development environment that is only a few months old.
I had a particular app I wanted to build by tomorrow, but the complexity of the development environment (that is, Xcode4) kept thwarting me.
I should say at this point that I prefer the simplicity of a linear development environment, one where the whole of a project can either be developed (or at least visualized) as a single document of code. Most of my web applications are that way, though it's true that some blocks of coded information end up in places that diverge from the linear model (.js files, data in databases, the schema for the database, and also .css files). I think one of the reasons I love Arduino so much is that every application is a single file of code (although, in complex deployments such as my master-slave solar controller, non-linearities can emerge). I've had more trouble with non-linear programming enviroments such as Flash, where blocks of code are tacked onto multiple timelines and it's difficult to track down what exactly is causing a problem when a problem inevitably surfaces. No single search works, and indeed (when some of the programming is done via GUI) the thing you'd be searching for had been created interactively by mouse movements and would be impossible to describe.
This problem, in a nutshell, is one I soon encountered in Xcode4. Apple's Xcode IDEs have always encouraged a proliferation of files, to the point even where class headers are kept separate from implementations. This runs counter to my programming inclinations. I prefer to have everything in the ongoing job to be in one file so that I can quickly run a search to find any particular place in the code I'm looking for. A single file paradigm also makes "undo" into a straightforward operation (too often in Xcode, I find myself hitting "undo" on the wrong file). A single file might not work for enormous projects, but when little projects turn big, files can easily be broken up, usually into more useful segments than the regime of headers and implementations.
A further problem with Xcode is that it, like Flash, depends on a GUI (Interface Builder) for linking together programming units. But in order to use that GUI, you have to have a firm understanding of its values and limitations. And you also have to give up a lot of flexibility. Back when I'd made my first iPhone app, I'd done it without Interface Builder, choosing instead to assemble the user interface programmatically. Xcode supports doing things this way, but nearly all the examples one finds online are from people doing things in Interface Builder. So on today's project, that was what I used. But at some point I made the mistake of editing a .xib file (the XML file that Interface Builder generates) manually. I'd needed to do something and hadn't figured out how to do it interactively, so I'd thought I could just shortcut the process. This ended up being a huge mistake. Suddenly UIWebView blocks could not be resized, and none of the configuration settings in Interface Builder, confusing though they are, were having any effect. The whole mess was analogous to what happens on a Windows XP operating system installation compromised by a virus or data corruption: sure, in theory it would be possible to go in there and tweak the parts that are failing to restore system health with an economy of time and effort. But the problem is that in a non-linear computational environment, most of the work involved in fixing a bug lies in searching for the place where the bug is happening. Since that task is so daunting, usually what gets recommended is to either "reboot" (reload the operating system into memory) or "reinstall" (reload the operating system onto the hard drive from canonical installation CDs). One hears such recommendations even when the problem is as small as a single inverted boolean value buried somewhere in the registry. In the case of my failing iPad app, clearly I needed to build the whole thing again from scratch, salvaging whatever blocks of code from my failing implementation. But even before I realized this, it was after midnight, I'd been working at this for many hours, and I needed a break. So I went to bed. It's rare for me to allow myself to scurry off to bed as a failure at whatever I'd been trying to achieve, but for some reason tonight I allowed myself to do so. Still, I was impressed with the motivation I'd somehow mustered allowing me to work at this project for so many hours undistracted.

For linking purposes this article's URL is:

previous | next