Abstract Language:
Music and Software

Kelly Curtis


To start out this article, here is a YouTube video about Glenn Gould and Leonard Bernstein where Bernstein talks about how they must read the symbols and make decisions in regards to a Bach Keyboard Concerto. It is a great video, and as a bonus, you get to hear and see the Piano mastery of Gould. The first 6 minutes are what the purpose of this article is about. To talk about how Software Engineering uses language in a very similar way that Composed Music does. That is, once the originator (Composer/ Systems, Data, Software Architect) puts their idea to paper (Musical Scores/ Software Libraries, Codebases), it is up to someone else (Performers/ New Engineers, Maintaining Engineers) to understand it. This process is what makes Music and Software such a great compliment to each other in studying the written forms of both.

Recently, the topic of abstraction came up in a conversation about patents for software. The primary theme was this; when writing claims, how do you abstract implementation details at a level high enough to cover the core idea of software? In the end, it came down to to trying to write things to allow for as little variation in interpretation as possible while covering as many implementations as possible.

Interpretation is not something that is talked about in Computer Science a lot. What?! LIES! All these languages are interpreted, so we know all there is to know about interpretation (Javascript, Python, Ruby, etc). As Software Engineers, we know that when we use these languages, the interpreter will take the symbols we give it, and create a process using your instructions without us having to worry about how the memory, CPU, disk, and network are used. This is a huge productivity win for professionals, as they are able to say more with less.

With that said, it does nothing to say how the actual code is going to be interpreted by the next human (non computer) that needs to read and understand the code. This kind of interpretation requires understanding machine language linguistics and how humans read and understand visual symbols. In the field, we call these Standards or Conventions. Every corporation struggles with maintaining Software Standards due to this very issue. This very problem is what leads to technical debt.

Starting with this assumption:

Software is a living language written to deliver instructions to both humans and machines. This creates a paradox where the written language can be designed to either help us say more with less (Abstraction, Encapsulation, Frameworks, etc - ie approach-ability or business class systems), or to say exactly what we mean to say (Assembly, Drivers, Firmware, etc - ie high performance systems). Simply put, Software can be infinitely abstracted. There is no end to how simple or complex the written form can be.

A quick look on Wikipedia, one can easily see that there are well over 100 different programming languages. This is an important point to make because conservatively, computers have only existed in their modern form for 80 or so years (1930s). This means a purely scientific and engineering driven field has spent decades trying to master the "Art" of abstract instructions at just the right level for other people to understand.

Wikipedia Article - Programming Languages

Given the assumption that Software is a language meant for humans and machines, we can start to look at other languages throughout history that perform the same basic function. As a computer is a universal device capable of performing any compute function that can be programmed into it via a written language, a musical instrument is a universal device capable of performing any sound function that can be programmed into it via a written language. This fundamental similarity has led to the development of purely abstract languages that are built on symbols because the devices need a human to input the commands.

Music is a great candidate for a study in the development of machine languages and how we can deal with evolving the language of Software without losing sight of its own history. New languages are coming out every few months (it feels like). This creates a situation in the world of Software where ideas will never be understood in the future. This is a byproduct of abandoning languages so quickly (<20 years). It gives this Software Composer concern, as it should all Software Professionals. The wheel is being reinvented so often that as professionals, we have lost sight of the fact it needs to be a circle, and not a square. Context is completely lost for new tools and languages and technical debt ($$$ liability $$$) is being generated exponentially at this point.

How is the world capable of knowing that Bach was the great composer he was? My belief is that it is because we can still read the Music, hundreds of years later and understand it. This is a major problem in Software. With language evolving so fast (100+ languages over 70 years), we are losing the ability to read the "old" languages. This is where Music and Software can learn from each other; how to preserve an idea using abstraction to hide the implementation at a high level, while maintaining a low cost of ownership.

Please feel free to reach out to me if you are interested in this kind of topic.


Kelly M. Curtis, MBA, PMP, PMI-ACP

bootstrap builder