Try reading the manual for Boto3 and writing code blind without being sure of the response format without just calling it first and looking at the response.
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.
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?
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?
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.
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.
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.)
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.