Ask HN: What language-agnostic programming books should I read?
Until now I've read:
- The Healthy Programmer
- Clean Code
- Test-Driven Development by Example
What should I add to my library?
- The Healthy Programmer
- Clean Code
- Test-Driven Development by Example
What should I add to my library?
343 comments
[ 3.9 ms ] story [ 167 ms ] threadImplementing Domain Driven Design
So - good book, but not for this purpose.
- Code Complete by Steve McConnell
- The Effective Engineer by Edmond Lau
- The Pragmatic Programmer by Andrew Hunt and David Thomas
It has good parts. But it has some very bad parts too, when it reinforces myths that, IMO, are very wrong (e.g.: cone of uncertainty, X times better programmer, etc).
I'd recommend to read it with care.
> - The Pragmatic Programmer by Andrew Hunt and David Thomas
After many years I still read parts of it, again and again. And I still like it.
It covers some really foundational concepts like idempotency which programmers don't often think about when architecting systems.
I have attempted some of the problems in Lua, Python, Erlang and Ada. It is very doable. So not just for Scheme.
If you don’t know much about hardware (and maybe even if you do) it’ll change the way you think about computing devices.
The concepts and terminology are absolutely invaluable to understand, but you can pick those up other ways.
It's an old book but the most eye-opening one to me.
Still a worthy topic, still worth your time. As was mentioned about 'The Pragmatic Programmer', I think reading this works best once you have a few years of experience.
But programmers haven't changed much since then. You'll recognize all the weirdness in software work.
http://thinking-forth.sourceforge.net/
Teaches you to think simple and elegant.
The algorithms are explained, and demonstrated (in java). But with the knowledge of how the algorithm works you should be able to use them in another language.
(And even though henrik_w already mentioned it, Code Complete2 is a really good book to read!)
https://www.coursera.org/learn/algorithms-part1
Any examples of books focused on that? I can't think of any.
Motulsky's Intuitive Biostatistics - this one goes over all the usual methods used in science from distributions to t-test to ANOVA to regressions etc., the basics, but doesn't introduce the maths (you use R for that) but the assumptions and pitfalls of all of those methods.
Statistics Done Wrong: The Woefully Complete Guide - this is all the stuff that's going wrong in applied statistics, a bit short but enlightening
Discovering Statistics Using R - a whopper of a book (~1000 pages?), it goes through everything while also being funny (the constant humor may not be for everyone). Graphs, correlations, regressions, all the MLMs and GLMs, linear models etc. pp., their assumptions, how to run them in R, how to interpret R's sometimes annoying output, etc. pp. Like Motulsky's, but wayyyyy more in-depth on the language's specifics.
Naked Statistics - an intro to stats for laypeople with a focus on politics/economics, good for interpreting and assessing daily news
I here assume your source code will be read by others; or by yourself after more than three months has passed.
If you want this sort of thing, read a well-respected publication's style guide (e.g., from the AP, NYT or Economist).
http://aosabook.org/en/index.html
Titles :
Any language worth learning has this property of influencing the way you think forever. TDD, Code Complete &co are all very integrated into mainstream industry and are no longer novel. If you find yourself needing to recommend your colleagues to read Code Complete you might consider working on the skills to get a better job.
I'd also recommend The Linux Programming Interface by Michael Kerrisk as it teaches so much about what makes modern Unix what it is but.. it's arguably quite oriented around C by necessity. It's not a "C book" by any means though.
https://en.wikipedia.org/wiki/Jon_Bentley_(computer_scientis...
2004 is old now? Really?
Honestly, good books don't age as long as their core domain stays valid. Structurally C++ is pretty much the same as when the book came out.
It was written for a different type of developer and a different type of development environment and a specific language, C++.
You haven't looked at C++ lately if you think it's the same as it was in 2004. The ISO has released new versions of the language in 2011, 2014 and ratified a new standard here in 2017. If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++.
Edit:
Modern C++ contains native support for the filesystem, threads, lambda expressions, variants, upcoming networking library, coroutines (at least in Visual Studio), no more new/delete memory management, parallel algorithms and a ton more. This is a completely different language now and the code you write looks nothing like 2004 C++ code.
Just about all of these things were around in 2004.
"If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++."
I applaud your attempt at an authoritative voice. But you focus on mostly technical trivia that are thin scaffolding on top of the language. I agree modern C++ is nice but it's the same language still.
"This is a completely different language now and the code you write looks nothing like 2004 C++ code."
Are you trolling? This reads like a transcript from a TV commercial.
> I agree modern C++ is nice but it's the same language still.
Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.
I would say generally C++ style has evolved through last decades with people understanding class based architecture as an antipattern and data pipelines based on preferably immutable data as the more robust and understandable approach. This has nothing to do with language standards or 'idiomatic' constructs - both can be expressed as perfectly elegant C++, using the '98 or '11 or '17 variant.
But anyway, within this context - refactoring old code - I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++. This is the main reason I find the claim of methods to understand circa 2004 C++ to be outdated to be silly.
That's never been the way that I've read it, and it's not how I meant it. New language constructs allow for more-natural ways for the code to express the intent of the programmer, replacing the use of older constructs in the places that they were clumsy.
The entire point is to make the language more practical. Patterns of use in a language aren't idiomatic because of dogma (or at least, they shouldn't be). They're idiomatic because they're a clear and elegant way (or at least the most elegant way available) to implement something.
> I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++.
Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017.
Well, if the original code is of the worst kind of a mess, Feather's circa 2004 collection of methods to make it more understandable but functionally the same work just fine for the first part of the refactoring. In my experience this is the most difficult part as well. To what dialect of the language the code is ported after it is understandable, is a relatively trivial syntax transform after this.
I speak from experience from having recently had to implement features to a production codebase with millions of lines of code, some of which date back to Fortran, and that took the final step of evolving into C++ sometimes in the late 90's.
I prefer the definition of legacy code that it's any code that does not have unit tests. In this case every transformation to a production codebase needs to retain the original behavior - without exact understanding what that behavior is.
I think this comment should have been my original response to this thread instead of the relatively cheeky responses I wrote earlier.
That statement alone, one of the sections of the book, recommending you to allow the compiler to find your errors for you, is an example of the "age" of the book.
At the time I read it, when it first came out, I loved it. I still love Michael's work and advice to this day, but this book was written for another time.
And also it seems to be something lots of programmers don't realize for some reason - many times I had to instruct people to crank up their compiler warning settings and actually read them. Especially in C-land, I can't count the number of times I solved someone's problem by appending -Wall to the gcc invocation and telling them to come back after they fixed all the warnings...
The IDE space has improved a lot since 2004, eg. Jetbrains' tools around refactoring and code cleanup suggestions, make things super simple.
Don't get me wrong, I've read this book, multiple times, it's on my bookshelf and think it's a great book, but it was written when the state of development was a much different landscape, IMO.
And Fred Brookes' book is over 30 and sadly just as relevant.
https://www.manning.com/books/dependency-injection-in-dot-ne...
Implementing Domain Driven Design by Vaughn Vernon
Clean Code by Robert Martin
I think you will find some code in all of the books but the ideas are applicable almost everywhere.
This is one of the few truly language agnostic books on programming. SICP is close, but it is limited in relevance at times due to the limitations of a particular language (Scheme).
From a blog post ( http://the-whiteboard.github.io/book/review/2016/02/17/five-... ) I wrote a bit ago...
---
The first thing that will come to mind when seeing that title is “ug, another book on patterns.” Or maybe “I thought it was named Design Patterns - Elements of Reusable Object-Oriented Software”
This isn’t anything like that book. Or maybe it should be. The full title of the book is A Pattern Language: Towns, Buildings, Construction. Yes, this is a book about architecture - but not software architecture. It is about the houses and buildings that we walk live and work in.
The description of A Pattern Language is one that will sound very familiar to people familiar with Design Patterns:
> It is shown [in The Timeless Way of Building], that towns and buildings will not become alive, unless they are made by all the people in society, and unless these people share a common pattern language, within which to make these buildings, and unless this common pattern language is alive itself.
> In this book we present one possible pattern language, of the kind called for in The Timeless Way. This language is extremely practical. It is a language that we have distilled from our own building and planning efforts over the last eight years. You can use it to work with your neighbors, to improve your town and neighborhood. You can use it to design a house for yourself, with your family; or to work with other people to design an office or a workshop or a public building like a school. And you can use it to guide you in the actual process of construction.
> The elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. This is the book that inspired Gamma, Helm, Johnson and Vissides.
By reading A Pattern Language you will be able to understand what the authors of Design Patterns were trying to do and how design patterns were intended to work.
It’s a good book too, who knows what else you will find useful in it. Pattern #146 describes a flexible office space. Pattern #148 describes a workspace for small work groups, #151 is about small meeting rooms, #152 is a half private office. Everyone who works in today’s world of computers and cubes, can use these ideas to conceptualize and consider improvements to the office.
*but be aware that he's a polarizing figure and opinions of his merits differ
(and if you happen to have a differing opinion, please use the reply button instead of the downvote button)
TAoUP is a good book on the Unix Philosophy, but it's worth noting that the ultimate expression of these ideas (Plan 9) was a failure, and the 'everything is a file' metaphor is arguably incorrect. I hope I didn't give the impression that it was not worth reading, especially in the sense that there are few other good sources for that information (even using Unix is not likely to teach you much about its whys and wherefores). I just think that it should be read in the proper context, and that recommendations should try to include that context.
And I'd bet that a lot of programmers wouldn't be working on and with Linux right now if they hadn't have read that book long ago.
Both of them changed my career path from Dos/Windows to Linux
Yes. TAOUP has a lot of good content about Unix programming styles and traditions, much of it useful generally. ESR's writing style is a bit heavy / verbose / uses verbal flourishes, but if you can let that not put you off, the book is worth reading. I've read most of it. One of the good sections is about Rules (of programming in Unix, which are not really rules, of course, but informal guidelines developed over many years of experience by many people - ESR has sort of codified them, a thing he tends to do a lot :)
The Rule about separating the interface from the implementation is a good one. I've seen developers at even enterprise companies sometimes not follow it in practice.
> - Parsing Techniques by Grune and Jacobs
Just saw that there is a new edition of this book:
https://dickgrune.com/Books/PTAPG_2nd_Edition/
It's about software engineering but also about hardware and some different kinds of design outside of IT.
From an interview about the book [2]:
> Eoin: Your new book does talk about software design in places, but it’s really about design generally, and the case studies span buildings, organizations, hardware and software. Who is the book aimed at? Are you still writing primarily for people who design software or are you writing for a broader audience?
> Fred: Definitely for a broader audience. I have been surprised that The Mythical Man-Month, aimed at software engineers, seems to have resonated with a broader audience. Even doctors and lawyers find it speaks to some of their team problems. So I aimed this one more broadly.
Brooks is also the author of The Mythical Man-Month which is often mentioned on HN.
[1]: http://www.informit.com/store/design-of-design-essays-from-a...
[2]: http://www.informit.com/articles/article.aspx?p=1600886
the bible / unknown author
the new testament / various
Refactoring
Patterns of enterprise architecture