5 ms·

I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus t

I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus the other. Logging, done well, will inform (1) exactly what version of your code you were running 3 months and 12 days ago, and (2) where the potential issue may be. Therefore it will inform you _where to place a breakpoint_ should you wish to repro the issue and debug locally. Good luck getting started in a local debug session without having had adequate logging in place.

deepGem 4y ago
Even better luck debugging in the enterprise without logging. You won’t even know which machine your code is running on and in which machine Splunk is spitting out the logs. Without printing time stamps and debug worthy information to the logs, you are fucked, period.
lytefm 4y ago
Also, when trying to reproduce an issue, adding logs can often be more helpful than using a debugger: With the debugger, you can only see the application state at one specific point at the time. With added print statements, you get a nice history of the application state. If I already know where exactly something is going wrong: sure, I'll could a breakpoint there, if needed - often it's not. If I don't know where exactly the problem is, I'll add print statements.
- DougBTX 4y ago
  > With the debugger, you can only see the application state at one specific point at the time. Really depends on the debugger. Some tools support “time travel” debugging, which essentially stores a structured log of memory state over time.
  - Qem 4y ago
    The Smalltalks are nearly unmatched on this. Pharo is a great representative of this tradition.
    - igouy 4y ago
      "One aspect which has not yet been focused upon is that in modern Smalltalks (forget about the block-fiddling in ST-80) exceptions are proceedable. This means, that the exception handler may decide to repair some malfunction and continue execution after the point where the original exception was raised." https://wiki.c2.com/?SmalltalkAndExceptions https://wiki.c2.com/?SmalltalkAndExceptions
      - Qem 4y ago
        So it falls short of full fledged past time travel. It's more like you could stop the flow of time, fix whatever went wrong, and then restore time flow, as if nothing had happened. Short of what OP wanted, but still very useful. It avoids "Groundhog Day" debugging.
        igouy 4y ago
        > Short of what OP wanted… (That wasn't what I wanted to post; I should have waited.) More like stop the flow of time, fix whatever went wrong, fix why it went wrong, go back before it happened, and then restore time flow, as if nothing had happened (so more restart before than resume after). I don't know if that's what the OP wanted or not, I'll leave you to explain. https://news.ycombinator.com/item?id=28361693 https://news.ycombinator.com/item?id=28361693 https://news.ycombinator.com/item?id=28361845 https://news.ycombinator.com/item?id=28361845
        Qem 4y ago
        Sorry, I got confused.
        igouy 4y ago
        About what the OP meant or about what I meant? :-)
        Qem 4y ago
seanmcdirmid 4y ago
There are a lot of contexts where debugging isn’t feasible, like rubbing your (flaky) test 600 times to figure out why it is failing 2 out of 600 runs. Since starting my job at Google a couple of years ago, I haven’t used a debugger once, it wouldn’t really work for what I’m doing. Couple that with remote development limitations (and not being able to run an emulator truly locally), and it doesn’t make sense to use a debugger even when it might be useful.
dgfitz 4y ago
> I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus the other. Just yesterday I debugged a problem starting with gdb and ending with print statements. I needed both to find the issue. This isn’t an emacs vs vi debate, I completely agree.
nemo44x 4y ago
I don’t think he’s talking about logging here. He’s saying that devs are more likely to print variable states, etc to their console rather than load up the debugger to step through.
AtlasBarfed 4y ago
FOr multi/parallel issues, debuggers are practically worthless. Logging + threadid + timestamps and something to organize/sort the output is about all you can do. Debugging parallel/multithread code is a badly unsolved problem in programming, and something that TDD, which tends to focus on single thread units, also doesn't really address. I think it would require something that can built on-the-fly visualized reconstructions of what happens, almost like a starcraft game where each unit is a process/thread and it replays events from the log in reversible forward/backward slo-mo. Interactions or message passing can be attacks on other "units". Or some dynamic graph/process diagram builder that links together the processes when message passing occurs or flashes/changes color as interal process state changes. Good news everybody! All your code should be built with the intent of multithreading or parallelism to some degree, since that is all that we can really do with the remaining scaling from Moore's law, and really has been for a decade now. Edit: oh I forgot. Debugging multithread isn't even a single-VM issue now. Even more common is visualizing interactions across many many VMs thanks to microservices.
- samsquire 4y ago
  When writing multithreaded code I need some visualization of where everyone could be. It's expensive invariant management. There is a partial order that is fine and there is a partial order that is not fine. If we could define the orders with a sorting function and apply them to events in real time that would be perfect. In effect my partial order cannot overlap your partial order. This is the grounds of the YATA algorithm. Happens before relation is really powerful. But it needs to be visible to other processes.
  - AtlasBarfed 4y ago
    Sounds like code proofs and other things which I last saw in the 1990s in school. But I see how once you have to cross the rubicon to parallel processing, to make it sane, you'll need to rethink the old ways from simpler serial execution programming.
    - samsquire 4y ago
aaron695 4y ago
IshKebab 4y ago
It's clear that he meant they are only using printf debugging. The most basic form of debugging. The point is that most developers don't use the tools that are available to them. They're stuck in the stone ages. Nobody is saying that you should never use printf debugging. Sometimes it is the best way.

deepGem 4y ago

Even better luck debugging in the enterprise without logging. You won’t even know which machine your code is running on and in which machine Splunk is spitting out the logs. Without printing time stamps and debug worthy information to the logs, you are fucked, period.

lytefm 4y ago

Also, when trying to reproduce an issue, adding logs can often be more helpful than using a debugger: With the debugger, you can only see the application state at one specific point at the time. With added print statements, you get a nice history of the application state. If I already know where exactly something is going wrong: sure, I'll could a breakpoint there, if needed - often it's not. If I don't know where exactly the problem is, I'll add print statements.

DougBTX 4y ago
> With the debugger, you can only see the application state at one specific point at the time. Really depends on the debugger. Some tools support “time travel” debugging, which essentially stores a structured log of memory state over time.
- Qem 4y ago
  The Smalltalks are nearly unmatched on this. Pharo is a great representative of this tradition.
  - igouy 4y ago
    "One aspect which has not yet been focused upon is that in modern Smalltalks (forget about the block-fiddling in ST-80) exceptions are proceedable. This means, that the exception handler may decide to repair some malfunction and continue execution after the point where the original exception was raised." https://wiki.c2.com/?SmalltalkAndExceptions https://wiki.c2.com/?SmalltalkAndExceptions
    - Qem 4y ago
      So it falls short of full fledged past time travel. It's more like you could stop the flow of time, fix whatever went wrong, and then restore time flow, as if nothing had happened. Short of what OP wanted, but still very useful. It avoids "Groundhog Day" debugging.
      - igouy 4y ago
        > Short of what OP wanted… (That wasn't what I wanted to post; I should have waited.) More like stop the flow of time, fix whatever went wrong, fix why it went wrong, go back before it happened, and then restore time flow, as if nothing had happened (so more restart before than resume after). I don't know if that's what the OP wanted or not, I'll leave you to explain. https://news.ycombinator.com/item?id=28361693 https://news.ycombinator.com/item?id=28361693 https://news.ycombinator.com/item?id=28361845 https://news.ycombinator.com/item?id=28361845
        Qem 4y ago
        Sorry, I got confused.
        igouy 4y ago
        About what the OP meant or about what I meant? :-)
        Qem 4y ago

seanmcdirmid 4y ago

There are a lot of contexts where debugging isn’t feasible, like rubbing your (flaky) test 600 times to figure out why it is failing 2 out of 600 runs. Since starting my job at Google a couple of years ago, I haven’t used a debugger once, it wouldn’t really work for what I’m doing. Couple that with remote development limitations (and not being able to run an emulator truly locally), and it doesn’t make sense to use a debugger even when it might be useful.

dgfitz 4y ago

> I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus the other. Just yesterday I debugged a problem starting with gdb and ending with print statements. I needed both to find the issue. This isn’t an emacs vs vi debate, I completely agree.

nemo44x 4y ago

I don’t think he’s talking about logging here. He’s saying that devs are more likely to print variable states, etc to their console rather than load up the debugger to step through.

AtlasBarfed 4y ago

FOr multi/parallel issues, debuggers are practically worthless. Logging + threadid + timestamps and something to organize/sort the output is about all you can do. Debugging parallel/multithread code is a badly unsolved problem in programming, and something that TDD, which tends to focus on single thread units, also doesn't really address. I think it would require something that can built on-the-fly visualized reconstructions of what happens, almost like a starcraft game where each unit is a process/thread and it replays events from the log in reversible forward/backward slo-mo. Interactions or message passing can be attacks on other "units". Or some dynamic graph/process diagram builder that links together the processes when message passing occurs or flashes/changes color as interal process state changes. Good news everybody! All your code should be built with the intent of multithreading or parallelism to some degree, since that is all that we can really do with the remaining scaling from Moore's law, and really has been for a decade now. Edit: oh I forgot. Debugging multithread isn't even a single-VM issue now. Even more common is visualizing interactions across many many VMs thanks to microservices.

samsquire 4y ago
When writing multithreaded code I need some visualization of where everyone could be. It's expensive invariant management. There is a partial order that is fine and there is a partial order that is not fine. If we could define the orders with a sorting function and apply them to events in real time that would be perfect. In effect my partial order cannot overlap your partial order. This is the grounds of the YATA algorithm. Happens before relation is really powerful. But it needs to be visible to other processes.
- AtlasBarfed 4y ago
  Sounds like code proofs and other things which I last saw in the 1990s in school. But I see how once you have to cross the rubicon to parallel processing, to make it sane, you'll need to rethink the old ways from simpler serial execution programming.
  - samsquire 4y ago

aaron695 4y ago

IshKebab 4y ago

It's clear that he meant they are only using printf debugging. The most basic form of debugging. The point is that most developers don't use the tools that are available to them. They're stuck in the stone ages. Nobody is saying that you should never use printf debugging. Sometimes it is the best way.