DOTFOR

Modern programming languages have come a long way from the origins of computing. Today’s programmer can benefit from conceptual and technological advances such as monadic computation and parametric polymorphism. These changes in computation directly allow a different type of software development. With the thoughts of the programmer less concentrated on the substrate and more focused on the problem at hand, it is possible to build bigger, more complicated systems faster and cheaper. We’re doing today with software what was previously only imagined in science fiction.

Beyond just code itself however, the infrastructure underlying our programs have changed dramatically as well. Even as recently as the late 1980s programs were written not on a laptop and saved to the cloud, but instead typed on a card punch to be encoded as specially sequenced holes in firm paper card stock. The significance of this type of change is multifaceted, and goes much deeper than the physical mechanism of storing data. Keeping programs on card stock also required significantly more effort on behalf of the programmer. For example, punch cards are a destructive medium, unlike today where typos are fixed with a backspace key, an error on a punch card may well mean having to throw out that piece of code and start from scratch. Running code involved taking your stack of punch cards from wherever you happened to type them down the hall or perhaps to a different building to where the room-sized mainframe lived where it could be executed. These mainframes, being too big and expensive for personal ownership, were often shared resources among large departments. Moreover they would require special operation that would be performed by designated operators, not the author of the code. Even the cards themselves were subject to types of failures we cannot experience today, if you were unfortunate enough to drop your stack of cards on the way to the mainframe, you’d have to spend the whole day trying to recall the correct sequence of the whole program.

It’s clear why computing has moved in the direction it has. Less hassle, fewer extraneous problems, fewer concerns beyond the logic itself. But from a purely aesthetic perspective, maybe we’ve left something behind. Programs used to be a thing that you could touch, flip through, and yes, even drop into an amorphous mess on the floor. These days code is at most a few bits recorded magnetically on a disk somewhere on the internet. Perhaps there’s value in the tactile and physical interaction programmers once had with their programs. Perhaps the more methodical and linear processes of developing algorithms was more focused, meditative, and cathartic then our current norm of frantically banging away at keyboards.

But even if you wanted a return to a simpler time and a simpler way of coding, the infrastructure to do so doesn’t exist anymore. There are no more mainframes, you can’t get your hands on a card punch, and nobody manufactures card stock anymore. The solution to this problem of generations, however, comes from the same era as those mainframes themselves. There is one product that serves as destructive card stock capable of encoding and conveying programs to be executed: Sour Mega Candy Buttons!

For those who did not grow up with candy buttons, the above image may be slightly confusing, but for those who did the very sight of candy dots immediately brings back the excitement and joy of childhood. Candy buttons (or dots as they’re sometimes affectionately referred to as) are little brightly colored dots of hardened sugar deposited in a regular grid along a paper card to be bitten off and eaten by children.

Now, I know what you’re thinking: What does something so delicious and fun have to do with the computing of yore? Well, few things have the power to evoke the simplicity and basic enjoyment of days gone by as do candy buttons and computer punch cards. These two paper-based products both come from a by-gone era when we had the pleasure of interact with our world physically instead of digitally.

Now, I know what else you’re thinking: How can something so delicious and fun also be used to crunch numbers? Well, just like punch cards, of course.

Punch cards represent programs one line at a time, with each column representing a character. A single card will often have around 80 columns/characters, predating the teletype width of 80 as well as current style guides with the same value. Characters were represented by the combination of holes punched into each column, in a similar manner to the way binary values represent numbers in modern binary byte-based storage.

Today, programming has largely settled on a standard representation of characters using either the ASCII representation, or one of its supersets in unicode. However, including 128 characters, ASCII requires a minimum of 7 bits which was not always available on punch cards. Before the widespread adoption of ASCII several smaller, 6-bit, types of encodings were in wide-spread use, including the BCD (Binary Coded Decimal) family of character encodings.

While going from a 7-bit to a 6-bit encoding of characters may seem insignificant in terms of the single fewer bit required, it turns out that there are several scenarios where only 6 bits are available and while using ASCII isn’t viable BCD is. One such example is the Sour Mega Candy Buttons card.

Sour Mega Candy Buttons have their brightly-colored, delicious dots arranged in a 6x12 grid which, given the right encoding, can represent 12 6-bit bytes. Unlike punch cards, however, which “flip” bits by removing a square of a card itself, Sour Mega Candy Buttons can have data recorded through the eating of the buttons laid on top of the card. Candy buttons that remain on the card represent 1s, and candy buttons that have since become a yummy snack represent 0s. And in this way, we can eat our way to fully executable programs.

Using the GE/Honeywell dialect of the BCD code, GBCD, I’ve created a Sour Mega Candy Button programming simulator. This simulator lets you plan and digitally construct candy dot programs in the predominant programming language for punched-card programs: Fortran. I call this language DOTFOR, and the tool with which you edit it, the edotor. It’s available below for your candy programming pleasure.

---