I’ve started learning C four years ago, after a career spent coding ruby/javascript/Go, so I guess I was in the same position than you. I started by reading the GNU C manual, then the Glibc documentation, and the man pages for headers and functions I was using (all glibc functions have a man page ; depending on your distros, it may already be installed or you may need to install a specific package to install them all at once). And of course, reading header files in /usr/include/
is always useful for using this or that library. Later, I discovered the book Modern C and it completed my education to feel at home with C. I can’t say if it’s the best path, but it worked for me.
Obligatory mention for those who don’t know yet : you can find what files a program use by using strace <command>
(provided strace is installed). It actually logs all syscalls made by the program, so there will be a lot of noise, but in there you will find the access()
and open()
calls.
Additionally, if you want to strace programs that already are running in a convenient interface, htop
has strace support (this is less useful to find configuration files, as those are usually read at the start of the program, but if you can trigger a save to the file, it will appear here).
I use it regularly in projects from other people, almost never in mines. It’s a good tool when I’m completely in the dark, not knowing much about the architecture of the codebase. When I do know the architecture, I usually have a good intuition where the problem is coming from and I go poke the git log of the file or files related to that, it’s always faster than bisecting. But in Terra Incognita, this is an incredibly powerful tool. You know this version worked, you know this one is broken, and you can just follow the process of git bisect to find the exact commit that introduced it. In FOSS projects, it’s usually a commit that changes two or three lines and you can pinpoint immediately what the problems is. If it’s a 1000 LOC change commit, you’re in for more analysis, but at least you know it’s somewhere there. :) So yeah, I would call that mostly a tool to contribute bugfixes in FOSS projects, at least in my usage.
Made me laugh, but I can’t help but think that’s exactly what so many abstractions in OOP languages are doing. NullObject, anyone?
It’s even worse than that. :) I’ve read the 4 standards (which, to be fair, are very pleasant to read, we’re lightyears away from xhtml docs), and I still don’t understand how the search feature works in Lemmy and Mastodon. Because the standards are very minimalists : they describe what messages look like (the various activities a user can do), ActivityPub itself describe the http structure of the inbox and outbox (the requests to do to use them), and… that’s about it. There is nothing about discovery, so I suppose now applications implement it as they see fit, which means on top of understanding the standards, you need to understand actual implementations (that’s what I’m going to read next, at least).
We probably were not living on the same planet, then, you and me. :) From what I saw, in the 2000’, there were no “backend developers” either. We were all webdevelopers, then younger people started to call us “fullstack developers” when they specialized. But the hate against javascript is way older than that. Already in the early 2000s, it was considered a malware language. It’s only when prototype.js and scriptaculous introduced web animations that people started to consider it seriously. Even then, jQuery’s main sale point was that it allowed to do the least possible amount of js. Anyway, it doesn’t matter when and why you started hating, hate is always wrong, period.