Why You Should Learn C but (Probably) Never Use It


Life is too short for going down the abstraction stack to the bare metal. Anyway, knowing what is under the hood is essential to understand what happens in the layers above

I am not going to tell you that you need to know C/C++ because it is the language that every hacker has to know to be worth of such a name. I am not even going to try to convince you that C/C++ has a shrinking community and this will make the wages rise for those fortunate programmers knowing such language. I will not even use the card of the "high profile" job for a C programmer, also if it is the case since Google, Microsoft, all the high frequency trading players, games studios and everyone in the aerospace industry do need to be as close to the metal as possible to get the maximum from their machines (Luca, a dear friend of mine, used to refer to this as "smelling the soldering"). I am going to use a different point.

I suppose that as an engineering or computer science graduate, programmer or just a simple self-taught practitioner, you know — or just have a sense of — how the computer you are reading this document on, the network that took it to you and the browser rendering it work.

Most likely, the operating system that you use and that makes your computer more than a bunch of metal, silicon and carbon-oxide; the drivers of the network card and the browser itself have being written in C. While the compiler for your favourite programming language could be written in the language itself (this is called "self-hosting"), it could be written in C for efficiency or historical reasons. For certain, if it is based on a virtual machine, this last one is written in C/C++.

When you decided to do this job — unless you are part of this last new wave or self-made programmers who entered the start-up circus just for the money — knowing C/C++ is an essential skill to understand the very nature of how things work. You can program in the most high level programming, or even presentation, language but if you start digging into the stack that interprets and runs your stuff you will end up to a point in which C/C++ was used.

By its very nature of low level programming language, C/C++ was able to replace assembly in all the typical uses of that primeval language. C/C++ was able to make its way in operating systems, programming languages, databases, browsers, text editors and in all the other parts of a computing system. If recently it was replaced in some of these applications by something "higher level", this something still use or need some other library or piece of code written in C/C++.

Now, to the second part: why (probably) never using it.

First of all, do not take my words literally, you will maybe use it to fix or enhance something that you get from the web contributing back to it or you could eventually need to read it in order to understand how things work when the code is, unfortunately, the only documentation around.

Life is too short to spend a huge amount time writing your own abstractions over data, networks or processing. C has almost no abstraction over those things and it comes with a very thin and light-weight standard library that does not provide many fancy functionalities since all of them are usually provided, through C/C++ libraries, to the language by the operating system. Moreover, the majority of the times you do not need all that speed in your own application since the world is moving toward remote services and all your latency and speed problems are in the I/O layer of your application. Doing asynchronous programming in C/C++ is possible but it is as difficult as hell because you have to do everything yourself while any modern programming language with a bit of syntactic sugar makes that possible in very few keystrokes (for instance through the async/await pattern of C#).

In their book "The Practice of Programming", Kernighan and Pike show the same program (i.e., a text generator based on Markov chains) implemented in different languages and then compare the performance of those. While, sometimes, lower level programming languages show an advantage in terms of performance, the scripting languages use an incredibly low number of lines of code and take few hours to be implemented.

It is always a balance between programmer's time and run time. If an application needs to be run 24/7 and it needs to perform a high number of operations very quickly, it could be reasonable to invest quite a bit of time in implementing and optimizing it. If the application is a throw away one or it just needs to wait continuously for the user to do something or if it does a lot of I/O and very little computations, it well deserves to be implemented in a higher language such as, Perl, Ruby, Python, VB, JavaScript, … Those languages are not known to be the best performers around in terms of speed or memory footprint but they enable the programmer to write quick and to be highly productive.