4 ms·

I think poorly engineered is a better term than under engineered in this case, but I agree with you. Logging is my go-to example for this sort of behaviour. Pe

I think poorly engineered is a better term than under engineered in this case, but I agree with you. Logging is my go-to example for this sort of behaviour. People write stupid amounts of log statements in their code, so much that it’s hard to even read the code to understand what it does, in the hopes that it’ll make debugging easier. Use a damned debugger! Take a traffic dump! Use strace! What’s more, it’s extremely rare that libraries provide logs themselves. So the actual complex parts of your application, like say the HTTP library or (God forbid) the TCP stack, can’t be debugged this way. If you find yourself writing a bunch of statements like “DEBUG: updating balance from 1 to 2”, stop and write some tests instead.

jcelerier 6y ago
> Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. - not an admin on the machine you are and the person with the admin account is not around ? sorry, you can't debug on macos (and likely in some linux distros) - likewise, no traffic dump (and I'd assume no strace) if you don't have root access
- SCHiM 6y ago
  And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.
  - coddle-hark 6y ago
    Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
    - SCHiM 6y ago
      I certainly wouldn't want to debug this ball of mud if there were no log statements, no :) But, I think we're depending on different programs in our workflow. I much prefer a logfile with statements that focus on what I want to inspect at the time. I'm quite proficient with debuggers on both Windows and Linux, but I tend to use them less when dealing with my own multi-threaded code.
    - merb 6y ago
      that works maybe with multi threaded code but not with greenthreads that are all over the place. the calls stacks are a pain in the ass.
- coddle-hark 6y ago
  > loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds To be clear I’m not talking about adding some specific print statements to the code while debugging, I’m talking about keeping those statements in production code. Of course, there’s cases where logging might be your only option. In that case: Go for it!
- MaulingMonkey 6y ago
  > - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! VS natvis files and other visualizers can hot-reload while I'm looking at a crash dump from production that took hours to trigger/gather/repro! There are cases for logs - where sufficiently efficient conditional breakpoints are particularly painful to setup, for example - but the only time I've waited minutes for a debugger to respond has been with VS after major system updates as it refreshes a universe of symbols from the symbol server. Do you have some really slow python scripts auto-loading in GDB or something?
  - jcelerier 6y ago
    > Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! well, we have definitely opposite experiences :) the main software I work on creates a ~1gb binary in debug mode and lld links that in a few seconds. Bud gdb and lldb, even with gdb-index, and all the optimizations I could find, both make startup slow enough that I can go for a coffee and it's not always finished loading when I'm back
nullsense 6y ago
On the contrary, I've spent months recently working on a system loaded with tech debt that has fallen victim to a half done rewrite. I've used a debugger on it plenty of times. It was only when I added proper logging to the critical junctures in the code that I could finally see very clearly how it behaves and see what input results in what code paths and output. I learned more in an afternoon than I did in a month.

jcelerier 6y ago

> Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. - not an admin on the machine you are and the person with the admin account is not around ? sorry, you can't debug on macos (and likely in some linux distros) - likewise, no traffic dump (and I'd assume no strace) if you don't have root access

SCHiM 6y ago
And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.
- coddle-hark 6y ago
  Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
  - SCHiM 6y ago
    I certainly wouldn't want to debug this ball of mud if there were no log statements, no :) But, I think we're depending on different programs in our workflow. I much prefer a logfile with statements that focus on what I want to inspect at the time. I'm quite proficient with debuggers on both Windows and Linux, but I tend to use them less when dealing with my own multi-threaded code.
  - merb 6y ago
    that works maybe with multi threaded code but not with greenthreads that are all over the place. the calls stacks are a pain in the ass.
coddle-hark 6y ago
> loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds To be clear I’m not talking about adding some specific print statements to the code while debugging, I’m talking about keeping those statements in production code. Of course, there’s cases where logging might be your only option. In that case: Go for it!
MaulingMonkey 6y ago
> - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! VS natvis files and other visualizers can hot-reload while I'm looking at a crash dump from production that took hours to trigger/gather/repro! There are cases for logs - where sufficiently efficient conditional breakpoints are particularly painful to setup, for example - but the only time I've waited minutes for a debugger to respond has been with VS after major system updates as it refreshes a universe of symbols from the symbol server. Do you have some really slow python scripts auto-loading in GDB or something?
- jcelerier 6y ago
  > Relinking a super large program may take minutes, whereas loading gdb can get me a backtrace in 3-4 seconds! well, we have definitely opposite experiences :) the main software I work on creates a ~1gb binary in debug mode and lld links that in a few seconds. Bud gdb and lldb, even with gdb-index, and all the optimizations I could find, both make startup slow enough that I can go for a coffee and it's not always finished loading when I'm back

nullsense 6y ago

On the contrary, I've spent months recently working on a system loaded with tech debt that has fallen victim to a half done rewrite. I've used a debugger on it plenty of times. It was only when I added proper logging to the critical junctures in the code that I could finally see very clearly how it behaves and see what input results in what code paths and output. I learned more in an afternoon than I did in a month.