Skip to main content

Why are we still using C?

Youtube rarely makes great recommendations anymore, but this time it did.

Yday found this recording of a CppCon presentation from 2016 (slides) in my feed and made some time to watch it. It's pretty long, due to an extended Q&A section at the end which I mostly skipped, but well worth watching. The presentation itself is great and masterfully explores the reasons why we're still using C instead of C++ (especially if C++ is such a better alternative?) from a psychological/sociological point of view. The presenter quickly shows that technical arguments are just not effective, and also explains why.

I've greatly enjoyed it because it aligns with some of my leadership beliefs, and also because I don't understand (or I guess I don't have the same frame of reference) people who pick C as their preferred programming language. I've done a bit of C programming while I served in Mapserver PSC maintaining the Swig/Java bindings and to sum my experience up: what's to like about a programming language in which you have to allocate, deal with and free every single character string. The cognitive load is significant and obviously distracting. If this is the deal with strings (a relatively simple concept), imagine everything else.

To help my own understanding, I've picked a few slides out of the presentation that I thought were really interesting and commented them below.

Framing the problem

First, let's frame the problem that Dan Saks wants to explore. I think this slide sums it up eloquently, no need to comment it:


If you're arguing, you are losing

This slide is actually before the one above in the presentation, but I chose to reorder it because I thought it would make more sense to focus our attention on this LPT "after" the framing of the problem. In the presentation it works the other way around because the presenter probably wants to build momentum.


This is a lesson I've come to appreciate in my various leadership roles. In the context of leadership/mgmt I often rephrase it as: relying on power to get people to do things is a slippery slope.
If you use power once, you are putting yourself in a position in which you are forced to use power more and more to keep them going. Eventually you complain about people not being "committed", when you're in fact the reason they are not "committed". Arguing is one of the many forms of power.
The slide has great advice, which we'll see is backed up by further slides later on.

Frame (of reference)

Such depth I would never have expected from a programming conference! The point made by Dan Saks is that people see the world through a set of beliefs (a frame) and use that frame to makes sense of the world. What is important to note here is that the frame makes complete sense to the person holding it, or they would not be using it.
The key to get them to change or update their frame of reference is to understand it first. Negating it (that doesn't make sense! or that's stupid! or that's wrong! or yes, but... ) and then going on a long tirade pushing your frame of reference will only push you further from your goal as your interlocutor will go into defensive mode, closing up instead of opening up.


Programming in C really means: debugging

I laughed out loud when Dan said this, but in hindsight and my admittedly short experience as a C programmer while working on Mapserver, this seems intuitively true. Maybe this is what people mean when they say: I like C because it gives me full control!
(Like you could manage memory better than a compiler or runtime (my sarcastic thought every time I hear this "full control" story)).

What IMHO C programmers really when when they say "it gives me full control" is: I can look at the code while it's running (with a debugger) and understand it. Now that we're closer to understanding their worldview, we can make hypothesis on the best way to change it or influence it. And here Dan has another pearl of wisdom.

Inception

Like in the movie, the best way to have someone execute something at the best of their conviction is to make them think it was their idea in the first place. Who would not do their best to execute their own ideas?

A corollary worth mentioning is that if someone comes to you with an idea and you start making suggestions for changes, etc you've just cut their committment in half. Just shut up.


Conclusion

Dan Saks then goes into a longer section in which he explains one possible way to illustrate why C++ is a better choice (not a better programming language!) than C. Personally, this is not very interesting to me, because I was more interested in the first non-technical part. Additionally, I think that in 2023 we have even better choices that C++, such as rust and swift (another swift link). Unfortunately vendor support is thin to non-existent, but I believe that the first vendor to add suppor for one of rust of swift will have a huge advantage. Maybe. If C programmers get to adapt their frame of reference first.

Comments

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.