I have been programming for a pretty good fraction of my life. In that time, I’ve thought about what my goals were in many different ways. This post is an attempt to get some of these thoughts to stand still for a while.
In the beginning
I started programming before the internet was widely available. Some of the first memories I have of programming is learning LOGO on green-screened Comodore 64s at school (this would have been around grade 1, when I was 7 in 1985) and copying BASIC code from magazines on our XT computer (perhaps a little later, around 1988). The most difficult programs were the ones that contained pages of hex codes for pre-assembled parts of program.
 |
| Hex codes for a program on a magazine page |
At this point, I didn’t have much of a grasp on the techniques involved, but this was a cool way to get the computer in our garage (my mother wouldn’t allow it in the house) to do things. In many ways this was the predecessor of today’s copypasta programming culture: many people who don’t really know what the codes do copying from the sages to get something useful. I was intrigued and started digging into my dad’s copies of the BASIC manual that came with the computer, slowly teaching myself how this stuff worked. I must give a lot of credit to my dad here, as he was always keen to point out how I should be using functions or other programming structures. He had experience with programming as a systems analyst.
I did computer science in school. We learned Turbo Pascal. I was initially not very fond of this, as I preferred the Borland C++ environment. In Std 9 I helped to organise the movie-themed matric farewell and wrote a database program (in C++) which allowed us to print tickets at the gate, as though you were going to a movie. This was using the text-mode library I had developed which looked a little bit like curses (although I didn’t know it at the time).
 |
| Text-based interface similar to the one I wrote |
As a final matric project I developed a program which would help you set and solve crossword puzzles. Initially I had wanted to make it automatic, but I couldn’t sort out the algorithm, and I had my hands full as it was developing my own graphics library which handled graphical input on a grid and also had a whole font system and mouse access working via hand-tuned assembly routines in Mode 13h. Because we used Turbo Pascal for school, I used that. Turbo Pascal allowed for very easy inclusion of assembly in functions, and I used it perhaps more liberally than I should have. I was quite proud of this program, but I will admit that it was terribly written.
By the time I was finishing school I was programming for fun and profit. I wrote a Windows program to look up vendor information based on postcodes for call-center operators which I ended up selling to an insurance company. I had migrated from Visual Basic to Delphi when I started learning Pascal in school and had also learned about SQL databases and through contact with these industry programmers.
Up until this point, most of the programs I had written were basically user interfaces. The problems the programs solved weren’t particularly complex algorithmically, but the trick was figuring out how to allow interaction and how to make certain effects happen on the screen.
Hand-coding assembly is a waste
I had a couple of friends who were into the same things, including running a BBS together. Through the BBS, we got into the demoscene and I was driven to figure out the techniques they were using to get the computer to do these amazing things. We would try to outdo one another with optimising our graphics routines. For instance, we would calculate frame rates at line drawing. The kinds of problems I was solving here were more satisfying to me on the algorithmic level. It felt really good to go from a naive line implementation to the Bresenham’s line algorithm and see the huge difference an algorithm could make to rendering speeds.
I hand-optimised my assembly code and dug into the technical reference manuals while one of my friends wrote more portable C code. When the Pentium chips came out my hand-optimised code was now outperformed by his due to the power of a good compiler. This was a breakthrough moment for me – I realised that this time I had spent had not been a good investment. It had won in the short term, but in the long term higher level languages would win over lower level ones.
So, when I got to university and learned Matlab I was intrigued by how much I could do with this small amount of code. Around this time I also started to get into Linux (another thing I had been introduced to on the BBS) and there weren’t really many cross-platform GUI libraries at the time, so I ended up focusing on what I liked best: algorithmic developments which would lead to faster solutions. Looking back now, I guess that Matlab was also the first time that I came across a well-documented and extensive set of libraries and the idea that the best way to solve a problem was to find a library routine which could get you close rather than implementing a new algorithm from scratch.
I used Matlab and Quattro Pro for most of my programming jobs throughout my undergraduate career, but I also learning to program my HP48GX calculator. This was an interesting mind-expanding moment as it introduced me to the concept of stack-oriented languages and would make it easier to understand Postscript later.
Good programming practice and the move back to text
I graduated in 2000 and enrolled for my masters.
As part of the coursework in my masters course, I also learned a lot about image processing and image recognition and processing in my course on pattern recognition, where we had to write a program to identify number plates.
 |
| Output from my number plate recognition progra |
For my actual Masters project, I inherited a Matlab/Simulink program which was written in typical crufty engineering style. It made extensive use of global variables, so many that there was a spreadsheet to keep track of the places the globals were used! It also made very little use of any higher-order programming techniques. In order to understand what was going on in there, I ended up writing a parser in Matlab to generate a call graph of the program and refactored the program mercilessly until it was manageable.
 |
| The call graph from my Masters program |
This gave me very valuable experience in maintaining large programs and I started programming much more defensively to save someone working after me (or myself in the future) the trouble that I had to go through to get going on this program.
With these kinds of engineering problem, you end up thinking a lot about the algorithm and the solution method, and often the solution is a single number, so you don’t really think about the program in terms of an interface. You write lots of code to read inputs from files or other computer systems, your program becomes unresponsive, or shows a progress bar for a couple of minutes and then spits out the answer in the form of that number, or perhaps formatted in a nice plot. I ended up having to run my program on many different computers to generate the data I was looking for and all this conspired to make my programs very non-interactive. My master’s code did actually have a GUI, but it was developed by my predecessor and was so difficult to maintain that I just ended up using it as-is.
I learned LaTeX for typesetting my dissertation, which was also an exercise in non-interactive programming. I migrated away from Windows, partly because I was convinced that Open-Source software was poised to take over the world and partly because Matlab ran faster in Linux than on Windows at the time. This move was another nudge away from GUIs as the support for the kind of click-and-drag programming that I was doing in VB and Delphi is not very deep in Linux. I also discovered the great power of the Unix command line, where a couple of basic programs strung together could solve problems I would have required lots of code for in Matlab.
I ended up with a deep understanding of writing programs which look like data pipelines, with raw data entering one end, being processed by a number of programs and then ending up with postprocessing on the other end. However, I fell behind in the interface department. Since you could get the results you were looking for without providing user interaction, that seemed like an annoying and unnecessary side step.
But text is ugly
To produce good-looking output I learned about a number of different technologies that could be accessed in this data-flow fashion. I learned how to generate static PDF graphics from Matlab so that I could include it in my dissertation. I generated HTML output from many of my programs so that I could easily show tabular data. I still use these techniques to generate nicely formatted tables for beer scores.
This brings us up to the end of my Masters in 2002. At the end of that year I started teaching, which opened up a whole new avenue of programming for me, but I think I will make that the topic of the next post, as this one is already quite long. Stay tuned for part 2.
Leave a Reply