I’m back from CppNorth, my first C++ convention. I feel like I’ll be unpacking the things I learned there for some time.

While at CppNorth, I attended a talk by Titus Winters called Software Engineering Languages that differentiated between programming and software engineering. You can watch it here on YouTube. After Chandler Carruth revealed the new programming language Carbon at the keynote the following morning, Titus tweeted his congratulations on the Carbon announcement. In that tweet, Titus also shared that by laying out some of the strengths and weaknesses he sees in C++ as a “software engineering language,” his talk set the stage for the Carbon announcement.

There’s a lot to take in with Carbon, but setting that aside, I’m thinking about Titus’s distinction between software engineering languages and programming languages. Titus described programming as short-term problem solving, such as writing a quick script to process a one-time data block. He contrasted programming against software engineering, a disciplined act of software development with products maintained by many people over a long time. When connecting this distinction to languages, Titus argued that there are languages that support one activity better than the other. For instance, Python gained wide popularity as a programming language. However, Python’s convenience and rapid prototyping capability come at the cost of limited performance and static analysis tools that weaken its utility as a software engineering language. Note that there aren’t any value judgments attached to either act. It’s better to solve some problems with software engineering and others with programming.

I would argue that SuperCollider is a programming language in this taxonomy, and for things like live coding, a programming language is precisely the right tool for the job. Meanwhile, just “under the hood” with SuperCollider sits a rich complex of engineering challenges that necessitate the rigors and requirements of software engineering languages like C++. For example, real-time audio synthesis, interpreters, and interprocess communication via OSC are advanced engineering specialties requiring domain-specific knowledge.

Most users will throw away the SuperCollider code they’ve written once they have the desired sounds. Meanwhile, the SuperCollider software itself has lasted for longer than 20 years. The quality of the software engineering work that has gone into SuperCollider enables its use as a programming language and explains, in part, its longevity.

SuperCollider is a programming language that supports the rapid prototyping and deployment of audio workflows as an assembly of software engineering artifacts. The synth components represented by UGens are necessarily software engineering artifacts, and they are written in C++ to enable efficient computation on the audio synthesis servers. So too are the Qt objects that back the most commonly used UI toolkit inside sclang, the NetAddr and MIDI backing, and any other interaction with the world outside of the interpreter through primitives.

This separation of concerns between programming and software engineering is an elegant solution that creates a remarkable software tool for making audio. However, it’s got me re-thinking some of the design priorities in Hadron or possibly clarifying some of my already-held concerns about the language. For instance, I’d like to move more of the core library from programming practice to software engineering practice. Conversely, I’m not seeing software engineering tools like automatic code formatting and test coverage analysis as critical as I once did. Hopefully, by separating these two strategies, I can do the software engineering work to empower others to make SuperCollider an even better programming language.