For lots of reasons this past week I decided to look into books on the C programming language.
There are very few books that have been published in the last 10 years on C.
You’d think that given the amount of code that is still being written, the amount of code that must be supported, new books would exist.
Heck, you would expect web pages to exist.
Instead, crickets.
Or I am just doing my web searches wrong.
The challenge with C, if you’re an author of a book, is that the language is pretty simple. The libraries are also pretty simple. The complexity of the language is that, unlike almost every other language out there, C does very little to obscure or hide the underlying hardware. To program in C is to program, for better or worse, directly on the underlying hardware.
Hardware doesn’t have garbage collection, memory hierarchies exist, CPU’s have error handlers and has registers that need to be carefully programmed. Hardware has errata that makes your code break in weird ways.
There is a temptation to write a book about the C language that quickly turns into an apologia for the limitations of the language definition instead of an exploration of how and why it’s used and the value it brings.
Most texts and books that exist for other programming languages advocate a style of programming that tries to create a nerfed environment that hides the complexity of hardware. The theory of those authors and language being that the physical reality of hardware gets in the way of creating magical software that only the Turning Tar Pit constrains. Heck, Apple just released such a language called Swift to get away from Objective-C because — in many ways — it didn’t abstract the hardware enough.
There is a book crying out to be written about how to program to the hardware-software interface. A book that demystifies a lot of what I have learned through painful, bloody and miserable training.
If someone has a good book, just drop me a comment.
Not just Apple. (Formerly) Google’s own Go language, designed by Ken Thompson (yes, the one who co-invented Unix as well as C’s predecessor, B) and Rob Pike (of Plan9 OS fame), also does much of the same thing.
I like these languages. I just wish I had some material for C to do some teaching and training.
My First C application was an IIS log file repair tool. Servers had 2GB of Ram, and the logs were many many GB. I wrote something to eat the files line by line without loading it all in to memory and throwing away corrupted lines (IIS in NT4 with CF liked to corrupt logs when it segfaulted).
My learning process was mainly ask a compsci major about the libraries and search for equivalencies for perl/php in c. Even back then when it was the hot, Most of the books were just garbage. Learn C in 28 days I think was the best one I had found and it was really only decent if you already knew quite a bit of C.
Seems little has changed.
I’ve heard good things about http://www.amazon.com/Computer-Systems-Programmers-Perspective-Edition/dp/0136108040 , which is used as a textbook at CMU and is reasonably up to date. It’s on my to-read list, but I have not gotten to it yet.
Will give it a look. I think I saw it once
I’m about 1/2 way through “21st Century C, tips from the new school”. So far I’ve found the history of how the language has changed somewhat valuable and there are some solid things to do/not do. As you say programming in C really is more about about the underlying operating system and processor architecture. The first C program I wrote involved reading files out of file system using the raw disk device on Vax running BSD 4.1. It took me about 4 hours to learn the language, about 1 week to grok the vax architecture manual, and about 2 days to wade through the academic papers and documentation on FFS (including reading the source code). Today, I think you need about 6 hours for the programming language and 6 months to address the modern equivalents of OS and processor architecture.
Thanks on the book will check it out.
Kernighan and Ritchie is “the” book for C programming.
It is “the” book, but as a language reference and not so much as a best practices book. Some of its examples try to be a little “too clever” and could lead to buffer overruns and other sorts of nasties (none of the sample string routines do any bounds checking and the don’t even mention why it is or isn’t a good idea to do so). It also doesn’t explain why printf(someString) is more dangerous than printf(“%s”, someString) other than saying it may result in incorrect output (ignoring the format string vulnerability issue here). Granted, the book was written and published long before these security issues were well-known. However, that brings up another issue with the book: it was published all the way back in 1988 (and a quick Amazon search doesn’t lead me to any newer editions) and as such is quite outdated. Heck, people who only refer to this book don’t even known that C supports the ‘//’ comment character a la C++ since C99, let alone other new features of the language since it was published.
As a companion to a more modern C book that covers newer versions of the language, it’s still an excellent book. However, you still need something that grounds you on both changes in more modern versions of the language as well as the gotchas in the language that have been discovered since the book was published.
Six years late to the party but now there’s https://nostarch.com/Effective_C as well.
Kostadis,
You are an idiot of the highest order. Only the management at vmware is more stupid than you. You have no ability to program, and you know it. That’s why you have not contributed a line of code to any product at vmware in the entire time you have been there.
Hope you get found out, exposed and run out of town.
Dear affinity 71,
I wish you had written your name down because then we could talk about my job and why I would uniquely add value. I understand that you feel that I add no value, and I understand that you think I’m worthless, and I also know that it is a lack of perspective. So here’s my offer: Reach out to me on my e-mail or corporate e-mail, and I promise I won’t get angry. I won’t be upset, and I’ll walk you through – Why does what I do add value? Why am I willing to do it? Because I think you’re a good engineer, and I think your career will be hindered if you don’t understand what it is that I do.
I’m sorry for what I did that upset you so much. It’s not good for you, and it’s not healthy for you either. I promise not to get angry. I’m willing to spend some quality time with you explaining what I do, why the company sees value in me, and how you and I can do it together.
So, please reach out.