Close to a decade ago, I gave up programming. I figured that I could do no more – certainly not without becoming more mathematically literate. I was also sick of the hours of staring at the screen. I wanted to go outside. I wanted to walk up hills. I wanted to explore other (lived) processes.
However, I’ve recently returned to programming. I’ve returned to finish some projects – or to push them a bit further. I’m focusing particularly on developing the Loom subdivision engine.
I’ve been surprised how easily I’ve found it to get back into programming – not only the arcane syntax of Java and Scala, but also the whole mind-set needed to make sense of complex data structures and algorithms. It all seems so familiar, as though I have scarcely been away – like an alcoholic that only has to taste liquor for the addiction to return in full.
I’d like to say more about this eventually, but just here I want to mention a bug that I solved this morning. I had been wrestling with it most of the weekend, running endless println statements to try to trace where the values were going astray (the experience of debugging is also very familiar to me). Anyway, I finally found the problem. I had an overall manager class that managed a whole complex Bezier drawing system. I’d assumed that I’d need to create an instance of this class when I was loading existing drawings from XML files, but it turned out that the class was already instanced at a higher level in the program. I was then referring to two instances of an overall manager, which each represented aspects of the loaded drawings. They were strange coextensive doubles that had unclear implications in the same drawing space. They were intersecting alternate worlds, each withdrawing (providing null data or wrong indexes) just when they were needed.
I only had to change one line and it was all gone. The whole program worked. The hardest thing to do is to examine an intractable problem with open mind, to not make assumptions that lead me astray.
Bezier drawing app for Loom