2008
The Musical Element
<meta>
There simply isn’t enough time to write about all the ideas in my mind. I originally wanted to create a working prototype so that I could blow everyone away with this follow-up post, but that would have taken even more time. I’m spread too thin as it is. So I’m not going to spend much time writing about some of my ideas about the primal element of programming. That means no footnotes making pedantic clarifications to prevent people from pointing out how what I post is somehow wrong. [Yes, you’re supposed to laugh after reading that comment. :-) ]</meta>
If you haven’t read my last post, you will be confused. So go read that now! I mean it.
Did you read it? No? Read it! … Okay. Fine. I give up.
One of the first ideas that came to me was music. Can we connect programming to music? Can we find a meaningful correspondence between them?
One answer that popped into my mind was the special forms of Scheme. They are like the atoms of programs, and there are 7 or so that combine to make all programs. Similarly, in music, the notes A through G are like the atoms of music; 7 or so of them combine to make all music. So what if we said each special form corresponded to a note, and as we executed a program, played its tune …?
The repitition symbols used in music notation are reminiscent of loops in assembly. Labels, gotos, breaks. (Interestingly, loop conditions are implicit.) Programming and music coincide too much to ignore.
The way I imagine it, a master programmer/composer would write a program that actually did something useful, but also sounded beautifully, like music. In this way, a program would be a huge pun. It would have two completely different meanings, one as software and another as music, whose sources would be intertwined so tightly that you couldn’t separate the two.
Think Perl poetry, but to the next level in so many different ways. Perhaps one could even listen to the execution of a program and tell something was off, just by the sound, and track down a bug based on it.
A simple program would sound simple, like a simple one-instrument tune. As you implement more features, the sound becomes fuller, as there is more going on, and the program/piece sounds more like a symphony performed by a full orchestra.
How exactly would this work? I’m not sure. First of all, how would you play multiple notes at once? I have no idea. How would you represent changes in pitch between, say, a C and a C that’s one octave higher? Could using the number of levels deep the call stack is work? as in, each level deeper corresponds to one octave higher? Tail-recursion could prevent you from ever-increasing your stack depth. In this way, tail-recursion would become practically a necessity.
What about different voices or instruments playing simultaneously? The most obvious thing would be to have concurrent threads, each representing a different voice. But how would you sync them? What about the beat? What if all I wanted was a simple, regularly-repeating beat? How would that look in the code? Could the runtime somehow infer it from, say, memory allocation? as I’ve seen some profiler graphs that actually have a repeating pattern.
How about the tempo? Unless you found some way of grouping blocks of code together, playing a note every time a special form was executed would sound like one big chaotic storm of notes all at once. What to do?
As you’ve probably noticed, this doesn’t answer any of the questions I raised about the primal element; it only raises more questions. But perhaps this will inspire someone… I have my own projects to work on.
