It’s like Java Hello World, or Python urllib. I want to do some basic operations in S3 and I’m knee deep doing all kinds of non-sense boilerplate with boto. This is not a knock on Amazon; I later used their official Go SDK and it was great. The API surface is absolutely enormous, so I don't buy the handwaving that big APIs are by nature incomprehensible.

I also don’t really get the framing that this is a No True Scottsman argument. I’m saying if someone has trouble using your API, and that problem is not a matter of the developer not understanding a core concept, it is a problem with your API. The counter argument is basically “My API doesn’t suck, it’s the developers that are stupid.” And no, a valid retort is not “what if they are, though?”

I dont consider a REPL to be a debugger. It’s just another code sandbox. You may consider it in the realm of ‘debugging tools’ but I do not. The difference for me is I hit sandbox tools like Go Playground and the Python REPL before I have code to debug, not after.

Anyway, this has now evolved to the point where we’re personifying APIs and stretching the definition of a debugger. I never claimed I do not printf debug, or use a REPL; hell, occasionally, every few months, I even use a real debugger. My claim is not even that I am a good programmer, which I would agree I am not. I am literally claiming that my use of debuggers (not necessarily all debug tools) has declined to very low levels because of better developer tools, better intuition ( = coding a lot, not necessarily being ‘good,’) and honesty, just having too many environments to actually learn how to use debuggers in all of them.

Having to use a debugger in C because you overwrote the call stack is an example of why debuggers can be an anti-pattern. You had to do so much work because the compiler couldn’t prevent you from making the simple mistake of an out of bounds memory access. Is a debugger useful here? Absolutely. Is it ideal? Hell no. I don’t want to be the Sherlock Holmes of core dumps, I want all of my mistakes illuminated as early as possible, so I can get back to work. I am not yet a huge Rust zealot, but you can see where I’m going with this. Does accidentally overwriting the stack in C have anything to do with bad APIs? Maybe. There’s plenty of C library functions and POSIX functions that are not invalid or broken in any way - in fact they behave exactly as described - but are incredibly common sources of memory and concurrency bugs. It’s why Microsoft compilers crap themselves with warnings whenever you use functions like strcat. I’m not sure I believe that the “secure CRT” versions are always much better, but the original API is terrible. C++ can do a fair bit better with strings and memory management when used responsibly. Obviously Go does a lot better, and Rust does even better than that.

So I don’t often use a debugger because a lot of the scenarios like that where I might have been reduced greatly, again, by better tools, better testing, etc etc. The fact that I have to defend this so rigorously makes me wonder if you are taking advantage of modern tools and testing standards that makes development work flow so much easier. Not everyone practically can; I imagine there are many fields of work where the tools or the ecosystem is behind, but I do not believe it is something that can’t or won’t be fixed, and if that’s the case I sure hope it does.