This is the sound of me writing a small program on my laptop to read a list of numbers, sort them, then write the result back to disk. When I run the program, you can hear what the program is doing. Things don't work quite right the first few tries (they never do) but I eventually get it right.
For those interested, here are some technical details.
The program is sorting a list of 10 numbers using a recursive implementation of the quick sort algorithm. I did in fact write a program to do this and had it output sounds (to a midi file) as it ran. I then later modified the midi file to adjust things like instruments. I actually got everything working correctly first, then went back and added the various bugs that you'll hear me correct. (Getting the sort working correctly was easy. Getting the audio output working right was a little bit more tricky!)
The first time I try to compile, there are build errors, so it fails quickly and I fix those.
The next time I compile, it builds successfully and runs - but it gets stuck in the loop that reads the numbers. You can hear the tap of a drum each time the loop goes around. It's stuck, so I stop the program, fix the problem, and run it again.
It makes it safely through the loop this time and begins to sort the list, but there seems to be a problem with the recursive sorting algorithm - it's never hitting the base case so the program continues deeper and deeper into recursion until it runs out of stack space (memory) and crashes. The problem here is that one of the parameters to my recursive call is off by one, so the same call gets made repeatedly. I fix the program and try again.
This time it makes it through the program. As you can hear, the notes are played in ascending order in the end, so it seems to have sorted the list correctly.
If you want to try to figure out what is actually happening as each sound plays, here's a guide to help you with the sounds:
- Anything dealing with the values of the numbers, either reading from disk, writing to disk, or swapping them in memory, is done using a piano. The pitch inidicates the value of the number.
- The low synthy sounds in the beginning and end are the sound disk access, and of memory being allocated and freed.
- A tap on the drum happens each time a loop executes.
- Normal calls and all returns are represented with violins.
- The recursion into the main quick sort algorithm is represented by the long synthy sounds in the middle. As the recursion depth increases, the pitch of the note increases as well. Returns from the recursive call also change pitch depending on the depth of the call.
- Whenever the base case is hit, a bell is sounded. You'll only hear this the last time through.
[edited to add critique reflections, below]
A couple of issues came up during critique which I hadn't thought much about when I was creating the project. The hum of the computer underlying everything, for instance, wasn't something I thought too much about, it was just necessary to get things to sound normal since it was necessarily there when I recorded the sound of myself typing (and it would have been jolting if the hum just disappeared when I wasn't typing). I also hadn't really thought too much about the loud key press when I tapped the enter key to build the project. Although this did serve as a nice signal to start the "virtual" sounds, I put that in merely because that's really what it does sound like when I finish modifying a program. I was concentrating mostly on making the "real" sounds sound as close to possible to what they're really like.
I'm happy with the length this came out to be. My first version was a lot longer, and so I cut out a lot of the keyboard sounds. What remains, I think, is sufficient to show that changes to the program are being made, but not so long as to get dull. The point of this wasn't to show how annoying it can be to track down a bug (it can take hours, sometimes) but instead to show the progression of the program's behavior as it is modified, and the process of slowly adjusting and fixing a program until it really does what you want it to do. The evolution of the program's behavior, and the interaction between the programmer and the program's behavior was my focus, rather than the actual work that needs to be done to fix a program.
About the only thing I'm not completely happy with in this is the first "virtual" sounds you hear, when the build fails the first time. It doesn't sound quite like I wanted it to, though I'm not completely sure what it SHOULD sound like...I just know it's just not quite like that.