5 ms·

In a few years of my career now I never had to use a debugger or CI. Console debugging is good enough usually. On version control I agree.

by zwnow 1y ago

01HNNWZ0MV43FF 1y ago
CI is really nice with multiple platforms or multiple people. Solo projects for Linux, I never bother
polishdude20 1y ago
I was the same until I started working on a Go server. It helps immensely when I want to know the value of objects say when a request is handled and how that flows.
aerhardt 1y ago
I do not know what you work on, but debugging is indispensable for certain workloads. Print debugging doesn’t come close to setting up a breakpoint and inspecting every single variable in the stack with a good interface. You don’t even have to select what to print and where, anything can be printed anywhere in two clicks. A UI like the debuggers in Jetbrains IDEs provides smart rendering for all types so that for example map or list elements can be collapsed. The entire call stack is neatly organized and searchable too. It saves hours, creates less friction and also greatly enhances exploratory debugging, where you don’t even know where in the call stack your problem might be. I’d feel very hindered and unhappy if I didn’t have access to a good debugger.
- zwnow 1y ago
  I dont know, sounds more like a design issue to me, if your app requires this amount of information to get debugged properly.
  - trueismywork 1y ago
    Really? Just try debugging a Dijkstra like algorithm and then talk about design issues.
    - coderenegade 1y ago
      My bread and butter at one point was working on various pathfinding and numerical computing problems, and I'm primarily a print statement debugger. The time evolution of the system is usually the most important signal for debugging these types of problems, and is easy to dump. That's not to say I don't also use debuggers when necessary, I just reserve those for very hairy problems that can't be solved any other way, e.g. stepping into dependencies. Let's not forget that debuggers have their limitations too, e.g. release build GC optimization (or indeed any release-only bug), and any init process where you have to attach the debugger after the startup, fundamentally cannot be debugged using debuggers.
karn97 1y ago
You seem to have worked on small simple projects thus far then.
- guappa 1y ago
  Or on embedded systems
  - deleted 1y ago
    [deleted]
planb 1y ago
I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full mental model of what really goes wrong and often just fix the symptoms. Think "that shouldn't be null, we need a null check here" instead of "why is this value null? we should check here, but also make sure the caller works correctly."
- johnisgood 1y ago
  You can have that kind of thinking or mental model with and without debuggers though. I do not see how it is relevant to debuggers.
- vacuity 1y ago
  On the other hand, though this is n = 1 and from 2000 (and it is classic Linus): Linus Torvalds: > I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. > I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. > Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. > I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65 And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.
xnorswap 1y ago
The conclusion I draw from this is that some debuggers are so bad it's not delivering value over "print debugging". But perhaps it's a lack of knowing what a debugger can deliver. A debugger gives you the ability to immediately dive in and instantly inspect the complete stack trace, all the values on the stack, all the values of local variables, etc. Without restarting the program or calling out specifically what you're going to want to inspect ahead of time. A debugger will "pause the world" and let you see all the parallel stacks. A debugger will let you set conditional breakpoints. If you need to debug the conditions for when a variable gets set to a particular value, a conditional breakpoint on the variable set to break when it's set to that particular value makes that a doddle. A debugger will let you enumerate collections and re-write values on the fly. A debugger will let you break on exceptions, even ones normally caught and handled. A debugger can launch and attach itself. All of that is a massive force-multiplier and time-saver, which print debugging doesn't deliver.
- wiz21c 1y ago
  A debugger doesn't show you the evolution of your program over time. A few well placed prints give you that. I use my debugger often, but sometimes you need to track the value of something over time (say, over 1000 iterations) and a debugger can't show you that. So prints are still relevant. Debugger are more for "needle-in-haystack" stuff I think. A debugger that could record the execution over time (and query that execution), that would be great. I know there are some, but are there for python for example ?
  - lcnPylGDnU4H9OF 1y ago
    > I know there are some Do you mind providing examples? I’m not sure what I would search to find that and I’m interested in the idea.
    - danadam 1y ago
      I've never used it but sounds like https://rr-project.org/ https://rr-project.org/
- 1y ago
deleted 1y ago
[deleted]
yetihehe 1y ago
Debuggers are important tool, but not all debugger are good and not all problems require debugger. That's why I wrote a simple tool, which given a list of methods and classes will printf to log every invocation and exit of selected functions (via java reflection and function rewriting). It was much better than a normal debugger at finding actual flow of data in very complex multi-program system, so essentially machinegun-printf saved the day.
HelloNurse 1y ago
There are different categories of tools. You can design a house on paper, but you need e.g. mallets and wheelbarrows to build it; you can design software with "tools for thought", more or less computerized, but you need the automation offered by CI, version control etc. to handle the more concrete aspects properly.
stackedinserter 1y ago
It means that you don't write anything complex.
- paganel 1y ago
  Which is most probably the majority of us, computer programmers.

In a few years of my career now I never had to use a debugger or CI. Console debugging is good enough usually. On version control I agree.

by zwnow 1y ago

In a few years of my career now I never had to use a debugger or CI. Console debugging is good enough usually. On version control I agree.

01HNNWZ0MV43FF 1y ago

CI is really nice with multiple platforms or multiple people. Solo projects for Linux, I never bother

polishdude20 1y ago

I was the same until I started working on a Go server. It helps immensely when I want to know the value of objects say when a request is handled and how that flows.

aerhardt 1y ago

I do not know what you work on, but debugging is indispensable for certain workloads. Print debugging doesn’t come close to setting up a breakpoint and inspecting every single variable in the stack with a good interface. You don’t even have to select what to print and where, anything can be printed anywhere in two clicks. A UI like the debuggers in Jetbrains IDEs provides smart rendering for all types so that for example map or list elements can be collapsed. The entire call stack is neatly organized and searchable too. It saves hours, creates less friction and also greatly enhances exploratory debugging, where you don’t even know where in the call stack your problem might be. I’d feel very hindered and unhappy if I didn’t have access to a good debugger.

zwnow 1y ago
I dont know, sounds more like a design issue to me, if your app requires this amount of information to get debugged properly.
- trueismywork 1y ago
  Really? Just try debugging a Dijkstra like algorithm and then talk about design issues.
  - coderenegade 1y ago
    My bread and butter at one point was working on various pathfinding and numerical computing problems, and I'm primarily a print statement debugger. The time evolution of the system is usually the most important signal for debugging these types of problems, and is easy to dump. That's not to say I don't also use debuggers when necessary, I just reserve those for very hairy problems that can't be solved any other way, e.g. stepping into dependencies. Let's not forget that debuggers have their limitations too, e.g. release build GC optimization (or indeed any release-only bug), and any init process where you have to attach the debugger after the startup, fundamentally cannot be debugged using debuggers.

karn97 1y ago

You seem to have worked on small simple projects thus far then.

guappa 1y ago
Or on embedded systems
- deleted 1y ago
  [deleted]

planb 1y ago

I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full mental model of what really goes wrong and often just fix the symptoms. Think "that shouldn't be null, we need a null check here" instead of "why is this value null? we should check here, but also make sure the caller works correctly."

johnisgood 1y ago
You can have that kind of thinking or mental model with and without debuggers though. I do not see how it is relevant to debuggers.
vacuity 1y ago
On the other hand, though this is n = 1 and from 2000 (and it is classic Linus): Linus Torvalds: > I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. > I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. > Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. > I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65 And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.

xnorswap 1y ago

The conclusion I draw from this is that some debuggers are so bad it's not delivering value over "print debugging". But perhaps it's a lack of knowing what a debugger can deliver. A debugger gives you the ability to immediately dive in and instantly inspect the complete stack trace, all the values on the stack, all the values of local variables, etc. Without restarting the program or calling out specifically what you're going to want to inspect ahead of time. A debugger will "pause the world" and let you see all the parallel stacks. A debugger will let you set conditional breakpoints. If you need to debug the conditions for when a variable gets set to a particular value, a conditional breakpoint on the variable set to break when it's set to that particular value makes that a doddle. A debugger will let you enumerate collections and re-write values on the fly. A debugger will let you break on exceptions, even ones normally caught and handled. A debugger can launch and attach itself. All of that is a massive force-multiplier and time-saver, which print debugging doesn't deliver.

wiz21c 1y ago
A debugger doesn't show you the evolution of your program over time. A few well placed prints give you that. I use my debugger often, but sometimes you need to track the value of something over time (say, over 1000 iterations) and a debugger can't show you that. So prints are still relevant. Debugger are more for "needle-in-haystack" stuff I think. A debugger that could record the execution over time (and query that execution), that would be great. I know there are some, but are there for python for example ?
- lcnPylGDnU4H9OF 1y ago
  > I know there are some Do you mind providing examples? I’m not sure what I would search to find that and I’m interested in the idea.
  - danadam 1y ago
    I've never used it but sounds like https://rr-project.org/ https://rr-project.org/
1y ago

deleted 1y ago

[deleted]

yetihehe 1y ago

Debuggers are important tool, but not all debugger are good and not all problems require debugger. That's why I wrote a simple tool, which given a list of methods and classes will printf to log every invocation and exit of selected functions (via java reflection and function rewriting). It was much better than a normal debugger at finding actual flow of data in very complex multi-program system, so essentially machinegun-printf saved the day.

HelloNurse 1y ago

There are different categories of tools. You can design a house on paper, but you need e.g. mallets and wheelbarrows to build it; you can design software with "tools for thought", more or less computerized, but you need the automation offered by CI, version control etc. to handle the more concrete aspects properly.

stackedinserter 1y ago

It means that you don't write anything complex.

paganel 1y ago
Which is most probably the majority of us, computer programmers.