3 ms·
I do too, I think this is more efficient when I understand what's going on. However, let's say I'm given a third party library, and I know essentially what it
by natural219 12y ago
I do too, I think this is more efficient when I understand what's going on.
However, let's say I'm given a third party library, and I know essentially what it does. I want to "see" the properties and methods of the object, I want to "inspect" values, and I want to "test" expressions, all at once. If you're just using printf, then between each of those steps you need to write a line of code, recompile, and reach that state in your program again. Like I said, if you already know essentially what's going on, deep dives like this become less and less important. However, I just think it's a boneheaded philosophy for a language / toolchain to just like...I don't know, assume you're good. I'm trying to become good, but I am getting more and more frustrated with Go every time the default answer to my problem is "be less of an idiot"
- mercurial 12y agoIt's not necessarily a matter of being good. Writing efficient code doesn't mean that you can build a mental model for a reasonably complex projects, which will naturally accumulate dependencies. If you're lucky, you'll get a mental model of the component you're working on, and some of the more problematic dependencies. That's where being able to dive into arbitrary code during execution becomes crucial. Especially if the problem occurs in a piece of code you don't have access to at the layer you operate, and hence can't display the value for easily, or at all.