Debuggers/inspectors are great, but they absolutely do not serve the same need as documentation, and any language/community that recommends the former in place

Debuggers/inspectors are great, but they absolutely do not serve the same need as documentation, and any language/community that recommends the former in place of the latter should be considered suspect as to the quality, reusability, and extensibility of its creations. > Why read docs when you have irb and can pretty much inspect everything you need? Because irb is another tool I have to learn how to use if I'm new to a language. Even if I already know the tool, I have to learn how to get the inspector to my code in order to inspect it in irb. That can be quite hard if I want to inspect an object that gets described and constructed during the runtime of a big "harness" I don't control. How do I get the inspector to run precisely where I need it to? In most situations like this, the code I want to inspect is itself running in a new process, or on a different server, so "just drop a breakpoint in", while possible, is far from easy advice to follow. And all that is assuming that the inspector's output, when I get it, will be at all useful! What if the code I want to inspect is highly dynamic, and has different object "shapes" at runtime depending on subtle differences in inputs? That kind of code isn't obscure in ruby land--I've seen common situations where inspection is at best a waste of time and at worst actively deceptive in Puppet, ActiveRecord, and various RSpec-ish frameworks. That's not to say their code is bad; just that it's a really bad idea to assume that a inspector can double as a documentation authority. The alternative--textual documentation--is absolutely essential and cannot be replaced with a debugger/inspector. I already know how to read English (or doc-language-of-choice). To read documentation, I don't need to learn a new tool (designed for prototype testing and debugging; probably not the first concerns on my mind if I'm at the "check the documentation/API reference" phase of development), carefully construct a contrived runtime context to reach my code, extrapolate the output as intended for the runtime back into something human-intelligible, and then pray that what I found is the right output, or is in any way representative of what my code is going to actually encounter when it runs.