I'm amazed at the amount of worshipping (in the comments) of luddites when it comes to debuggers. Citing Linus, Log4J developers ("use logging instead"), Kernig

I'm amazed at the amount of worshipping (in the comments) of luddites when it comes to debuggers. Citing Linus, Log4J developers ("use logging instead"), Kernighan and Pike... especially the latter two had learned programming and used computers that were orders of magnitude less capable than today's computers thus being able to run orders of magnitude less complex programs thus more readily understandable by humans. It's always the two polarities: understanding the program vs focusing on tiny details of the bigger picture. For me, the debugger is THE tool for understanding the bigger picture! Example of a concrete problem that I solved with a debugger today: I was populating a list in the UI, yet the elements were constantly disappearing. Why were they disappearing? It's a JavaFX where the UI elements are bound to observable lists.. So I put a change listener on the list and a breakpoint inside it. The breakpoint had been hit a couple of times and one of these times I saw a piece of my code in a remote location [1] that was clearing the list! Root cause found, problem solved. EDIT: could I have logged the stack trace rather than using a breakpoint? Yes, but the stack trace printout is far less actionable (harder to pinpoint something interesting, can't inspect variables, etc.) than an interactive stack trace in the IDE while the program is suspended. [1] Why remote location? The UI is the frontend that communicates with a backend. The UI is rather strongly separated from the backend bridge; the bridge also runs in separate threads. So the bridge takes care of the back-end, receives messages and interprets them and updates the elements (data model) observable from the UI. So my impression is that people who talk down debuggers simply haven't learned how to use them effectively.