3 ms·
The question that I'm answering is "Best book to learn C in 2022?". K&R written as you say in the 1980s (the first edition in the 70s) is not that book, there i
by armitron 4y ago
The question that I'm answering is "Best book to learn C in 2022?". K&R written as you say in the 1980s (the first edition in the 70s) is not that book, there is far better written material out there: One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are.
I'm guessing based on the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point.
So let me re-iterate that point. K&R is a terrible C book in 2022, and should not be recommended as an introduction to the language. It wraps C in a veneer of simplicity-hiding-untold-complexity which leads readers thinking that the language is much safer and much easier to deploy than reality dictates.
This has proven to be disastrous and something that we should point out and drive newcomers away from.
- tialaramex 4y ago> One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are. I'm not familiar with John Regehr - At least recently, Regehr's blog appears to be extremely low level (relative to C at least). Reading about the IR in LLVM or the ARM machine code which makes a spinlock go isn't a "solid grounding in C". It's fascinating - but it's not about C. Perhaps he used to write more about C? Robert Seacord though, I just don't see it. I think you've recommended Seacord because you're thinking about what you'd need to write good software in C in 2022. But if we wanted to write good software in 2022 we shouldn't use C for that task in the first place. That's my point here. "Secure Coding in C" goes on the shelf next to "Agile Development using the Waterfall Model" and "Version Control using Visual SourceSafe". In each case these should be one paragraph inside, "Better not I think". My assumption is that the OP is curious about the language, to the extent maybe they'll solve Advent of Code in it or something, not that they're about to write or maintain serious C software.
- cxr 4y ago> I'm guessing based on the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point. That's a shamelessly self-serving assumption. When confronted with a claim/argument that is not favorable to your position, you have (at least) two options: one involves employing humility and intellectual honesty in an earnest attempt to resolve the conflict, and another involves inventing a convenient narrative in order to avoid the conflict. An example of the latter would be a stand-up comic who consistently bombs on stage and chooses to cope with it by telling themselves that the audiences are just too sensitive for the comic's edgy-but-otherwise-brilliant material. An example of the former would be for the comic to at least entertain the idea that their sets always bomb because the jokes are shit. Your response (which amounts to "u just mad") indicates that you seem to have taken this approach. You have made a fact claim. You said that K&R "doesn't even attempt" to cover undefined behavior. That claim has been disputed. The next step for you to do is not to change the subject by questioning the motives and emotional maturity of those who have disputed the claim, but rather to substantiate it. (For the sake of completeness: K&R was neither my first introduction to C nor my first introduction to technical writing—not that it matters.)