It’s been a couple weeks, so let’s focus up and get down to business. Which, as we all know, means
promulgating Rust talking about software engineering.
It was reported by the creator of curl a few weeks ago that half of curl’s vulnerabilities are C mistakes. Notably, this is only talking about security vulnerabilities. (also, fun fact, curl is apparently used by that really far away helicopter, Ingenuity. If Ingenuity is hosting a WiFi AP to serve its camera data, JPL isn’t telling)
Everyone and their dog has a blog post talking about this. It’s a lot of buffer overflow stuff, a bit of use-after-free stuff, a couple double frees, and a couple NULL pointer dereferences. Nothing super interesting, par for the course for any C programmer, and these types of things have directly inspired all modern programming languages as we know them.
But, unlike this blog, that blog has comments, and reading them piqued my interest because they were just a whole bunch of variations on the same thing.
There are, in total, 18 comments, of which 4 1⁄2 (partial credit to one of them) contain some variation on the theme best put by the top comment:
C mistake? I blame it [sic] lack of design!
In other words, the idea that the problem isn’t with C, it’s with the fools who program it. If only we had better programmers, this wouldn’t be a problem.
And they’re right. Sorta. There’s sort of two things here.
One is that, yes, Java schools substantially lower the barrier of entry for software engineering (kids these days). Joel Spolsky (of Stack Overflow fame) has covered this topic much more in-depth (and more humerously) than I can, but to summarize: Being able to wrangle with pointers is what separates the great programmers from the rest. Obviously, if only we only hired these “great” programmers, all would be well.
But, it’s hard to hire these “great” programmers. It may not be easy to notice if you’re just a hobbyist, working on a program by yourself. Or if you’re not the person who does the hiring at your company. But the fact is, there aren’t enough programmers to go around: The US Bureau of Labor Statistics estimates that from 2019 to 2029, the number of software developer jobs in the US will grow by 22%. Software engineer pipelines are reaching into high school.
The other thing is that even if you had better programmers, are you going to waste their time dealing with making sure their array indices are correct? They could be spending their time inventing amazing architectures, tying them down with the little stuff is counter productive. If you own a restaurant and have a five-star chef in your kitchen, you don’t get cheap ovens that won’t hold a steady temperature and then say “why do we need better tools, burnt souffles is an issue of the chef not paying sufficient attention to their souffles.”
So, I keep hammering this point home, and I don’t plan to stop: Software engineering is, currently, a profession as subject to creativity or human factors as any other profession, like emptying barrels. Programmers are raised (dare I say, programmed) to think of the world in terms of hard absolutes. There is no God, there is only what compiles. Don’t get in the way of my beautiful algorithm with your need for a user interface.
If it compiles, shipit.
But we’re all humans. Designing our tools and processes with this in mind is mandatory in order to function properly in a 21st century
Fox programming environment.
P.S. The half-credit comment goes to the comment that noted that “it isn’t a problem with C, it’s a problem with the libraries, C has a terrible ecosystem.” Yup. That’s true. And why is it that C has a terrible ecosystem?
This blog series updates some weeks at Programming for Maintainability