Why C?
"think of this as an intervention lol. using c these days is like wearing bell bottom pants (also a product of the 60's)."
- Excerpt from a friends email to me, 2017
As of writing, it's 2020. I still happily write things in C. I use ANSI C (c89) a lot of the time now, but occasionally a subset of C99 will be needed for third party things.
Why C today? The big things are legacy and portability. These are two very important things that need to exist in order for computer music to grow as an artform. I believe software tools for computer musicians need to be usable for many decades. This is how artists master tools. Artists also need to be able to study and learn techniques from the previous generations. This is iteration refinement, where art gets turned into transformed into "fine art". At the same time, the software medium needs to have a degree of malleability. It should be able to adapt to platforms and OSes of the future. For audio, ANSI C fits bill better than anything else out there.
Soundpipe is a good example of a program that trys to think long-term. It's written in very portable c99. In the 5 years that Soundpipe has existed, it has been ported to all the major OS platforms (Linux, OS, Windows), all the major mobile platforms (iOS, Android), the web (via emscripten), several ARM bare-metal platforms, and I've been told that it works on AmigaOS. This is a testament to how portable well written C programs can be. Soundpipe is also written in a very decentralized style. Parts of Soundpipe can be extracted and optimized, and re-used in different ways. It recent years, the devs at ElectroSmith have retro-fitted parts soundpipe to C++ for their DaisySP library.
C is a conservative choice, and in the world of digital art, I am one for conservation. The c99 and c89 specs are very well established. There are also a handful of C compiler implementations out there. Admittedly, clang/gcc have become the only reliable ones, but there are certainly others like tcc, pcc, and lcc. This variety is good. New languages usually have an evolving standard. With these sorts of languages, it can be hard to say what parts will last, and what parts will stay. This volatility is not great for long-term creative ecosystems. One wants to build a tool, master it, then forget about it. It's counter-productive to keep updating to the Latest and Greatest (TM) software stack in order to make the thing run still. Shell scripts, Makefiles, and C compilers will do the trick.
C sucks. It is a well polished footgun. But what's so great about C is that we've had over 3 decades to learn why it is terrible, with many languages designed specifically to address the shortcomings of the language. We've collected a lot of wisdom of what good and C code looks like, and what the best practices are. The same cannot be said for newer languages. I believe there hasn't been enough time to discover the long-term problems like we have with C.
Finally, there's the restrictive aspect of C. One must be thoughtful when writing a program in C. There are many things to consider. Memory leaks and segfaults are easy to come by. C can also be time consuming: there's a lot of handrolling data-structures and algorithms (the sorts of things that higher-level languages have by default). As a result of all this, programs I design in C tend to be built better than if I had implemented it in another language.
home | index