Debuggers exist in the terminal, in vim, and in emacs.
Why would you want a GUI debugger?
Honestly, I consider myself pretty comfortable with the terminal and vim and whatnot, but I've never been able to get into using GDB. For me I feel like a debugger is one of those things that's just so much better as a proper GUI.
Huh, this must really be a personal taste things, because I only want the debug info I specifically request to be printed on the next line. But I can imagine wanting a different interface to it.
I can't do it either. Something about typing commands that have some kind of grammar and pressing Return to submit each one for consideration just throws me off. Don't make me think. Thinking is typically what got the code into this mess in the first place - whether too much of it or too little, it doesn't really matter. Time to try some other approach.
Can see all your source code while you're debugging. And it's not like emacs where your termcap is 99.99% right which means it is 0.01% wrong. (Mac-ers get made when something is 1px out of place, in Linux culture they'll close a bug report if the window is 15000 px to the left of the screen and invisible because it's just some little fit and finish thing)
Having the code, the callstack, locals, your watched variables and expressions, the threads, memory, breakpoints and machine code and registers if needed available at a glance? As well as being able to dig deeper into data structures just by clicking on them. Why wouldn't you want that? A good GUI debugger is a dashboard showing the state of your program in a manner that is impossible to replicate in a CLI or a TUI interface.
Re:The Grug Brained Developer (2022)
by fingerlocks on Wednesday June 18, 2025 @04:58PM
(#44313232)
You get all of that in the terminal debugger. That’s why dwarf files exist.
All the information is there, but the presentation isn't. You have to keep querying it while you're debugging. Sure, there are TUI debuggers that are more like GUI debuggers. Except that they are worse at everything compared to a GUI debugger.
Re:The Grug Brained Developer (2022)
by fingerlocks on Wednesday June 18, 2025 @06:42PM
(#44313918)
I don’t know what debugger you’ve used but the entire query command is `f v` in lldb for the current stack frame
Yes, but in a GUI debugger the stack and everything else is available all the time and you don't have to enter commands to see what the state is. It even highlights changes as you step. It's just so plainly superior to any terminal solution.
I don’t disagree that a visual debugger made with a proper GUI toolkit is better than a TUI. However, nvim-dap-ui[0] does a pretty good job.
I didn't really get into debuggers until (1) I was firmly in Windows, where you expect the GUI to work and the LI to be busted, and (2) I'd been burned too many times by adding debugging printfs() that got checked into version control and caused trouble.
Since then I've had some adventures with CLI debuggers, such as using gdb to debug another gdb, using both jdb and gdb on the same process at the same time to debug a Java/C++ system, automating gdb, etc. But there is the thing, as you say, is that there is usually some investment required to get the debugger working for a particular system.
With a good IDE I think Junit + debugging gives an experience in Java similar to using the REPL in a language like Python in that you can write some code that is experimental and experiment it, but in this case the code doesn't just scroll out of the terminal but ultimately gets checked in as a unit test.