"Let us C" by Yashavant Kanetkar

This post is part of my Book reviews series, where I share thoughts and impressions on the books I read.

"Let Us C" is written by Yashavant Kanetkar and published as the 18th edition in 2022 by BPB Publications.

As a special mention: I read the 18th edition, but the 19th is available now as well, so perhaps some of the things I mention in this review have already been addressed in the newer edition.

💡Topic
Learn C in a quick introductory manner.

I personally found the usage of the work "Authentic" in the subtitle very funny, but it's good to know that the author believes their book to be authentic; I would definitely not want to read any "inauthentic" ones!

📖Content
The book is split in 24 Chapters and 467 pages including Annexes.

Code examples are showcased, together with explanatory diagrams and some cute graphics with a C character at the start of each chapter.

👩‍💻🧑‍💻 Who is this book for?
Beginners to programming in general and the C language in particular. 

👍Likes
I very much liked the size of each chapter: short, sweet and to the point, just the right number of pages and content to introduce new concepts but not so long that it becomes tiring; more authors of introductory programming books should take the approach to their chapter sizing. 

The diagrams are of high quality, and I think they convey the concepts explained very well, in a superior manner actually to other C books I've read and which I would consider to be better overall.

The philosophical quips and funny input examples interspersed throughout the book were a nice touch, a welcomed feeling of humanity inside what is essentially a terse and cold computer science topic.

👎Dislikes
The text font color of code boxes is too light, making it slightly hard and unnecessarily annoying to read.

Some abbreviations are used without being defined previously, e.g RHS and LHS on page 27.

I think the usage of the term “real number” for what the rest of the world calls “floating point number” or “float” is confusing and unproductive. 

I find the use of multiline comments (/* comment */) for commenting out single lines to be outdated. 

The author assumes most of the time that the reader is using Windows (e.g. we would get an executable file UTIL.exe), which is most definitely not an accurate default assumption in my view, especially in the systems programming world. 

The fact that “call by value” and “call by reference” are explained as abstract concepts, and the way they are explained in Chapter 9 - which introduces Pointers, is in my view a confusion-prone approach and a mistake from the author's part with potentially damaging repercussions to the understanding of future programmers. 

I think there’s a real danger here for the beginning programmerst to misunderstand what the technical behavior of C is, and also to misunderstand what it is that actually happens also in most of the other languages which claim to have "pass by reference" mechanics, e.g Java; they do exactly the same under the hood like what C does, which is passing pointers by value and then dereferencing them to simulate “pass by reference” behaviors. 

It is crucial for future understanding of what pointers are and how they work, to clearly grasp from the beginning that there is no such thing as function being “called by reference” in an absolute technical sense in C: all functions calls are done using pass-by-value in C, and whatever you pass as actual arguments into a function when you call it gets copied in the stack frame assigned to that function, aka its "local scope". This occurs no matter if you pass to the function a “normal” variable (e.g int x) or a (int* y) pointer-type variable; all arguments passed are copied in the stack frame, including the value of the pointer variables. The proof of this is that you always have to dereference twice (**xx) in case you want to modify the value of the pointer itself which is passed inside a function, because the initial pointer you pass gets copied inside the function, and any change to that copied value is only limited to the local scope of the function and will not be seen outside of it.

The tricky bit conceptually to understand here is that only the pointer value itself gets copied (reminder that the value of a pointer is a plain memory address), and not the value of whatever is at the end of the memory address to which the pointer dereferences ("points") to.

The fact that with a pointer-type variable’s value you can do things that are “reference-like” (e.g. dereference them to then be able to change the memory object that they point to) - which is something that normal variables cannot do when passed to a function - is a very different aspect and should be clearly separated in the abstract sense when teaching this topic, from the available mechanics (only one in C, pass-by-value) of passing values to functions.

What I’m saying here essentially - and it might seem like nitpicking but I believe it’s actually very important- is that the capabilities of pointers should not be confused or mixed with the underlying memory mechanics that occur during function calling, as this can easily lead later on to misunderstandings and can be a long-term handicap that you develop as a systems programmer. 

As a separate dislike: after 18 editions I would expect that absolutely all typos and errors have been eliminated from the book. Unfortunately this is not the case, and you still find glaring errors such as calling the binary complement a “compliment”! Not once, which I could classify as a small typo, but it occurs several times in a row actually!

🚧 Improvements I would suggest
Use the newer single line comment style (// comment goes here)

Make the font color of the text boxes darker.

Provide visual breaks in the code to separate sections (personal taste).

Remove mentions to “Turbo C”; something tells me a sub-digit percentage of anyone who will ever buy this book going forward will even hear about its existence, let alone come into contact with it. 

In Chapter 9, when pointer types are first explained in the section “Pointer Types and their Sizes”, it would help comprehension much more if pointer arithmetic would also be presented as well at the same time, even if briefly. 

Overall Chapter 9 should be clarified and explained better, see the “Dislikes” section for more suggestions. 

🤔Final Thoughts
Finding it very hard unfortunately to recommend this book.

I'm aware that this book is seen like something of an "institution" in the Indian subcontinent, and that the author has very high accolades in CS academia. By comparison though to its book competitors in the market, I find it to fall short in many ways that matter. Page for page, also factoring in the actual book cost, you're better off buying and spending your time with other introductory C books, in my humble view.

Even though I think the author has done a decent job at synthesizing a complex topic in a small handbook, this process of reduction has come at the significant expense of over-simplification and even confusing wishy-washy top level explanations. I've encountered this in several places, and my conclusion is that you'll definitely need to read at least another book after this one to be able to properly code in C.

It's important to also note that I've read by now most of the highly rated C introductory and mid-level books, so I think there is some weight to my view and also the ability to "objectively" assess it against its competitors.

In conclusion, I think that by comparison The C Primer Plus (which I also reviewed here) is superior in all points of view that matter for a learning systems programmer. Even though that book is much larger in size and weight, and the text in it can seem more technical and a bit less “accessible”, you’ll get superior information, explanations and understanding when compared to "Let us C", which will help us more in forming a solid foundation for your future understanding.