Introduction
I'm pleased to announce the pre-release of my forthcoming book Why Learn C to be published with steadfast support from my editor Melissa Duffy at Apress by the end of September 2025:
If you’re thinking, “Why a book on C?,” I address that in the book’s Preface, an excerpt of which follows:
“Should I still learn C?”
That’s a question I see asked by many beginning (and some intermediate) programmers. Since you’re reading this preface, perhaps you have the same question. Considering that C was created in 1972 and that many more modern languages have been created since, it’s a fair question.
Somewhat obviously (since this book exists), I believe the answer is “Yes.” Why? A few reasons:
-
Modern languages have many features for things like data structures (e.g., dynamic arrays, lists, maps), flow control (dynamic dispatch, exceptions), and algorithms (e.g., counting, iteration, searching, selection, sorting) as part of the language (either directly built-in or readily available via their standard libraries). While convenient, the way in which those features are implemented “behind the curtain” has to be done in a general way to be applicable to a wide variety of programs. Most of the time, they work just fine. However, occasionally, they don’t.
C is a fairly minimal language and has almost none of those things. If you want any of them, you’re likely going to have to implement them yourself. While onerous, you’ll be able to tailor your implementations to your circumstances. Knowledge of how to implement such features from scratch and understanding the trade-offs will serve you well even when programming in other languages because you’ll have insight as to how their features are implemented.
Many systems and some scripting languages (e.g., Python) provide C APIs for implementing extensions. If you ever want to write your own, you’ll need to know C.
Many open-source software packages upon which modern computers and the Internet still depend are written in C including Apache, cURL, Exim, Git, the GNU compiler collection, Linux, OpenSSL, Postfix, PostgreSQL, Python, Sendmail, Wireshark, Zlib, and many others. If you ever want either to understand how those work or contribute to them, you’ll need to know C.
Embedded systems are largely developed in C (or C++, but with restrictions). If you ever want to work on embedded systems, you’ll likely need to know C.
C has influenced more languages than any other (except ALGOL). If, in addition to programming, you also have an interest in programming languages in general or from a historical perspective, you should know C.
I’m not suggesting that you should learn C intending to switch to it as your primary programming language nor that you should implement your next big project in C. Programming languages are tools and the best tool should always be used for a given job. If you need to do any of the things listed in reasons 2–4 above, C will likely be the best tool for the job.
“Wouldn’t learning C++ be good enough?”
“I already know C++. Isn’t that good enough?”
Since C++ has supplanted C in many cases, both of those are fair questions. The answer to both is “No.” Why? A couple of reasons:
Even though C++ is based on C, their similarities are superficial. Aside from sharing some keywords, basic syntax, and toolchain, they are very different languages. The ways in which you get things done in C is necessarily different from C++ due to C’s minimal features.
From the perspective of learning how features are implemented behind the curtain, C++ is already too high-level since the language has modern features and its standard library contains several data structures and many algorithms.
“Why this book?”
If all that has convinced you that C is still worth learning, the last question is “Why this book?” Considering that The C Programming Language (known as “K&R”) is the classic book for learning C, that too is a fair question.
The second (and last) edition of K&R was published in 1988 based on the then draft of the first ANSI standard of C (C89). C has evolved (slowly) since with the C95, C99, C11, C17, and C23 standards. This book covers them all.
This book is split into three parts:
Learning C: teaches the C23 standard of C, includes many additional notes onC’s history and philosophy, and also includes best-practices I’ve learned over my thirty-five year career.
Selected Topics: explains several additional advanced or obscure parts of C that I’ve found not to be explained well elsewhere, if at all.
Extended Examples: gives detailed examples with full source code of how features in other languages might be implemented including discussion of the trade-offs involved so you can understand what’s really going on behind the curtain in whatever language you program in.
Additionally, there’s an appendix that lists differences between C23 and C17, the previous version of C.
Motivation
I’ve been writing articles for my blog, chiefly on C and C++ programming, since 2017. Unlike far too many other programming blogs, I wanted to write about either advanced or obscure topics, or topics that are often explained incompletely or incorrectly elsewhere. Indeed, many of the topics I’ve written about were motivated by me reading poor articles elsewhere and thinking, “I can do better.” Since each article is focused on a single topic, I invariably go deep into the weeds on that topic.
Those articles explaining topics incompletely or incorrectly elsewhere were sometimes on really basic topics, like variables, arrays, pointers, etc. Again, I thought, “I can do better,” so I wrote a whole book that teaches all of C from the ground up.
More about “Why Learn C”
My book is 404 pages. (For comparison, the second edition of K&R is 272 pages.) It took me six months to write largely full-time (that I could devote to it since I’m mostly retired).
Not mentioned in the Preface excerpt is the fact that the book contains over 100 inline notes containing commentary, explanations for why something is the way it is, historical context, and personal opinion, i.e., things not essential for learning C, but nonetheless interesting (hopefully), for example:
- Why does the first program ever shown in any programming language print “hello, world?”
- Why does the C compiler generate a file named
a.out
by default? - Why is
_Bool
spelled like that? - Why does C have such a convoluted declaration syntax?
The book does borrow a few topics from my blog, but they’ve been reworked into a cohesive whole along with a majority of all-new material.
Just for fun, the book also contains a few apt movie and TV quotes ranging from The Matrix to The Simpsons and several instances of an easter egg homage to Ritchie. (See if you can find it!)
In case you’re wondering, I used LaTeX to typeset my book. Prior to this book, I had never need to use LaTeX, so there was a bit of learning curve. Some things about some of LaTeX’s packages still seem either incomplete or somewhat broken as if nobody had actually used them to write a book before. At some point, I might give details about using LaTeX, but that’s a story for another time.
My actual text editor was trusty old vim and LaTeX renderer was TeXShop.
If you like my blog, I expect you’ll love my book.