If I would write down every bug I produced I would have filled a decently sized book by now. But debugging has some additional functions. If you interface your

If I would write down every bug I produced I would have filled a decently sized book by now. But debugging has some additional functions. If you interface your standard wep-api, you might want to take a look at the response. Yes, you could do that without a debugger, but I would argue it is more convinient. That expands to anything that is a blackbox to you. Stopping execution and taking a look at the state of the program is a decent tool I would not want to miss. In some languages you have an insane amount of dependencies and you need something to evaluate the behavior of those submodules. For pure algorithmic and determinist programs the statement of Dijekstra is true, but you often don't have it in reality. A server sending you garbled responses might garble you program too. You also become blind to your own code. You think it does something that isn't reflected in code. You think this regex certainly matches the input, but it just doesn't because you forgot something. Reading again might not help.