undefined | Better HN

0 pointsjohndubchak8y ago0 comments

Me and a friend continually send IM's to each other, "LEAN ON THE COMPILER!".

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.

0 comments

TeMPOraL8y ago

I do not understand this. It seems like a perfectly good advice, and in fact it's what I'm doing every day - leaning on my compiler, and in Java world, on my IDE.

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...

johndubchakOP8y ago

My point was that with a modern IDE we can do that without resorting to a full compile, which can be burdensome with large codebases.

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.

biot8y ago

Leaning on incremental compile via a modern IDE is leaning on the compiler. The principle is the same, even if the implementation slightly differs.

j / k navigate · click thread line to collapse