Are you also avoiding debuggers? If so, why? What makes debugging so tedious?
I use Jetbrains tools and have an easy time debugging in Java, Python and Javascript. In Java I'd say that you can use unit tests to interactively experiment the same way people do with the CLI in Python with the difference that you get unit tests out of the deal as opposed to having lines scroll away in the console.
I use WebStorm to debug Javascript programs that run in npm but if it is running in the browser I just use the "developer tools" from Firefox, Chrome, Edge or Safari. I think there is some way to attach WebStorm to a running web browser but I've never figured it completely out.
I think the Unix culture is allergic to debugging. It's not that hard to use gdb from the command line and in fact you can do some pretty awesome things with it such as embedded system debugging or debugging the C++ and Java sides of an application at the same time, but for a long time I kept trying graphical front ends for gdb such as ddd that "just don't work".
It’s not just Unix culture that’s allergic to debugging, it’s every chancer and charlatan the world over.
Back in the days when I didn't use one, it was a miserable developer experience. Thanks to Go and his great decision of having unit testing built into their standard now writing tests and debugging them is a joy.
Far are the days of not using a debugger because the programing language of choice didn't treat debuggers/unit testing as a first-class citizen. I could say that now I sleep a lot better thanks to coding my backends on Go and having the confidence that I can go as much depth as I want to fix any bug.
Debugging for me is an automatic action like drinking water when you're thirsty; two clicks (set breakpoint and click the debug button) and I'm back into the debugger, again.
You put a "print" statement dumping whatever data structure you want, you run the program again, and voila you got something. Now, the "where to put the print" is an art on itself of course. If you don't know where to put it, then either you start writing multiple "print"s here and there (following an approach similar to binary search) or you use a debugger and go step by step until you find right place to inspect.
The problem with debuggers is that they do not work out of the box. If you use the terminal, then you have use an external program and read its manual to understand how to debug, how to put breaks. Depending on the platform you are using, you may require even an executable to run the debugger on. Sometimes you don't have an executable. Sometimes you don't know where the "entry" point of your program is, but you know where the bug relies. Some debuggers require you to point the debugger to the entry point.
If you use an IDE like Jetbrains', then for debugging you need as well to do some (minimal) setup as well (the last week I had to debug a Node.js program: it was simple, but it didn't work out of the box. Also, when I open my IDE on a different Node.js repository, my debugging setup was gone).
First, if you can fix most issues with a glance or a brief stare, using a debugger never really feels necessary. It may also feel less like using your own brain and solving a puzzle, and puzzle-solving is a huge part of human psychology (see post title).
Also, the story of the last N years has been the text editor, not the IDE. The IDE and its world is really where the integrated debugging story is a big deal.
But if you are using a text editor--or text editors--integrating debugging is less of a thing. Your time may be better spent with various productivity-focused changes for ergonomics, like studying or changing keyboard shortcuts, installing or writing plugins, setting up your own scaffolding using system tools integration, and so on.
Plus once you know the various shortcuts, it's maybe more fun to use them and zip around adding prints than it is to debug. You also gain practice this way, after all.
But if you moved from text editors to IDEs, IMO you probably brought that same set of practices along.
Anyway, good q, I've thought about this recently as well.
Sometimes you don't know what you don't know.
But yeah, these days I rely on the debugger heavily. Even for Python :)
Right now I'm writing some stuff which takes over the terminal and works in recursive loops (ncurses roguelike map generator) so print debugging is a hassle. It's actually quicker to use a debugger.
I find that attaching gdb and running "bt" and "info locals" or inspecting variables with "p" is much cleaner than printing, and helps me visualise what the code is doing much better.
This use of a debugger for "little things" is immensely helpful for when I need to use a debugger at work to solve "big things", which are usually remotely and after-the-fact with a core file, so printing isn't even an option there.
As to why they are a last resort. For me it was just having to learn the debugger and also setting up the debugging environment. For every binary needs to be built with debugging symbols and any libraries you're wanting to step through you have to find the symbols for those too.
Also I think it depends on how low level the language and what kind of program it is.
Some languages/environment don't have debuggers or they aren't very good. I wouldn't say most debuggers that are mature are super great to use either.
Could you give some examples or languages/environments with "bad" debuggers?
The Chromium Project can be way too slow to run in a debugger. Even just debugging the Content Shell can be very slow.
The code I write is also a lot more asynchronous nowadays, and debuggers are fairly worthless for async code imo. Pausing on a breakpoint conceals issues with asynchronous timing that good logging will show immediately.
I still believe debuggers should be a part of every developers toolkit, but like anything else, pick the tool for the job and sometimes print statements are just the easiest and fastest. Actually in a lot of cases.
I often find it a lot faster to set up breakpoints and fire up the debugger than to write debug statements. At least in some IDEs, breakpoints are a single click each, and if you have to restart the application/module/whatever anyway, doing that in a debugger instead of a non-debug run is also just a click. I can then inspect any variable values at the breakpoint instead of having to explicitly include all potentially interesting ones in the debug output.
When I'm trying to figure out a problem in code I'm writing rather than one in production, the debugger is often my first resort.
I'm mostly writing plain old backend code without asynchronicity, though.
Debug output (at a reasonable level) is still useful even outside of asynchronous program flow, of course, because it might give immediate clues for problems encountered in testing or production. If you don't have a good idea of where to look, debug output from several places might also be nicer than having the program stop at lots of breakpoints that turn out to not be useful.
I have the exact opposite opinion. Firing up the debugger is what you do when you no longer know where to look, because you need it to examine the whole program state and have the ability to step through. Writing a console log with output from a variable is the precise "I already know what the problem is, all I'm doing is verifying it" approach.
> if you have to restart the application/module/whatever anyway, doing that in a debugger instead of a non-debug run is also just a click
A click that spawns a process that takes 10x longer to spin up. Debuggers are slow and heavy.
If you force yourself to use the debugger more, you will in the process both familiarise yourself with it and iron out any configuration kinks. Learn those keyboard shortcuts, figure out how to make it autoconnect and break on exceptions, find out how to evaluate expressions on the fly, …
You + That tool = maybe goodness. Maybe not.
I also do a lot of web stuff, and if you're running some server process and you're not running the server process through a debugger directly, then you need to find and attach to the server PID, etc., then maybe deal with threads, and it's just a lot of upfront effort when I could just find the issue by throwing a puts/print somewhere or writing a test.
I'm not anti-debugger, I'm just busy and it's easier to put something in my code (which is how I frequently jump into debuggers too, e.g. binding.irb, binding.pry, debugger, byebug, etc.)
the CLI debuggers (gdb, lldb, etc.) are great when I really need them, but they're a pain in the ass to setup with things that are not C or C++, editor integrations sometimes need setup, and using them without setting breakpoints visually is tedious.
I'd have a really hard time respecting someone's choice to bet on a tool that is very difficult to troubleshoot, if there's an alternative that isn't, unless that tool is extremely better at something else.
I'll give it another crack because I have just started a new job (new machine, new PHP, new everything) but I have my doubts it will work this time, either.
Setting up debugging for PHP has got to get a whole lot easier and user-friendly, IMO.
I do use a lot of analysis tools like Valgrind which imho are way more useful than debuggers. Linters and static analysis tools can also be really useful for early bug detection.
Other than that, debuggers are very superior to print statements and such. You can’t pause a print statement and inspect the objects you didn’t print!
Would you be willing to use one of those?
This may also contain further pointers that I missed: https://softwareengineering.stackexchange.com/questions/1815...
I looked through there; I code in Python for work (Lua at home a lot), so I didn't see anything that seemed to be targeted towards that use case. I've also seen tools like rr that record a session, but I specifically want to be able to step back and forth while executing code. I would use anything that, at minimum, would allow me to set a "save point" like a breakpoint and then return to that save point from any breakpoint, or from paused execution if I am stepping through the code.
I think it would be easier for Python, Lua, or other dynamic, interpreted languages to do this because you could store the program state via storing the interpreter's internal state more easily.
Also, I understand side-effects would complicate this and I am willing to ignore those issues if I had a bare-bones reversible debugger for Python.
I know that "remote debugging" is a thing, but I would need to talk with our network guys about firewall exceptions to allow me to connect to the Kubernetes pod over port XYZ. That sounds like a hassle, and I'm not sure they'd allow it.
I would guess that it also supports debugging.
(Thanks also to matthias247, who also suggested this.)
One nice property of asserts is that they keep working even when your attention is elsewhere.
If I don't understand what is happening to data without stepping, the code is too complicated.
If it's too complicated, I don't understand it now, won't understand it later, and it's probably wrong.
If I was working (again) in embedded systems, I might use a debugger as a substitute for print.
t. Grumpy maintainer
TLDR: He doesn't understand why a lot of SV big-tech companies are hostile to debuggers.
Learning and effectively using a debugger can require as much cognitive load as programming itself.
Given that, using a debugger takes you out of your programming mindset and into debugger mindset. Using prints, asserts, etc. keeps you in programming mindset, so you can find and fix the problem and get back to coding without the need for cognitive gearshifting.
Personally, I think "too much" is when you get a large table of all variables and their values; it is quite hard to locate the one you care about...