Chris's Wiki :: blog/programming/CProgrammersTwoTypes

The two types of C programmers (a provocative thesis)

April 22, 2023

Here is a provocative thesis:

There are two types of C programmers: people who chose C because they liked various of its properties, or people who used C because it was their best or only option at the time.

Back in the days, C was somewhere between your best option or your only real option for doing certain sorts of programming. If you were writing a Unix program, for example, for quite a while C was your only real choice (then later you could consider C++). The people who came to C often found some of its virtues to be attractive, but they weren't necessarily strongly committed to it; they'd picked C as an expedient choice.

Meanwhile, there are people who looked at C and felt (and often still feel) that it was very much the language for them (out of those available at the time). They feel strongly drawn to C's virtues, often explicitly in contrast to other languages, and today they may still program in C out of choice. If and when they switch languages they often pick languages that are as close to the virtues of C (as each person sees them) as possible.

I am the first sort of C programmer. I like some aspects of C but there are others that I more or less always found to be kind of a pain; as I've kind of said before, I no longer want to have to think about memory management and related issues. So I've wound up mostly in the Go camp, despite Go's garbage collection being anathema to a certain sort of C programmer.

(Thinking about memory management can be fun every so often, just as it can be fun to optimize anything, but I want it to be an optimization, not a mandatory thought.)

My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust. Rust is certainly not C-like in some respects, but in a lot of ways its virtues are the most C-like out of all of the mainstream languages (and some of the ways it's better than C are important).

(Like all provocative theses, this is a generalization and simplification. People had and have many reasons for choosing C. And yes, there are non-mainstream languages that are trying to be 'a better C' in ways that are significantly different from Rust.)

Comments on this page:

By Fazal Majid at 2023-04-23 04:52:49:

I’m type 2, and if I were to switch, it would be to Zig. Rust is too bloated a language, with constant churn in the language spec, and would be more appealing to a C++ programmer.

By Walex at 2023-04-23 11:40:56:

I am one of those programmers that really liked C as a pretty decent, usable, evolution of BCPL and B as a MOHLL (Machine Oriented High Level Language). The major non-MOHLL alternatives at the time were Pascal, which was a toy language, Algol 68, for which compilers were rare and expensive, and Visual Basic :-).

What I had greatly underestimated is that C (or any MOHLL) in the hands of programming practitioners was a vehicle for enormous amounts of bugs. I discovered that there are two types of people who do programming:

"programmers", who write programs that work, except for some occasional mistake, that gets fixed in good time.

"programming practitioners" who write programs that mostly don't work, even if they appear to work in some cases, and are bodged into working in more cases over time.

C is a catastrophic tool for the second category, largely because so many mistakes don't get detected. "Go" is an attempt to have a C-like language for "programming practitioners", and "Rust" is an attempt to do a safer MOHLL for the first category, as our blogger argues.

One of the great missed opportunities of our times has been the lack of widespread use of Ada, I am not joking. Even if a bit inelegant it is/was a pretty decent language with a lot of error checking, and while there were a lot of Pascal-like languages like Ada over time, some of which became fairly successful in some segments (e.g. Borland Pascal), only Ada had the overall (technical, social) potential to be a widely used language.

Unfortunately the world have chosen JavaScript and Python as the dominant non-MOHLL languages for "programming practitioners",

But nowadays the cool kids use Julia (or Scala sometimes).

By Verisimilitude at 2023-04-28 20:39:01:

Alternatively, there are people who like the C language, and people who are forced to use the C language, usually by UNIX. I'm in the latter group.

If you were writing a Unix program, for example, for quite a while C was your only real choice (then later you could consider C++).

There's some paradox of the intolerant minority here. Real operating systems could support many languages, including the C language, whereas UNIX only really supports the C language.

If and when they switch languages they often pick languages that are as close to the virtues of C (as each person sees them) as possible.

It helps that most people only seem to be familiar with C-flavoured ALGOL clones. All of C++, Java, JavaScript, Python, and others fit this description.

I was glad to see Ada mentioned here by Walex. Ofttimes, I need to do something incredibly basic, but which isn't in my chosen language's standard library. UNIX, of course, makes this a horrible experience by only exposing interfaces to its only supported language, the C language. However, unlike the C language, Ada doesn't expect the entire world to bend over backwards to work around its design flaws, not that Ada has any design flaws as grievous as the C language's anyway. So, Ada 1995 has standard packages for interfacing with FORTRAN, COBOL, and the C language, which I use to interoperate with UNIX and cover up the nonsense with a proper Ada package. Even then, I must wade through the raw sewage of header files and definitions only exposed to the C language. Still, at least this way I can avoid writing any C language code whatsoever.

Written on 22 April 2023.

«	The traditional workaround for stuck NFS(v3) locks

Programming on Unix and automatic memory management