Well I guess there are different kinds of programming, aren’t there! The title of this article is like saying, Writing in English requires no skill and can be done by anyone. Yet amazingly not everyone is Shakespeare. I agree that more people should be encouraged to program, but, say, writing a multithreaded server in C is a programming task that even very smart and experienced programmers rarely do well. So I find the generalizing of this article ludicrous. Also, the language inventors cited created high-level languages all of which are arguably inelegant, inefficient, and unnecessary. Those people have contributed to the proliferation of superfluous high-level languages. I think this article is incredibly uninformed and short sighted.
I love being outside, and it’s great to get a break from computers, but I grew up like this. The screens were smaller, the processors were vastly slower, but this is what I do. I’ve been programming since I was 7, writing since I was 8, it just feels natural to be tapping away, with a C compiler in one window and a blog in the other, writing something, coding something, this is what I do.
Most debugging is easy. The compiler or the memory checker tells you what’s wrong up to a certain level, and after that you can compare the actual and expected results of your program, to fix the rest. With some experience almost all debugging is routine, even with multithreaded and network apps…you follow some process and fix problems with rapidity. But sometimes there are harder problems.
A coworker and I debugged a problem a few years ago where somehow some of the whitespace in the program contained a special character…it showed up as whitespace to our eyes, but to the compiler it was a non-whitespace character. So we were getting an error message that indicated that something was wrong with a piece of code which, when we looked at the code, there was truly nothing wrong with. Even copying and pasting the code section maintained the error. We knew there was something wrong because the compiler was complaining, yet we were correct in our assessment that the code we were reading was error-free. It took us a while to find the incorrect assumption: that the code we were reading was not the code that was there.
Today I solved a hard bug. That’s significant to me as it doesn’t happen often. I had referred to a variable, called system, in a newly-written function, without passing that variable into the function. Normally, if you refer to something that isn’t there, the compiler will find that and it will be one of the first and simplest problems you debug. In this case, though, there was already a global variable named system, that hid the fact that I hadn’t declared my variable. That global system variable was not put there by me…it’s part of some library I included. So there was no compile error and no memory error, but there was a program error, because when I thought I was referring to my variable system (which didn’t exist in that scope) I was actually referring to a different variable of the same name (and the same type, which just happened to exist for me because someone else created it). It was a fun “gotcha”…and finding that in thousands of lines of code took some time…because as simple as the situation is now that I understand it, the way the situation presented itself to me is this: it looks like somehow my pointer value is getting messed up, and no matter what I do, I can’t find the line of code that messes it up. That’s because my way of stating the problem is wrong: I was looking at some words called “system” all over my program, and trying to find where I mis-set one of them…but the assumption that all those “systems” referred to the same variable(s), variables I had created, was wrong…even though usually that’s a safe assumption since the compiler tells you when you refer to something that doesn’t exist…but it certainly doesn’t tell you when you happen to be using a variable named the same as someone else’s poorly-named global variable. The problem took a while to solve because of the way I was stating the problem to myself.
Programming, especially debugging, but programming in general, can be seen as a process of rectifying your idea of the world, with the world as it actually is. Most of the time, during the programming process, what you have left to do is measured by the difference between what you think is going on, and what is actually going on. It’s humbling to realize that in programming (as with other parts of life) there is almost always a delta between our models of reality, and reality itself. We are, essentially, wrong. Programming, and some other types of self-examination, involve humbly discovering exactly how.
h is a library of C programming tools that I created and am now hosting. It has containers, client/server networking, thread synchronization, PostgreSQL database access, uuids, config file support, and logging. h is free to use. Modify it, contribute, use it for commercial purposes—do whatever you want with it.