[jchw]

Hell yeah I'm claiming APIs I have trouble understanding with intuition are not well designed. You might even call them... unintuitive. The entire point of an API is for it to be consumed; A nice uniform API like Stripe or Qt is easy even with minimal docs. If a user has trouble with your application, you don’t immediately blame them, you have a UX problem. If your API is hard to use? That’s a problem. This only becomes more true as the stakes get higher. How do you feel about unintuitive cryptography APIs?

Have I ever used an API that is hard to use and confusing? Yes. JIRA, Workfusion come to mind. The latter was a SOAP API. Thankfully, I don’t really need to deal with SOAP anymore, and good riddance. In case of bad APIs, my approach has always been to strongly isolate them from my code with an abstraction; most dramatically by actually putting a service up that just interfaces with the API I don’t like and provides a minimal interface to the functionality I need. At work, I usually have to do that, for security reasons, even if the API is good.

Anyways, I really, genuinely don’t have any clue what you’re trying to prove here. You’ve gone on and on about how bad APIs exist and imply this means I must be lying. So what do I have to do, link to some docs and say “Hey, check out how usable this API is”? I won't bother but the two aforementioned (Qt, Stripe) are great examples in two completely different categories.

And I have literally not even the smallest clue how this ties back to debuggers. I can’t recall a single time my reaction to a confusing API was pulling out a debugging tool other than printf; more likely I’d play around in a sandbox or REPL instead.

[scarface74]

No, what I am saying is that your definition of a bad API is one that you can’t intuit is a case of the “No True Scottsman” argument. The Boto3 API is well organized, it just covers a massive surface. It’s much easier just to call the API and inspect a real world response.

For instance, of course I know all of the databases instances in our AWS account, I read the Boto3 docs to see what API to call to return them, but it was much easier just to call the API and look at the response in the debugger to see the response than just guess from the documentation. The Boto3 module covers every single API for every service that AWS offers. Of course the API isn’t going to be consistent between S3 (storage) and DynamoDB (a no sql database).

And what’s the difference between using a REPL where you are running code line by line and using a debugger where you are running line by line?

On the other hand, why look through log files with print statements when you can just let the program run and set a breakpoint and look at the entire stars of your app including the call stack? But these days I wouldn’t even think about using a regular dumb text logger. I use structured logging framework that logs JSON to something like Mongo or ElasticSearch where I can use queries to search.

Heck even in my C days when I would make a mistake and overwrite the call stack, stepping through code and seeing where the call stack got corrupted was invaluable or seeing whether the compiler was actually using my register and inline hints by looking at the disassembly while the code was running.

[jchw]

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.

[scarface74]

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

I would actually say the opposite. If you’re littering your code with print statements and #if DEBUG equivalents (instead of using a debugger) and grepping log files (instead of using a structured logging library) you’re not using the newest tools available and you’re “debugging” in a way that I gave up in the mid 90s writing C and FORTRAN for DEC VAX and Stratus VOS mainframes.

There is nothing “modern” about littering your code with print statements. I thought being forced to do that in the 90s was already taking a step back from the various DOS based IDEs I had used by then.

[jchw]

The thing is, your imagination of what I’m doing (littering code with printf statements) and the actual reality of what I'm doing (solving AT LEAST 95% of my problems using extensive automated tests, strong linting, strict typechecking, and modern programming practices) is leagues apart. When I say I break out the debugger around every few months, I am not exaggerating. I may insert a printf or two once every other week. This is not the common case, it’s just significantly more common for me than attaching a debugger, because it’s quick and easy.

The practice I adhere to is to break code up into small modular bits then unit test the living hell out of those bits, then integration test larger combinations. Maintaining test code takes time, but I take it very seriously. I can’t share any of my actual work at Google but I can share my open source work; a project that I wrote this way is Restruct and it normally has around 98% line coverage. If someone finds a bug I add a new test. I have never used a debugger on Restruct or projects built on Restruct.

So then, what do I do all day? Console.log and printf everything? No, honestly no. I spend little of the day debugging because unit tests tell me nearly exactly what codepaths I broke, printing out helpful diffs of the expected behavior versus the actual behavior. This almost always gives way to the problem, even when I’m working on a brand new piece of code with tests I just wrote (sometimes before the code, even.)

So I would say printf is my goto debugging tool, but if I want to be accurate, it’s probably really automated testing. Automated testing used in this fashion basically acts as small little debug routines. We don’t call tests debugging tools though, because that would undermine their usefulness; they do so much more. Which is why I don’t sweat it when I have just as much or more test code than actual code; unlike other code, it often pays for itself if you do a good job.

And besides, if unit tests explain a bug to you before you actually run into it, did you really do any debugging or did you bypass it entirely?