6 ms·

Whats even better than print for debugging is using a debugger...

ggambetta 8y ago
Doesn't quite work when debugging a distributed system, though. You end up adding a lot of "distributed print", AKA logging.
- judgardner 8y ago
  Fair enough, but attaching multiple debuggers across several interacting components with conditional breaks gets me there faster than incrementally inserting progressively more print statements, in a dev environment. Proper logging is a given doping out problems in a production system to then verify and correct in dev.
  - sieabahlpark 8y ago
    Logs aren't a bad thing and they aren't going away. Whoever let's you setup debuggers on prod should be fired.
    - judgardner 8y ago
      Agreed, great logs are great. My comment explicitly stated dev environment, not prod, for debugger usage.
    - canhascodez 8y ago
      No one said otherwise, and the comment you replied to specifies "in a dev environment". The language you are using is unnecessarily combative: this is likely to inhibit the adoption of your ideas.
    - rurban 8y ago
      Only with python. With LISP it's the common case to debug prod. I would rather argue that such incompetent managers who speak such nonsense need to be fired.
      - protomyth 8y ago
        Smalltalk folks will debug in production too. Although to be fair, Smalltalk folks will write whole programs in debug in development.
        rurban 8y ago
        Sure. Arguably Smalltalk is a LISP, just with non-Lisp syntax. It actually was prototyped in lisp first.
    - pmoriarty 8y ago
      Sometimes having a debugger on prod is the right answer. "The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.) "The Remote Agent was subsequently named "NASA Software of the Year"." http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html http://ti.arc.nasa.gov/m/pub-archive/176h/0176 http://ti.arc.nasa.gov/m/pub-archive/176h/0176 (Havelund).pdf
- avita1 8y ago
  There is much more to logging than print statements. I have yet to run into production code which uses vanilla stdout print statements for logging.
beatgammit 8y ago
I disagree. Most of the time, I find a debugger just slows me down. It's super helpful in some cases, but good logs can pinpoint problems far before a debugger can. Also, building in debug mode can change everything, so you may not even catch your bug, especially if it's concurrent in nature.
- judgardner 8y ago
  I think there are two use cases here, I was referring to debugging during development and a lot of replies are regarding troubleshooting an active prod system. Of course we all hope for well thought out logging to troubleshoot issues we're seeing in prod. I'm referencing an pattern I see with junior devs who simply use "printf debugging" in development instead of learning to use a debugger properly, even with distributed systems.
  - akvadrako 8y ago
    > an pattern I see with junior devs who simply use "printf debugging" in development Whereas I see this pattern more with senior engineers.
    - analognoise 8y ago
      I don't use printf. I tie a pin to an assertion of the expected result, and watch it with an oscilloscope. Get on my level, normies. /s
- marktangotango 8y ago
  This idea that debugging with print statements is superior to using a debugger is simply false. Learn to use the debugger for your platform it will pay huge dividends throughout your career. I regularly see pais+ of println debuggers debate and speculate while the guy with the debugger drills straight down to the issue, and fixes it.
  - nayuki 8y ago
    I think it is a fallacy to choose either printing or debugging. I forgot where I read this, but the two techniques are fundamentally different. A debugger lets you stop execution and examine data structures at one point in time. Printing lets you accumulate a log of one particular data structure over a span of time. I think these techniques are complementary and have different effectiveness on different problems.
saagarjha 8y ago
If I have easy access to a debugger. It’s extra work to hook things up to a debugger, and there are certain restrictions that may apply (attach too late if process launch is not under our control, program may behave differently, etc.). If I do have access to a debugger, often I will just do “printf debugging” there by setting a breakpoint and adding an action to “p someVariable; c”. Usually I treat my debugger a sort of IPython for statically compiled languages, to mess around with and inspect values as programs are executing.
- sanderjd 8y ago
  I have yet to come across a situation in which it is not worth the effort to figure out how to attach a debugger to a piece of code I'm modifying.
  - saagarjha 8y ago
    Again, attaching a debugger is occasionally not helpful–for example, if you're trying to figure out why your program isn't loading certain plugins at launch, you trying to attach the debugger may happen after this step occurs. So you don't get to debug this process.
    - dvlsg 8y ago
      Or if an issue happens in your staging environment but not locally. That happened to me just yesterday, and a simple print statement gave me the information I needed to resolve the issue. I probably could have attached a remote debugger, and executed the relevant function a few times until my request got routed to the right process in the cluster, but that honestly would have taken me more time than just committing the print statement and letting CI take it away.
      - sanderjd 8y ago
        That seems like a good thing to use logging for, instead of a print statement. But you're right, figuring out a dev / prod discrepancy in already-running code is a case where a debugger is not as useful.

Doesn't quite work when debugging a distributed system, though. You end up adding a lot of "distributed print", AKA logging.

judgardner 8y ago
Fair enough, but attaching multiple debuggers across several interacting components with conditional breaks gets me there faster than incrementally inserting progressively more print statements, in a dev environment. Proper logging is a given doping out problems in a production system to then verify and correct in dev.
- sieabahlpark 8y ago
  Logs aren't a bad thing and they aren't going away. Whoever let's you setup debuggers on prod should be fired.
  - judgardner 8y ago
    Agreed, great logs are great. My comment explicitly stated dev environment, not prod, for debugger usage.
  - canhascodez 8y ago
    No one said otherwise, and the comment you replied to specifies "in a dev environment". The language you are using is unnecessarily combative: this is likely to inhibit the adoption of your ideas.
  - rurban 8y ago
    Only with python. With LISP it's the common case to debug prod. I would rather argue that such incompetent managers who speak such nonsense need to be fired.
    - protomyth 8y ago
      Smalltalk folks will debug in production too. Although to be fair, Smalltalk folks will write whole programs in debug in development.
      - rurban 8y ago
        Sure. Arguably Smalltalk is a LISP, just with non-Lisp syntax. It actually was prototyped in lisp first.
  - pmoriarty 8y ago
    Sometimes having a debugger on prod is the right answer. "The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.) "The Remote Agent was subsequently named "NASA Software of the Year"." http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html http://ti.arc.nasa.gov/m/pub-archive/176h/0176 http://ti.arc.nasa.gov/m/pub-archive/176h/0176 (Havelund).pdf
avita1 8y ago
There is much more to logging than print statements. I have yet to run into production code which uses vanilla stdout print statements for logging.

beatgammit 8y ago

I disagree. Most of the time, I find a debugger just slows me down. It's super helpful in some cases, but good logs can pinpoint problems far before a debugger can. Also, building in debug mode can change everything, so you may not even catch your bug, especially if it's concurrent in nature.

judgardner 8y ago
I think there are two use cases here, I was referring to debugging during development and a lot of replies are regarding troubleshooting an active prod system. Of course we all hope for well thought out logging to troubleshoot issues we're seeing in prod. I'm referencing an pattern I see with junior devs who simply use "printf debugging" in development instead of learning to use a debugger properly, even with distributed systems.
- akvadrako 8y ago
  > an pattern I see with junior devs who simply use "printf debugging" in development Whereas I see this pattern more with senior engineers.
  - analognoise 8y ago
    I don't use printf. I tie a pin to an assertion of the expected result, and watch it with an oscilloscope. Get on my level, normies. /s
marktangotango 8y ago
This idea that debugging with print statements is superior to using a debugger is simply false. Learn to use the debugger for your platform it will pay huge dividends throughout your career. I regularly see pais+ of println debuggers debate and speculate while the guy with the debugger drills straight down to the issue, and fixes it.
- nayuki 8y ago
  I think it is a fallacy to choose either printing or debugging. I forgot where I read this, but the two techniques are fundamentally different. A debugger lets you stop execution and examine data structures at one point in time. Printing lets you accumulate a log of one particular data structure over a span of time. I think these techniques are complementary and have different effectiveness on different problems.

saagarjha 8y ago

If I have easy access to a debugger. It’s extra work to hook things up to a debugger, and there are certain restrictions that may apply (attach too late if process launch is not under our control, program may behave differently, etc.). If I do have access to a debugger, often I will just do “printf debugging” there by setting a breakpoint and adding an action to “p someVariable; c”. Usually I treat my debugger a sort of IPython for statically compiled languages, to mess around with and inspect values as programs are executing.

sanderjd 8y ago
I have yet to come across a situation in which it is not worth the effort to figure out how to attach a debugger to a piece of code I'm modifying.
- saagarjha 8y ago
  Again, attaching a debugger is occasionally not helpful–for example, if you're trying to figure out why your program isn't loading certain plugins at launch, you trying to attach the debugger may happen after this step occurs. So you don't get to debug this process.
  - dvlsg 8y ago
    Or if an issue happens in your staging environment but not locally. That happened to me just yesterday, and a simple print statement gave me the information I needed to resolve the issue. I probably could have attached a remote debugger, and executed the relevant function a few times until my request got routed to the right process in the cluster, but that honestly would have taken me more time than just committing the print statement and letting CI take it away.
    - sanderjd 8y ago
      That seems like a good thing to use logging for, instead of a print statement. But you're right, figuring out a dev / prod discrepancy in already-running code is a case where a debugger is not as useful.