Ask HN: Do You Use a Debugger? | Hacker News Reader

Ask HN: Do You Use a Debugger?

I saw an interview with John Carmack in which he remarked that game developers and PC users more often use debuggers, but going into an industry with more Linux and Mac users, they pride themselves on the purity of not using IDEs or debuggers

It seems odd to me, but I also noticed a lot of my coworkers don't use the debugger in vscode or even the browser when I've shown them how. They opt instead to put console.log statements everywhere

Do you use a debugger or breakpoints? How common is it in your workplace for people to debug things the old school way and prefer plain text editors over IDEs?

View on HN

Historically, DOS/Windows IDEs (I'm thinking turbo pascal, turbo C, visual C(++)) had nice integrated debuggers. Click, set a breakpoint, click run until you hit the breakpoint. No friction. Unix, well, the debugger (if it exists) is separate executable, you might need to rebuild everything with the -g flag, you run the debugger, you type in your breakpoint. Every time. Your debugger runs line-by-line with no context. And might screw up your terminal output.

(yeah yeah yeah, I think gdb has a tui mode now and the emacs debugger mode can probably do all that, solve world peace, and cook me an omelet).

I'm lazy, so if I have to do a lot of work to run the debugger, I don't.

First choice is to look at the code and reason it out. Then throw some printfs in. Third time's a charm, so that's when I reach for the debugger.

I remember the day using a debugger for the first time and I asked myself, why I wasted so much time not using one.

In some languages it is so easy, that you don't even have to use an IDE. Let's talk about JavaScript / TypeScript... you could use the browser developer tools to set break points, but for transpiled projects with boilerplate you can also use the `debugger` statement to hardcode a breakpoint.

  function test(y) {
    var x = 1;
    debugger;
    return x * y;
  }

I wish they would take it one step further and integrate the timeless debugging[1] concept everywhere, where you could step forward bug also backwards.

1: https://www.youtube.com/watch?v=eGl6kpSajag

I do embedded development. I usually implement some kind of test system (on pc) that allows me to run systems tests of the whole application and for this I use a debugger when I don't understand why something fails. I also often debug unit tests using a debugger. I hate printf debugging.

A debugger will be preferable in situations with:

  - slow compilation
  - slow start
  - lack of serialization
  - complex algorithms

In all other cases I prefer debug logging. It’s just easier to scroll through a couple of pages than stepping in/out of functions and managing watches. If you compare my gdb session with my debug logs, in an ideal case they’ll be the same. The only difference is the amount of work I put into writing debug code or driving a debugger.

In general I think that logs and debuggers aren’t enemies. A debugger helps with exploration in a specific moment or catching a specific condition or access. Debug logs help with matching expectations about a whole process. But both can do both.

Also, when I’m writing a service, I always write detailed operation logs. Saves your butt when something “costed us money” happened three days ago and you have to explain why. These never get turned off, regardless.

It's somewhat language-specific, I think. With languages like Python or Lisp or Haskell or indeed Javascript, it's an interesting question what "using a debugger" means. They do have debuggers, but In a safe language with a REPL the need for a debugger significantly decreases. The only times I've painfully, desperately wanted a debugger has been when dealing with unsafe languages where stack frames can get overwritten, buffers can overflow, and I have no idea where the instruction pointer has wandered off to -- you know, when I can't even get printf() to work. One of the main things I would use gdb for when working with C is just to inspect values inside variables etc. and get the sort of insight into the program that comes free at the Javascript console.

Python is a common example. You can use a debugger in vscode but I rarely see people do this, opting instead for print statements everywhere. But for javascript, the ability to put breakpoints into sourcemaps is invaluable, because trying to debug minified or transpiled javascript is a pain in the ass, and yet I still see people console.log everything

More often than not, with python and other dynamic languages, the main source of bugs is not knowing the type of the variable you're dealing right now or what it contains at this point. Setting up breakpoints can be troublesome especially if your IDE/editor is not the one launching your process (attaching to PID is often not trivial). Strongly typed language often obscures logic with verbose syntax, that's where a debugger comes in handy. Compiled languages often only have a single start point and a debugger is more useful than print statement.

I find debuggers are more useful in a dynamic language because of the uncertainty of the state of the program. I am better able to write lots of code without testing frequently in C++ than I am in Python or Javascript

In a statically typed language and explicit type definitions.

int age = will never have string "December".

But in python both: age = 42 and age = "December" are possible.

Yes, that's why I find it much easier to write code without a debugger in c++, though I do use one frequently

Highly miffed that debugging is rarely important these days. I'm speaking from the perspective of programming at work. I have had several dev setups where getting debugging to work was a royal PITA.

Debugging is so useful as a tool. There is nothing like it. They help a lot when there is complex state being manipulated. Instead of writing print statements, recompiling, repeat, debugging enables seeing everything, computing watch statements, deeply inspecting objects wherever you are and so much more. The biggest thing it enables is near-0 cost hypothesis testing when debugging.

I've looked at some transpiled languages or other web tech such as wasm, and I've found that many of them lack any kind of sourcemapped debugging symbols, which makes them total nonstarters for me. I know chrome has experimental support for wasm debugging but I've been unable to get it to work, let alone allow vs or vscode to connect to the browser

All the time. I think it's a great way to "learn" the environment you're coding in sometimes.

When I was first learning PHP I spent a year or two without a debugger. The first time I tried one I learned about a whole bunch of global variables I had no idea about.

I recently set up nvim-dap and have wonderful debugging experience while still in the "purity of not using IDEs or debuggers" realm.

Not lately. Back about 2010, I inherited an ASP application written in VB.Net. I could not have maintained it for the dozen years I did without the debugger built into Visual Studio.

And long ago the Microfocus "animator" saved our bacon when a Peoplesoft COBOL program was blowing up mysteriously and blocking implementation.

I'm not sure I'd count the browser console as a debugger, but I do use it from time to time.

I exclusively work on Linux and I use GDB all the time with pwndbg plugin. Makes everything a million times easier. I do use a lot of prinf debugging, its the best for simple scenarios or to narrow down to where the actual issue is.

Not using IDEs isn't a bad thing, VIM is infinity customizable and you can setup your own work flow.

I only use a debugger to find where a hidden problem is.

Normally I just sprinkle lots of logging statements around, which tell what is going on and when that occurs, and building a bigger picture of what's happening in the program.

I also turn on as many warnings as possible with the compiler. Fixing those warnings as they appear prevents lots of shit later in the development process.

C++ embedded developer, CV algorithms optimization and very rarely JavaScript for personal use. I use the debugger exclusivelly.

Logs are useful when reproducing the issue is complicated or having no access to source code. Usually related to timing sensitive issues with systems that communicate with each other.

I use debugger in my personal projects. I think a debugger is very useful when the call stack is deep, especially when there are recursive calls. I need the debugger to see where exactly went wrong.

VSCode debugger is pretty useful with a GUI and the ability to set up conditional breakpoint.

I have never seen anyone use GDB through the terminal.

There are however good videos out there for learning it.

But the people I've worked with used either use emacs, notepad++, vscode, or gdbgui to debug code.

Powerful debugger like the one in .NET is really something that I'd want to have in all languages

Editing code at fly and moving program's current executing code ahead or behind is really handy, even for development purpose!

yes. replay.io, time travel debugging for JavaScript is so amazing and saves so much time compared to before that it's hard not to have that elsewhere.

For Java development I use it very frequently. Not so much for any other language, but then I don’t do much programming in other languages either.

Yes, frequently, I tried to get used to lldb, but I still find gdb's breakpoints easier to work with.

Yes though I’m not particularly good at it. At some point I need to invest some time into learning it more thoroughly

Yes I do. Mostly when working with Python, JavaScript, and Ruby. If the project is running in docker then I’ll use print statements.

You may be able to expose a language server port via docker, but personally I make sure all my docker-deployed projects can still run on a local machine before running in docker

Debuggers are mostly useful in environments where the state of the program can't be easily expressed in text format.

I use a language with a builtin debugger and profiler (Lisp). Sometimes I even make good use of those tools.

At work as well?

Yes all the time for Python, JavaScript and golang

Yes I do in .Net C#, never bothered in typescript

Yes, ipdb breakpoints in Python

I use debugger only in reverse engineering. There’s almost no need for the debugger in projects you own.

> There’s almost no need for the debugger in projects you own.

Perhaps if you work on very small projects

Cursor is my go to

Reply on news.ycombinator.com