Ask HN: What is the best programming book you've read?
Whole language is an approach to, or attitude toward
learning that sees language as a whole entity, and writing, speaking,
reading, and listening should be integrated when learned.
It's been years since I even touched C and at this point I am not going back, I know; but as an Android dev I wish I could find a non-lengthy book like K&R that would expose me to Kotlin like I was exposed to C, while helping unlearn a lot of Java.
I didn't enjoy that much as a teaching device, but I had the chance to greatly appreciate its timeless writing style.
It's as good today as a book about the C language as it was when it was first published.
About 20 years ago C# was the second language that I'd learnt after C/C++ and remember just picking the C# language spec and learning from it rather than any of the books at that time since all the books were so wordy/verbose that it just didn't make sense. Especially having learnt C from K&R.
I haven't looked lately at other language specs, and don't remember others, but at that time the C# language spec was very well written.
I really like C, but I also disagree with that sentiment. C/C++ should be used as minimally as possible. New projects should use something secure by default in 2021 unless they have a specific articulable need (i.e. not "I like C more" or "I don't know [alternative]").
C/C++ usage should fall into three categories:
- New OS and System Utilities (in particular for hardware with no other language support).
- Existing projects written in C/C++.
- Areas where all the resources and support are only currently in C/C++ (e.g. game development).
I'm glad fewer new developers are getting into C/C++. That will increase the costs and make companies less likely to pick it unless they absolutely must.
All the tips are very focused on how the code, APIs and even the languages evolve, trying to understand how your changes could confuse other developers. Compared to clean code, it's clear that it's written by someone who has done a lot of coding and seen the evolution, with a very pragmatic approach. Not just theoretical like Clean Code
My recommendation is to read the original papers/manuals (bitsavers and ACM/Sci-Hub are my main resources). Starting with how computers were programmed befor high level languages were developed (i.e. machine code and assembly), then going through the early languages: Fortran, Lisp, COBOL, Algol; and understand why they were developed and the main ideas in those languages. Lisp had a huge influence on later generations of functional programming languages; Algol (first developed in 1958) is the granddaddy of all what we call today C-like languages, including CPL, BCPL, B, C, Pascal, C++, Java, C#, etc. Simula (developed in the early 60s) is the granddaddy of most object-oriented languages, including Smalltalk, C++ and their descendants.
Many ideas that are core to modern programming languages were developed in those early formative years (late 50s, 60s, and 70s); e.g. lexical scoping, dynamic dispatch, coroutines, garbage collection, encapsulation, virtual machine bytecode, metaprogramming, and many others.
I find it fascinating to read this early literature and understand why and how those ideas (that still live to this day) were formed.
2. How to Design Programs
3. Software Design for Flexibility: How to Avoid Programming Yourself Into a Corner
FYI - The original was written in Scheme. There is a newer version based in python which I haven't tried.
Edit: The python version is highly contested. Scheme is the more difficult and therefore the best way to understand these principles.
Code by Charles Petzold - https://www.goodreads.com/en/book/show/44882.Code .
Others would be:
Neural Smithing ( its now obsolete but was great at the time ) https://www.goodreads.com/book/show/1153223.Neural_Smithing
The Pragmatic Programmer https://www.goodreads.com/en/book/show/4099.The_Pragmatic_Pr...
The Effective series by Scott Myers https://www.goodreads.com/series/160060-effective-c
Because the problem today is complexity and abstractions. It prevents us from changing code easily, deleting code easily, and understanding the full program flow easily.
Yeah I find these are normally the books I want now, but it doesn’t take that many to suddenly turn my cart into $1k.
https://www.amazon.com/Understanding-Software-Kanat-Alexande...
For helping realize that in all the books telling me how to write good code, explaining language constructs, and working as a software developer, none of them ever made it clear to me that programmers spend less than half their time writing new code from scratch. For showing me that programming involves revising and improving far more than opening up an editor to a new file in an empty repo.
Did not agree with everything but it was excellent.
https://archive.org/details/pdfy-MgN0H1joIoDVoIC7
Best as in best written, along with K&R—Brian Kernighan co-authoring both can't be an accident!—it's just a pleasure to read. I use it as a model when writing documentation myself. They get you started using AWK literally on page 1. Later they get into the details of particular use cases—profiling, making DSL interpreters/compilers, random text generation, making indexes, a graph-drawing language, databases, data validation etc etc. All in under 200 pages!
And best as in most useful—I use AWK every day for all kinds of things–web scraping, rearranging and creating data for programs, meta-programming etc. So easy to make whatever tool's needed for a job.
One thing about the book is that it’s a lot more interesting than what a cursory scan of the table of contents would suggest. An O(log n) algorithm for multiplication doesn’t seem interesting at first. But the authors do an amazing job of starting from familiar ideas and building up to surprisingly beautiful and elegant ideas.
I think I’m finally able to grok c++ templates half way through this book.
One unfortunate downside to this book is that the authors wrote this before concepts were introduced in c++20. I would love to see an updated edition of this book that use the real c++20 concepts. However, this doesn’t diminish my recommendation for this book.
[0] https://www.fm2gp.com/slides/FM2GP_Course_Slides_Pt1.pdf
I suppose you can learn about the power of generic programming and apply it to another language. There is probably some non-zero amount of things that you can pick up from this book that you can apply elsewhere. However, I don't know if that is enough to justify going through this book. Your milage might vary.
Among its memorable conceits: debugging as a life-improvement strategy, the weirdly mesmerizing properties of randomness, adversarial cat-and-mouse games that have transpired as a result of dueling software programs. He's a gifted writer and one of the few to consider programming as somewhat spiritually connected to the question of what it means to be a human. (In addition to his literary credentials, the writer is a former technical lead at Microsoft and Google.)
Hon. mentions: HtDP and accompanying Simple Data and Complex Data courses on edX; Part I of Sedgewick & Wayne's Computer Science book and accompanying booksite and free Coursera course
For many years we gave this book to all new employees on day #1. Even the most experienced developers will find something in this book they will find very useful and it will help you to take a step back and evaluate your programming. This book is true gold mine.
Most informative - Effective Java
Funniest - Learn You a Haskell for Great Good!
Best written - Eloquent Ruby
Most useful - Data Modeling Essentials
And "Compiler design in C", also by him
2. Practical Common Lisp
3. A Programmer’s Introduction to Mathematics
4. Data Structures and Programming Design in C
5. The Art of Agent Oriented Modeling
The best lessons I've learned is how to balance all these good ideas for each problem, idea, implementation. How do do OO without lots of racy mutable state, using immutability efficiently, composing pure functions, identifying what to abstract explicitly vs allowing something to permeate, intention and priority when separating factors/aspects, good naming patterns and when to use which. I don't know of a book that tells you how to find balance.