Reader

The C Programming Language is a fantastically pragmatic abstraction over assembly language. I’m not saying that C invented any of the following, but it did solve the problems of expressing mathematical formulas, control flows, subroutines, data types, and various other things we take for granted when writing programs. By the time the language was an ISO standard in 1989 (“C89”), it had become widely used by professionals on serious software products.

It also had some glaring faults, such as memory safety, memory management, string handling, and so on. These faults prompted the rise of many descendants such C++ and Java, and ultimately also newer versions of C itself.

There was one thing that I really liked about C89, though: it was small enough for a programmer to learn almost everything about it. Many CS students would have implemented a subset of a C compiler in school, and most programmers can probably reimplement the C standard library in a matter of weeks. It was a tool kit that can feel fully mine.

The descendant languages don’t feel that way. In fact, they seem to grow faster than I can learn and master, and the problems they try to solve seem more distant and esoteric with each successive version.

Maybe I’m slowing down as I get older, or maybe I’m just not that smart to begin with, but maybe the language designers don’t have the right incentives to stop once they’ve accomplished what they set out to do. It annoys me that what was good and idiomatic code would become substandard in a subsequent revision of the language (C++ before and after STL is a good example).

In the meantime, the implementations suffer. Swift is now famously bad at the basic task of compiling code. It routinely just gives up at compiling SwiftUI code, vaguely demanding that the programmer simplify the code somehow.

I feel like the tail is wagging the dog now.