On becoming an expert C programmer

I'm a self-taught programmer. I started with Pascal (what seems like an age ago), then C, then VB5/6, then C# and JS and a bunch of other programming languages. At this point I felt like I could pick up about any mainstream programming language very quickly.

And then I tried to tackle Haskell. That was about five years ago, and I think I'm still at beginner/intermediate level with it. But I realized something. These days I have a career and family. Back when I was learning Pascal, I had a lot more time and mental focus on my hands. All the programming languages I've learned since (besides Haskell) were not much different than Pascal, not fundamentally so.

Haskell is fundamentally different. I definitely feel like my past programming experience helped me learn Haskell faster than if I had no experience, but that past experience was also a handicap. I had to discard a lot of assumptions and get to a more basic mindset of what the art of programmming entails. And like a lot of other folks, I found it to be a very rewarding (and useful) experience.

The article advises learning to play music because a lot of good programmers play music. A lot of programmers are also white. Please become white if you can.

Id's Quake and Doom sources are a classic in this matter. I looked a bit at wsw, a fork of Quake 2. Now, my code is full of structs with function pointers. It's like I just internalized the more elaborate syntax and now it's all Hammers and Nails. I mean, function pointers to functions returning function pointers, for example.

  typedef int (*foo) ();
  foo * bar ();
  foo * p = bar;

not rocket science, but ambiguous at first sight when compressed to one line. I hope that kind of syntax is as complicated as it get's, because I'd like to think C semantics aren't really difficult. That is until implementing customized data types on top.

As mentioned in another comment, learning the toolchain is just as important and it's not without reason, that Don Knut takes forever writing about compiler design. Never mind the ventures into the algorithmic side of things.

Those don't seem like "these days" things. In fact, some is much more "old days".

Glib is just another library like any other, and POSIX is just a library plus specification of the details any platform would have to specify. And if you're not on something that tries hard to look like a *nix, POSIX mastery isn't going to help you.

Autotools is a plague slowly being eradicated, the problems it ostensibly solved have become far less serious to the point that they can be effectively dealt with by less insane means.

Make is increasingly replaced or supplemented with other tools (cmake, scons, ninja, ant if you're crazy), especially when builds start getting complex.

Heavy macro usage is not some modern idiom. In fact, "these days" it's indicative of laziness, poor design, premature optimization, or a religious refusal to use an OO language for OO code. Sadly there is a lot of this code out there, but yours doesn't have to be part of it. If writing your application involves many and/or complex macros, you should reconsider your approach.

> I can't understand what undefined behaviors C has, because it is the most simple and defined language I do know of.

C has lots of undefined behaviors because the language was designed to be easy for compiler writers to implement. As such, a lot of decisions were left to the compiler writers, which is what "undefined" means. Here is a (probably partial) list of undefined behaviors in C. (For a full list you'd have to search through the standard): http://blog.regehr.org/archives/213

Edit: Linked to a C++ article by mistake, so I changed it.