[jchw]

This may surprise you, but I don't use Python or boto3. Last time I used either of those was nearly half a decade ago. Software I use nowadays generally has much better documentation, not to mention is written in a language where I can get code completions and accurate typings.

Also, I never said that I don't read the source code of third party libraries. In fact, I do. I like to embed third party libraries directly so that I can inspect them inside of my workspace. For almost any library that I use, though, it hardly requires much familiarity to get basic operations working. Since a good amount of the libraries I use at my day job are proprietary, I can't just google for Stack Overflow questions and sometimes documentation isn't always available, so it would be pretty debilitating if I needed a debugger just for the simple task of utilizing a library.

This is also part of why I stopped using Python. MyPy shows promise, but without typings at least on par with TypeScript, my productivity in Python was surprisingly poor despite amazing frameworks like Django and DRF. Simply put, there was almost always too much futzing around, and even with many debugging techniques I sometimes never fully figured out what was wrong with my code.

[scarface74]

I used Boto3 as a large complex library that you aren’t going to inspect every line of code. But you mentioned web development, so you inspect every single line of every third party dependency? Every library?

[jchw]

Nope, just when necessary; usually I don’t read very much of the code. Intuition, comments, unit testing and editor help does the rest.

Well designed APIs are self explanatory.

[scarface74]

So I just showed you a massive API could you use your intuition,comments, etc to figure out the response? Are you claiming that any API that you can’t understand through “intuition” is by definition not well defined?

Have you ever integrated with something like Workday?

[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.

[stock_toaster]

What languages (and industry) do you work in these days? Genuinely curious.

[jchw]

For the most part, C++, Go, TypeScript. At work I mostly write (micro) services or web UIs, and at home I do whatever (Tetris clones, small studying apps, utilities for reverse engineering, I’ve even done a couple Gameboy emulators in Go.)