3 ms·
Sigh. This is a rather myopic view of documentation. Of course the source code is the ultimate arbiter of truth. But having a few roadmaps to that source code
by groby_b 15y ago
Sigh. This is a rather myopic view of documentation.
Of course the source code is the ultimate arbiter of truth. But having a few roadmaps to that source code is _incredibly_ valuable. And as long as the underlying code does "what it says on the box", there's no reason to read the code.
Reading your stack's source should be a last recourse, not the default mode of operation. (Yes, I do read source code of my stack. Plenty of it. Which is why I appreciate any occasion where I don't have to.)
And when I see his "brilliant HN post" mention that suggests that "sometimes, you recompile your compiler", I'd like to smack some sense into people. You really don't. I've been working on low-level software for a loooong time, and I find about one compiler bug a year. I even do have a bit of a background in compiler writing. And yet, the sane choice is to write a small repro case, file it with the maintainers, and write your code to work around that bug, at least in most cases.
- brianpan 15y agoI didn't read source as the "default mode of operation", but rather a necessary fallback that you 1) shouldn't shy away from and 2) you should demand lest you be unable to access the ultimate truth of what you're building on top of. I definitely see a hallmark of experienced/skilled coders as not being afraid to follow the trail of code farther than I sometimes have patience for.
- groby_b 15y agoIt's a very thin line to walk. I know I've spent days reading Linux or Mach sources when I could just have coded around the issue, and I wouldn't list that as something that makes me a skilled coder. It just means for me sometimes shiny outweighs expedient ;)