I have been coding for a bit of time, I still have a certificate proving that I learnt how to code on a TRS-80 from 41 years ago, although I must admit I don’t remember much besides the fact it was BASIC. For good or bad, most of the coding I did in that time-frame is lost.

As I’m trying my hand on Swift, I’m basically rewriting code I wrote a quarter of a century ago, and of course one of my references is my old code, which mostly worked. So I had read the code I wrote fresh out of University, in a language I did not really master (Java), which was quite new. For that Java project, I used Metrowerks CodeWarrior, which was a really cool tool at that time.

First thing I must say is that it is not as bad as I would have expected: there is not much documentation, but the naming is reasonable and largely follows the Apple terminology. Second observation, it’s an early version of Java, which brings quite some baggage:

• Each class is a different file, so the logic is scattered between many files.
• Enumerations were not supported, so you get a lot of static integer constants.
• Free functions are not allowed, so there are empty classes whose job is just to contain them.
• A picture is basically a collection of OpCodes, but Java can only handle collections of Object, so there is quite a bit of casting logic, as well as helper function to see if a OpCode implements a given interface. There is a bit of very primitive reflection, instantiating instances from a class object, but early Java was extremely limited in that regard.
• The code relies directly on AWT for graphical operations. That library was pretty limited.

The most painful code to read was the one decoding bitmaps. The problem is that there are multiple code-paths that share some logic. In the Pascal and Assembly world of the original Macintosh, these were clearly records and supporting procedures, but this is Java, so I tried to solve the problem using multiple objects and inheritance. Object oriented was the thing.

This was not a good idea: as the control flow jumps up and down in the object hierarchy and makes the code very difficult to understand, and not more reuse as it were a set of functions. Another problem is that the code tries hard to be more abstract than needed, so there are quite a few constants for magic values (like length of certain data-types, areas to skip), these were typically only used once, and moving them away from the calling side hindered readability.

Still, these are pretty minor things, so what is the big difference with the way I work these days? Basically, testing. Besides the code, I also had the various files I used for testing out the code, it is a random collection with no actual structure. While I generated files for each bitmap depth, there was no systematic approach in files, which is a shame, because generating QuickDraw files was much easier then than now.

Unit-tests were not a thing back then, and a good chunk of my software engineering courses were about formalising requirements, specifications, very top-down design. Who remembers things like Merise? I had the QuickDraw specification, this was the most important, right?

My attitude towards stacks and abstractions was very different, I had grown up coding on the Commodore 64, where you just peeked and poked into memory, and each subsequent generation of computer meant using higher level APIs. University courses put quite some emphasis on the importance of layering, basically once an API was there, written by people more competent than you, you used it.

This meant that I struggled to get the very rough Java AWT API to do what I wanted, instead of just implementing my own frame-buffer and pushing this out. Given the fact you could not export any vector data from a Java applet, this would have made no functional difference, would have enabled some functionalities like patterns, it probably would have been more fun. Ironically, AWT had exactly the same problem, it tried to rely on the underlying OS, and was super-seeded by Swing which did its own rendering.

I believed Applets were the future, so clearly, Sun fun would refine the API and add support for image export and printing, the API improved a bit, but was never rich enough to all any meaningful conversion, my applet was forever a viewer. These days, I believe in what is implemented here and now and I’m very wary of abstractions, in particular bad ones.

Interestingly, it seems my approach to coding change more than my actual coding…