As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger?
I've seen how GDB works, and debugging this way seems much less productive. You don't see your whole source code, and you don't constantly see the values of watched or local variables, etc... Is there a different debugger you use for this task when developing using only a text editor (vim/emacs/sublime)?
I found that I wrote much better code once I ditched the IDE debugger, and stopped writing enterprise code... Perhaps the latter outweighs the former in terms of impact.
Firing up GDB for those rare segfaults which I don't immediately know the cause of (the last 2 lines I wrote, usually) gives me a stack trace very quickly, and lets me dump the values of the variables in that frame. I rarely need more. That wasn't the case back in my enterprise days.
GDB is very powerful, check out its integration with emacs for example (not something I've used).
When I moved from Windows to Linux development I was concerned how that would affect me. Turns out not so much, I just don't debug as much on Linux :)
IDE debuggers make it far too easy to press F5 and see what happens, make a change, press F5 etc without really thinking about what's happening. Iterative coding gone bad.
The only time I use GDB is for the occasional segfault that I can't figure out from back-stepping a few revisions, and it always nails it (which is more than can be said for MSVC)
I use Vim/Sublime for rote text editing and scripting languages. For most statically typed languages (C, C++, C#, Java, Objective-C and so on) I tend to use an IDE with a Vim emulator.
But honestly, visual debugging is nice and all but I don't know if the debugger is really the biggest loss of not using an IDE - for me it's more the code completion, navigation and refactoring support I'm after. You can get most of that going pretty well with Vim but it's a bit of a hassle.
>As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger?
I'd ask the reverse of you. Why do you spend time in a debugger at all? For 99% of the bugs logical thinking and a few printfs work faster and better ran blindly running around setting breakpoints and examining values.
Adding printf statements implies recompiling or rerunning code. A good debugger lets you set breakpoints against your app while it runs, and have the breakpoint log a message instead. So even if you just want to log messages at certain spots, a good debugger works better (to say nothing of following program execution through long sequences of source code files, which is even handier when the source code is some open source component that you didn't write).
I agree that printf works better than "blindly running around setting breakpoints", but so does pounding a 12-pack of beer and then hitting yourself in the face with a mallet until the solution comes to you.
On the other hand, learning to use a modern, advanced debugger and then applying that skill along with some of that logical thinking can be extremely effective in finding the cause of bugs as quickly as possible.
For languages like Objective-C or Java, I think the 'real men don't need a debugger bro' attitude is nuts. It is different for a lot of newer and/or more dynamic programming languages, which simply don't have debuggers anywhere close to as powerful as those of IntelliJ or Xcode/lldb.
Though learning how to use the debugger is a good skill to learn, these days I don't know anyone around me who has ever used a debugger, or even finds a use for it. I think the best tools of our age are really REPL's, which allows you to test out your guesses/hypothesis in the form of snippets.
Personally I have probably used a debugger 5-6 times in my whole programming career, these days I hardly find a use for it.
Depends on your use case. If you're trying to find an issue in Java code running on an app server somewhere where you're not allowed to update code (say, if you work in B2B and it's a customer site), being able to remote debug does wonders.
I think it very much depends on the language and platform/environment.
I've been programming professionally for nearly 20 years, in languages ranging from Perl to C/C++ to Javascript, and the only times I've used GDB in the last 15 years have been when C/C++ code is segfaulting and I want a stack trace. The rest of the time I use print/printf statements. I've built some pretty successful software this way, some of which you've probably heard of or used.
On the other hand if I were coding exclusively in C/C++, or Java, or using an IDE for my work, I might use a debugger more.
I think the use of the word printf makes which ones we're discussing pretty clear.
I'm getting up there too. And I know lots of older programmers with very bad habits. Many who have also working on household names. Age+popularity != skill/quality.
Doing that in anything but interpreted and micro applications seems like a massive waste of time and effort(both placing the printfs, recompiling, removing them recompiling.
We've all done it. It doesn't mean its a good way to do it.
And like I said above it can introduce bugs into your code doing so. I remember one case where a printf for debugging changed the memory in such a way as to make an uninitialized variable work. After testing when the printfs were removed the application would stop working.
Introducing code into your code base with the intention of removing it later when there is an easy way to not do so is asking for trouble.
It can be nice to pause the execution and think, then continue one line at the time and really see what is happening.
Also I hate writing prints over and over. Sometimes it is imply faster to put a breakpoint, look at the value and then pop it away. As opposed to manually writing the print, then check, and then removing it.
Debuggers are handy for the last 1% of bugs. And anyway there is nothing about debuggers that precludes logical thinking or requires "blindly" placing breakpoints.
I've seen how GDB works, and debugging this way seems much less productive. You don't see your whole source code, and you don't constantly see the values of watched or local variables, etc... Is there a different debugger you use for this task when developing using only a text editor (vim/emacs/sublime)?