Repos, Riffs & the Rockstar Programming Language

There’s this long fascinating discussion about what developers actually do. Is coding an art? Is it a science? Is it engineering? Is it just glorified typing?

Code can actually be all of those things; it depends on the code. 

There are a lot of reasons to write code. You can write functions that do things like calculating taxes and push them to a production environment. You can write code just to see what it does and throw it away as soon as it answered a question. 

You can also write code just because you want it to exist. You can treat computer programs like poems or songs or jokes.  Here’s an example – the c# ‘lunch order’:

public class LunchOrder {
    double CheeseBurger;
    char GrilledPeppers;
    short Cake;
    long IslandIcedTea;
{

or

public class MuhammadAli {
    float LikeAButterfly;
    string LikeABee;
}

Most developers agree that there is an element of craft in the way that they write code. Variable names or indentation styles, give little signs that a real living person wrote the code, as these things don’t make any difference to the computer. When you as a person read that code, these things tell you the person who wrote the code cared; they were paying attention. We can also assume that if somebody paid attention to the little things and got those right, they probably also paid attention to the big things and they got those right as well. These are craftspeople. 

In a talk at the 2021 GitKon Git conference, Dylan Beattie, creator of the Rockstar Programming Language, shared his thoughts on coding as a craft, Git, and more, so let’s dig in.

Coding as Crafting

The obvious comparison here is with people who craft physical objects. Let’s take for example the craft of guitar building, which is also called luthiery. When you pick up a guitar, there are countless little details that can tell you what kind of luthier built that guitar. You can walk into a store and buy a pretty good guitar for about $200-$300. But if you look closely, you’ll notice little details like screws that maybe don’t quite line up with the intended holes, or tiny gaps between components that should fit perfectly flush.

But on the other hand, if you go out and spend $10,000 on a guitar, you expect perfection. You’re expecting a high-quality product, crafted by an artisan who knows exactly what they’re doing. Someone who has skills and took the time and resources to create something that you know they literally couldn’t have made any better.

At the heart of what makes software crafting different than other forms of crafting boils down to version control. There are no backups in real-world crafting. In software, it’s very easy to create a working environment where almost every decision you make is reversible.
If you realize you just spent the entire day building the wrong thing because the product owner forgot to mention that the data export is going to be XML and not CSV, no big deal; you can roll back to an earlier commit, delete the files and fill in some new ones.

But imagine for a second that writing software was like building guitars. You can’t use backspace, you can’t ‘undo’, there is no version control, and there are no backups. Every single thing you do, every decision, is permanent. If you go to compile your solution and there is a bug, you need to write it again from memory. That it doesn’t sound like a whole lot of fun. 

The Crafting Workflow Spectrum

You can imagine all this as a crafting workflow spectrum. At one end of this spectrum is a completely digital, non-destructive workflow. If you have enough hard drive space, you can keep every single version of every single element of a project. Every decision is reversible.

At the other end of that spectrum, you are building guitars from limited stock wood. If you make a mistake, you’ve blown the whole project.

There are entire industries that have moved from one end of the spectrum to the other. 30 years ago, making a movie was a bit like making a guitar. Movies were shot on film. Film stock was sold by the foot,so every minute of your movie would take about 90 feet of film. You had to figure out how many feet of footage you needed before you started shooting. After a couple of weeks of shooting, you’d have all these canisters of film, with no backup copies. Editing a movie was a destructive process where you’d find the scene you want, slice the film with a razor blade, and attach it to the end of the previous shot with adhesive tape. It is incredibly delicate and painstaking work. Today, there are some directors who still insist on shooting on film, but even then, the film is normally still digitized before they start editing.

But the vast majority of film and TV production has moved all the way across the spectrum and is now shot on digital. The entire process is non-linear and non-destructive. Music is much the same. A thousand-dollar MacBook today has more editing power than Abbey Road studio did in the 1970s.

This digital end of the spectrum gives you freedom. It gives you the ability to try things out, experimenting with ideas. And if you don’t like it, you can just roll back. When you’re learning, that ability to explore and experiment is fantastic. 

A Time Before Git

Before Git was invented, you had a couple of choices when it came to revision control. You had Concurrent Versions System, CVS, and tools like Microsoft Visual SourceSafe. These approaches couldn’t really cope with Git merge conflicts, so it avoided them by ensuring that only one person at a time could edit a file. To edit a file in one of these systems, you had to check it out, and no one else could work on it while you had it checked out. There were some commercial solutions such as BitKeeper and Perforce which initially tried to address these issues.

You also had Subversion. Developers of a certain generation first encountered concepts like branches, merges, and tags through Subversion. It brought a completely new model of collaboration, but there were two really significant drawbacks. First, every once in a while, you get something called a ‘tree conflict’, which is where one of your branches had diverged so far from the trunk that Subversion could no longer work out how to put them back together. The other occasional frustration with Subversion was a bizarre insistence that history had to happen in chronological order. It turns out rewriting history is actually pretty useful.

Stuck in the old days of SVN? Check out these step-by-step instructions for migrating to Git from SVN.

Time Travel with Git

The ability to time travel, or work non-linearly, is one of the main selling points of Git. The freedom to make changes across multiple branches and then apply those changes in an order that makes sense is extremely compelling. Software development is a process of discovery; by the time you finish implementing something, you’ve often learned a whole bunch of stuff that you wish you’d have known when you started. 

Git and the Rockstar Programming Language

Reading this, you might be wondering if the Rockstar programming language does anything particularly interesting with Git. It is a quirky, esoteric language where all of your programs are also heavy metal songs, letting you write code that is also 80s, heavy-metal, power ballad, song lyrics. 

While the Rockstar programming language itself is kind of weird, the codebase is just a JavaScript project, complete with documentation in markdown. However, there is something that Rockstar does which is a little bit unusual. Rockstar is actually two repositories; both are hosted on GitHub and open source. One of these repos is the core Rockstar programming language repository that includes the language spec, the interpreter, and the test suite.

Then, there’s the website CodeWithRockstar.com. That site is built using Jekyll and GitHub Pages, with a goal of maintaining a single definitive spec for the Rockstar programming language, having it appear in multiple places, rather than turn the Rockstar language repo into a GitHub Pages site. This means the language spec and the compiler would end up as subfolders of a website by leveraging Git submodules to import one repository into another. Submodules in Git are an incredibly powerful pattern for a specific code reuse scenario, such as one that a website can pull in snippets and chunks of the language spec, and javascript components, straight out of the language repo.

But there are other ways to accomplish code reuse in multiple places. It would be to do it using branches, long-lived branches. You might think this is kind of controversial, and there are people who think feature branches should only exist for a couple of hours, and there are people who think you shouldn’t have any branches at all! 

In Git, there are a few Git branching strategies to choose from, so ensure you find the workflow that works best for you and your team.

A Case for Long-Lived Git Branches

There is a scenario in which to consider using Git branches in a fairly unusual way: teaching a coding workshop. In two days of hands-on coding, students build things like distributed systems or JavaScript components. During the workshop, you’ve got to be able to run, explain and justify every single line of example code. 

Workshop code ideally has to run on machines you’ve never seen before. Workshop code is challenging because it doesn’t have release versions, but instead, has to exist in multiple states at once. In each workshop repository, there are half a dozen branches that represent the state of the code at a particular point over the course of a two-day workshop.

Picture a two-day workshop. If during that workshop you need to update a reference or fix a bug, it can’t just be fixed in the final version of the project. It needs to be fixed everywhere it is relevant. Branches here are not acting as feature branches that are eventually going to get merged back in `main`. Each branch is a long-lived window onto the latest version of a possible future as the code evolves and develops over the course of the workshop. Git makes this even conceptually possible.

Create Art with Git

Git doesn’t just give you a new way to do things, it gives you a new way to think about things. Once you really dig in and start leveraging what Git can really allow you to do, you will find yourself wondering how you ever wrote code without it.

Be sure to check out the last section of Dylan’s talk to catch the world premiere of his new single re:bass.