Debuggers implement this but better. You can place a conditional breakpoint containing your code checks, and when execution stops you have access automatically to all the scope you could possibly use to print your output statements without having to write any. You are also free to still think carefully while using a debugger.
No. You're misrepresentating or misunderstanding the claim.
It is not about debugging. It is about program design. If you need to step through execution in order to understand and reason about iit then your design is too complex.
It is not a claim that print and conditionals are better debugging techniques. It is a claim that having those critical points in execution making assertions and logging warnings is a more productive alternative which precludes debugging in the first place.
> have access automatically to all the scope you could possibly use to print your output statements without having to write any.
If youre in a context where you need this level of access to the state scope you have a ball of mud that needs to be decomposed. You should know what state you have by the failure mode or the failing test at hand.
Using a debugger only makes sense if you're dealing with a mess. Fix the mess don't build tools to work with it.
> You are also free to still think carefully while using a debugger.
Yes but again, if you need a debugger it goes to show you don't think carefully very often so maybe telling me you can with a debugger is kind of aoot point when I know you won't.
I'm sorry but this reasoning sounds like elitist rubbish to me, like trying to turn a completely subjective workflow step into a universal law ;)
It's not about a "need to step through because your code is too complex", more about validating the code you just wrote, whether it still "feels right" after it has been dumped from your mental model into actual code.
You may have carefully thought about your program for hours before typing the first line of code, but usually such a splendid plan doesn't survive the first written line. Maybe the super-intuitive API you thought about doesn't quite feel that great in practice, maybe in the end you still didn't think "hard enough" about some problem. Spending time in the debugger to think about solutions is usually better than "just thinking hard" about solving the problem, because you have more data, and can tinker with potential solutions, and finally figure out which of the potential solutions feels best.
It's the same reason you're using a profiler for performance optimization, not just thinking about how to make the code faster (of course that needs to happen too, but it's not enough).
This sort of "validation debugging" in a tight edit-debug loop requires that the debugger runs in the same environment as the source code editor. It must be possible to switch between editing and debugging (and running to the location you edited) in under a second.
You've repeated AP's failing this isn't a workflow nor a replacement replacement debugging concept. It is a design paradigm that lessens the need for heavy weight debugging.
Debugging still has its usecases. I, like others, just see it as an infrequently required tool when most systems when properly composed simply lack the complexity required to make them useful.
> It's not about a "need to step through because your code is too complex", more about validating the code you just wrote, whether it still "feels right" after it has been dumped from your mental model into actual code.
Debuggers are for debugging. Not development.
It's not a rule without excception but in the general sense I would be very concerned to see a developer using the debugger on a daily basis especially if they're using it for state validation.
Like what are you validating that your tests aren't? Why aren't your tests validating it?
The need for a debugger is a symptom of a sick system. I have never required a debugger on a healthy system.
I've used them on healthy systems for more complex problem sets but by and large I only reach for them when someone has done something appalling.
> Like what are you validating that your tests aren't? Why aren't your tests validating it?
Your tests are probing your code on a narrow range of inputs (or if you're using something like property testing, potentially a larger but still finite range) drawn from the valid state space that is almost always too large to actually verify. They're also themselves pieces of code that itself can have bugs. Formal methods can prove properties about code, but usually w/ a much larger investment of time.
> The need for a debugger is a symptom of a sick system. I have never required a debugger on a healthy system.
I think people who say stuff like this are probably a little in denial about how many bugs they've actually written and how difficult it is to get any kind of certainty about the correctness of their code. Programmers write bugs, why are we policing the tools they use to fix them?
> Your tests are probing your code on a narrow range of inputs drawn from the valid state space that is almost always too large to actually verify.
You don't need to verify all inputs with mathematical certainty. You're writing the code some reasonable shortcuts can be made, some basic understanding of what bugs happen and what kinds of tests provide the best ROI gets you > 80% of the way there.
> They're also themselves pieces of code that itself can have bugs.
No, they are tests, bugs in test code are incredibly hard to produce if you are practicing test first development.
Most real bugs that make it into production are from conditional flows that are not being covered by tests.
> I think people who say stuff like this are probably a little in denial about how many bugs they've actually written
No denial, I know I've written a bug before.
> and how difficult it is to get any kind of certainty about the correctness of their code
Nope, not in denial about this either, I find it relatively easy. Maybe I just don't do a lot of rocket science or something.
> Programmers write bugs, why are we policing the tools they use to fix them?
> Like what are you validating that your tests aren't? Why aren't your tests validating it?
I use use a debugger fairly regularly when I'm writing tests. Debuggers are for moments of incredulity. When a test doesn't behave as I expect, I go back and look at my code. I'll look back and forth, and if I still don't see the root cause, then I'll fire go up gdb instead of adding print statements. Debugging a unit test is often way faster than recompiling.
> Using a debugger only makes sense if you're dealing with a mess. Fix the mess don't build tools to work with it.
I have long thought if I was unable to use a good IDE debugger I would just change careers. Why? Because often I make the wrong assumption about the data that library or 3rd party functions will return. It is not until I can actually see the data that I realize my assumptions were wrong.
Using a debugger is all about learning, and debuggers make learning faster.
I am often able to code rings around my peers on projects. And I believe the reason is not because I am better or smarter but because I use a good IDE and debugger. And they don't.
