7 ms·

I am always going to use print to debug in every programming language I can until the day I die.

konschubert 6y ago
I have found that print-style debugging gives a good birds-eye view of the situation. With a stepping debugger, I tend to get lost in the weeds. My suspicion is that the bug fixes I come up with are less holistic when using a debugger.
space_rock 6y ago
Actually rust has the functionality of Icecream as a buildin command "dgb" and you quickly find yourself using it over print
- huhtenberg 6y ago
  No doubt blatantly ripped off the venerable print_r :P
  - masklinn 6y ago
    Nope, because unlike print_r dbg! returns the input as-is, so you should be able to wrap any expression in dbg! in-place, and just get debug output. According to the RFC, the direct inspiration for dbg! is Haskell's traceShowId (http://hackage.haskell.org/package/base-4.10.1.0/docs/Debug-Trace.html#v:traceShowId http://hackage.haskell.org/package/base-4.10.1.0/docs/Debug-...).
- threatofrain 6y ago
  And Julia with @show.
QuesnayJr 6y ago
I had this exact thought, but the title gives the wrong impression (at least to me). The package just defines a fancy print.
- mcswell 6y ago
  Sure, but typing ic(someVariable) is a lot faster for me than typing print(f"{someVariable=}") in Python3.8 or >, and still faster than typing print(f"someVariable={someVariable}") in Python < 3.8 (which I still need to use in some cases). It's especially faster when I think about how often I fat-finger the '{' (and '}', when my editor doesn't insert the matching brace automagically). Of course YMMV.
  - QuesnayJr 6y ago
    I (and the person I replied to, I suspect) interpreted the title to mean that you shouldn't debug by printing stuff to the console at all, but instead do some other thing.
hathym 6y ago
give pycharm (or debugpy) a try, you might get few years of you life back :)
dnautics 6y ago
Same. I do this for elixir. Luckily, we have IO.inspect: https://youtu.be/JXQZhyPK3Zw&t=23m30s https://youtu.be/JXQZhyPK3Zw&t=23m30s
tasogare 6y ago
Why not taking the (short) time to learn using a debugger? This is way more efficient way to work for complex situations.
- ramraj07 6y ago
  I have debugger set in pycharm and use it all the time. I also use print all the time, often along with the debug tool. They are very complimentary and neither tool can do everything the other can.
  - masklinn 6y ago
    TBF if you always run your programs in pycharm and use its debugger, you can trivially use non-suspending "evaluate and log" breakpoints instead of print.
    - heavenlyblue 6y ago
      But prints work equally well in any environment. I can remove prints by just checking out the latest version of the file.
      - masklinn 6y ago
        > But prints work equally well in any environment. GP say they "have debugger set in pycharm and use it all the time". So under the assumption (explicitly made in my comment) that they're always using PyCharm to run their program, that's not a concern. > I can remove prints by just checking out the latest version of the file. Thereby losing all the changes you've made while observing program behaviour, which may be less than desirable. Meanwhile it's just as easy if not easier to disable or delete breakpoints from the View Breakpoints pane / window: https://i1.wp.com/cdn-images-1.medium.com/max/800/1*0wAP-w-a9SAN7xL8Cmfj0Q.png?w=980&ssl=1 https://i1.wp.com/cdn-images-1.medium.com/max/800/1*0wAP-w-a... you can just uncheck the "Python Line Breakpoints" box, or select all breakpoints and [Delete] them.
- masklinn 6y ago
pantulis 6y ago
It's the first debugging method one learns and always remains the last resort.
timbaboon 6y ago
When in doubt, cout :)
0xFFFE 6y ago
Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.
- yoz-y 6y ago
  It definitely has its place. The problem is mostly that you have to actually change your code to debug it, and then remember to change it back.
- maccard 6y ago
  > It's quick way to narrow down the "area of search" before bringing in the big guns. What are the big guns? with a debugger, I can stick a breakpoint and look at the entire state of everything. Given we're talking about Python, in pycharm [0] you can even execute your print statements in the debugger if you so wish. If you get the location wrong, or want to see what's going on elsewhere you can just continue execution and use another breakpoint. This is even more important if you have a long compile/deploy cycle (I work in games, and rebuilding and deploying to a console can be a >10 minute iteration time) [0] https://www.jetbrains.com/help/pycharm/part-1-debugging-python-code.html#start-debugger-session https://www.jetbrains.com/help/pycharm/part-1-debugging-pyth...
  - ZaoLahma 6y ago
    Sometimes sticking the debugger into the wheel makes stuff come flying over the handle bars in spectacular ways that have nothing to do with what you wish to observe. You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. In these cases prints work well as a less intrusive way to get a rough idea of what is going on.
    - maccard 6y ago
      I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?
jerzyt 6y ago
The old style printf from C is still the best formatting tool for output/debugging. The C++ style was just a distraction without introducing anything of real value. log4xyz has some nice features in terms of enabling/disabling at runtime, through a config, but ultimately, printf rules.
- sltkr 6y ago
  The value introduced by C++ was type safety. In C, it's way too easy for the format string to get out of sync with the type of the arguments, e.g.: printf("%d", my_long_var); Might seem correct and work correctly on one platform, but fail on another. scanf() is arguably even worse since it can cause memory corruption. These days compilers have diagnostics to catch those errors, but if you rely on those you can't use dynamic format strings, which means you're effectively using a subset of C with a stronger type checker than C. That's a pretty good state but it's definitely not "old style printf()"; old style printf() was insecure. And don't get me started on the convoluted macro invocations necessary to correctly convert int32_t, int64_t, size_t and ptrdiff_t. And that's with the newest standard: IIRC there was no standard way to print long long in C, at the time when C++ already supported it.
  - xeyownt 6y ago
    Maybe C++ fixed type safety, but it introduced lot of complexity and bugs for no actual added value. For instance, because of stateful ios objects, it's close to impossible to write correct code outputing hex on first attempt. I'm sure that lot of C++ code outputing hex is just plain wrong. Given that C++ keeps getting more and more complex features, it is just amazing that C++ I/O is still so inconvenient, opaque and ultra-verbose.
    - lorenzhs 6y ago
      I mean it's not particularly pretty but what's so bad about this? std::cout << std::hex << my_int << std::dec << std::endl;
      - 6y ago
bjourne 6y ago
You didn't even click on the link, did you? ;)
fredley 6y ago
Agreed, it's the simplest way to test and validate specific assumptions. Debuggers are useful tools, but it takes you just as long but usually longer to get to the same answer: is what I think is happening here actually happening here?
- ehsankia 6y ago
  At least debuggers give you new powers, the posted above makes you install a library, import it all just so you can have slightly cleaner print statements... I'm not gonna go out of my way to import something and have to clean it up after just so my printed statement is better formatted. And if I needed the more powerful debugging, I'd use a debugger not this library.
tpetry 6y ago
I am the same, it's the most easy. Very interesting is that in the laravel php world currently an interesting product is gaining momentum: Ray (https://myray.app/ https://myray.app/) So basically it's dump with a lot of neat extras and instead of looking at the console of the script, or the website you are printing on you push this to a little desktop application, from every of your languages you are using. Something like log collection for everything on your desktop.
RileyJames 6y ago
Hmmm I would have thought that too, but recently I’ve been using byebug, which has changed my mind. Being able to throw in ‘byebug’ on a line, then catch execution at that point in another terminal (using byebug remote) and then check variables at that point, is a game changer. Saves so much time compared to looking for printed statements in the output, and then trying again.
m463 6y ago
sometimes it's printf, sometimes it's printk, sometimes it's echo, but yes I agree. I had an emacs macro that would help. Simplified it was: (defun add-printf () (interactive) (let ((s (word-near-point))) (when s (beginning-of-line) (insert "printf(\"@@@ %s:%d " s ": 0x%x\\n\", __FUNCTION__, __LINE__," s ");\n") (forward-line -1) (indent-for-tab-command) (end-of-line) (search-backward " \\n" nil t)))) (global-set-key [f8] 'add-printf) I had lots of variants (crafted while recompiling) with prompts, or marked regions or lots more throwaway printf silliness
deleted 6y ago
[deleted]
gnramires 6y ago
My objection here is that code should be self-explanatory, and icecream or ic() doesn't explain itself, so at least I'd prefer a name like icecream_debugger and replace ic() with pr(), perhaps.
wrycoder 6y ago
“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” — Brian Kernighan, “Unix for Beginners” (1979)
xnx 6y ago
It's a failure of debuggers that they haven't cleared the very low bar of obviousness and ease of use of print(). I'm very much a novice, but RStudio was the first environment that made debugging so easy I didn't feel the need to use print().
maliker 6y ago
One of the nice feature of print debugging I like is that I often end up leaving some of the print statements in for logging purposes.

I have found that print-style debugging gives a good birds-eye view of the situation. With a stepping debugger, I tend to get lost in the weeds. My suspicion is that the bug fixes I come up with are less holistic when using a debugger.

space_rock 6y ago

Actually rust has the functionality of Icecream as a buildin command "dgb" and you quickly find yourself using it over print

huhtenberg 6y ago
No doubt blatantly ripped off the venerable print_r :P
- masklinn 6y ago
  Nope, because unlike print_r dbg! returns the input as-is, so you should be able to wrap any expression in dbg! in-place, and just get debug output. According to the RFC, the direct inspiration for dbg! is Haskell's traceShowId (http://hackage.haskell.org/package/base-4.10.1.0/docs/Debug-Trace.html#v:traceShowId http://hackage.haskell.org/package/base-4.10.1.0/docs/Debug-...).
threatofrain 6y ago
And Julia with @show.

QuesnayJr 6y ago

I had this exact thought, but the title gives the wrong impression (at least to me). The package just defines a fancy print.

mcswell 6y ago
Sure, but typing ic(someVariable) is a lot faster for me than typing print(f"{someVariable=}") in Python3.8 or >, and still faster than typing print(f"someVariable={someVariable}") in Python < 3.8 (which I still need to use in some cases). It's especially faster when I think about how often I fat-finger the '{' (and '}', when my editor doesn't insert the matching brace automagically). Of course YMMV.
- QuesnayJr 6y ago
  I (and the person I replied to, I suspect) interpreted the title to mean that you shouldn't debug by printing stuff to the console at all, but instead do some other thing.

hathym 6y ago

give pycharm (or debugpy) a try, you might get few years of you life back :)

dnautics 6y ago

Same. I do this for elixir. Luckily, we have IO.inspect: https://youtu.be/JXQZhyPK3Zw&t=23m30s https://youtu.be/JXQZhyPK3Zw&t=23m30s

tasogare 6y ago

Why not taking the (short) time to learn using a debugger? This is way more efficient way to work for complex situations.

ramraj07 6y ago
I have debugger set in pycharm and use it all the time. I also use print all the time, often along with the debug tool. They are very complimentary and neither tool can do everything the other can.
- masklinn 6y ago
  TBF if you always run your programs in pycharm and use its debugger, you can trivially use non-suspending "evaluate and log" breakpoints instead of print.
  - heavenlyblue 6y ago
    But prints work equally well in any environment. I can remove prints by just checking out the latest version of the file.
    - masklinn 6y ago
      > But prints work equally well in any environment. GP say they "have debugger set in pycharm and use it all the time". So under the assumption (explicitly made in my comment) that they're always using PyCharm to run their program, that's not a concern. > I can remove prints by just checking out the latest version of the file. Thereby losing all the changes you've made while observing program behaviour, which may be less than desirable. Meanwhile it's just as easy if not easier to disable or delete breakpoints from the View Breakpoints pane / window: https://i1.wp.com/cdn-images-1.medium.com/max/800/1*0wAP-w-a9SAN7xL8Cmfj0Q.png?w=980&ssl=1 https://i1.wp.com/cdn-images-1.medium.com/max/800/1*0wAP-w-a... you can just uncheck the "Python Line Breakpoints" box, or select all breakpoints and [Delete] them.
masklinn 6y ago

pantulis 6y ago

It's the first debugging method one learns and always remains the last resort.

timbaboon 6y ago

When in doubt, cout :)

0xFFFE 6y ago

Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.

yoz-y 6y ago
It definitely has its place. The problem is mostly that you have to actually change your code to debug it, and then remember to change it back.
maccard 6y ago
> It's quick way to narrow down the "area of search" before bringing in the big guns. What are the big guns? with a debugger, I can stick a breakpoint and look at the entire state of everything. Given we're talking about Python, in pycharm [0] you can even execute your print statements in the debugger if you so wish. If you get the location wrong, or want to see what's going on elsewhere you can just continue execution and use another breakpoint. This is even more important if you have a long compile/deploy cycle (I work in games, and rebuilding and deploying to a console can be a >10 minute iteration time) [0] https://www.jetbrains.com/help/pycharm/part-1-debugging-python-code.html#start-debugger-session https://www.jetbrains.com/help/pycharm/part-1-debugging-pyth...
- ZaoLahma 6y ago
  Sometimes sticking the debugger into the wheel makes stuff come flying over the handle bars in spectacular ways that have nothing to do with what you wish to observe. You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. In these cases prints work well as a less intrusive way to get a rough idea of what is going on.
  - maccard 6y ago
    I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?

jerzyt 6y ago

The old style printf from C is still the best formatting tool for output/debugging. The C++ style was just a distraction without introducing anything of real value. log4xyz has some nice features in terms of enabling/disabling at runtime, through a config, but ultimately, printf rules.

sltkr 6y ago
The value introduced by C++ was type safety. In C, it's way too easy for the format string to get out of sync with the type of the arguments, e.g.: printf("%d", my_long_var); Might seem correct and work correctly on one platform, but fail on another. scanf() is arguably even worse since it can cause memory corruption. These days compilers have diagnostics to catch those errors, but if you rely on those you can't use dynamic format strings, which means you're effectively using a subset of C with a stronger type checker than C. That's a pretty good state but it's definitely not "old style printf()"; old style printf() was insecure. And don't get me started on the convoluted macro invocations necessary to correctly convert int32_t, int64_t, size_t and ptrdiff_t. And that's with the newest standard: IIRC there was no standard way to print long long in C, at the time when C++ already supported it.
- xeyownt 6y ago
  Maybe C++ fixed type safety, but it introduced lot of complexity and bugs for no actual added value. For instance, because of stateful ios objects, it's close to impossible to write correct code outputing hex on first attempt. I'm sure that lot of C++ code outputing hex is just plain wrong. Given that C++ keeps getting more and more complex features, it is just amazing that C++ I/O is still so inconvenient, opaque and ultra-verbose.
  - lorenzhs 6y ago
    I mean it's not particularly pretty but what's so bad about this? std::cout << std::hex << my_int << std::dec << std::endl;
    - 6y ago

bjourne 6y ago

You didn't even click on the link, did you? ;)

fredley 6y ago

Agreed, it's the simplest way to test and validate specific assumptions. Debuggers are useful tools, but it takes you just as long but usually longer to get to the same answer: is what I think is happening here actually happening here?

ehsankia 6y ago
At least debuggers give you new powers, the posted above makes you install a library, import it all just so you can have slightly cleaner print statements... I'm not gonna go out of my way to import something and have to clean it up after just so my printed statement is better formatted. And if I needed the more powerful debugging, I'd use a debugger not this library.

tpetry 6y ago

I am the same, it's the most easy. Very interesting is that in the laravel php world currently an interesting product is gaining momentum: Ray (https://myray.app/ https://myray.app/) So basically it's dump with a lot of neat extras and instead of looking at the console of the script, or the website you are printing on you push this to a little desktop application, from every of your languages you are using. Something like log collection for everything on your desktop.

RileyJames 6y ago

Hmmm I would have thought that too, but recently I’ve been using byebug, which has changed my mind. Being able to throw in ‘byebug’ on a line, then catch execution at that point in another terminal (using byebug remote) and then check variables at that point, is a game changer. Saves so much time compared to looking for printed statements in the output, and then trying again.

m463 6y ago

sometimes it's printf, sometimes it's printk, sometimes it's echo, but yes I agree. I had an emacs macro that would help. Simplified it was: (defun add-printf () (interactive) (let ((s (word-near-point))) (when s (beginning-of-line) (insert "printf(\"@@@ %s:%d " s ": 0x%x\\n\", __FUNCTION__, __LINE__," s ");\n") (forward-line -1) (indent-for-tab-command) (end-of-line) (search-backward " \\n" nil t)))) (global-set-key [f8] 'add-printf) I had lots of variants (crafted while recompiling) with prompts, or marked regions or lots more throwaway printf silliness

deleted 6y ago

[deleted]

gnramires 6y ago

My objection here is that code should be self-explanatory, and icecream or ic() doesn't explain itself, so at least I'd prefer a name like icecream_debugger and replace ic() with pr(), perhaps.

wrycoder 6y ago

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” — Brian Kernighan, “Unix for Beginners” (1979)

xnx 6y ago

It's a failure of debuggers that they haven't cleared the very low bar of obviousness and ease of use of print(). I'm very much a novice, but RStudio was the first environment that made debugging so easy I didn't feel the need to use print().

maliker 6y ago

One of the nice feature of print debugging I like is that I often end up leaving some of the print statements in for logging purposes.