3 ms·

I know I do. And I know I used to feel a bit guilty about it, that a real software engineer would use some fancy debugger. There are plenty, I work at a FAANG.

by mrwh 4y ago

I know I do. And I know I used to feel a bit guilty about it, that a real software engineer would use some fancy debugger. There are plenty, I work at a FAANG. But as others have pointed out, printf is often the best approach. It's iterative and repeatable. I don't feel at all guilty that's it's my go-to approach now.

DeathArrow 4y ago
I don't think using printf is wrong, but if you can use a debugger, you will solve the bugs faster and with less frustration.
kevin_thibedeau 4y ago
For embedded, a debugger can interfere with ISRs and thread execution and printed output is often the right tool for the job. Just think of printed status as console logging and ignore the snooty crowd who don't know any better. None of them bat an eye at the inefficiencies of slinging around the text encoded data structures we're inundated with. There's a healthy dose of hypocrisy in the industry.
- maccard 4y ago
  If you think prints can't interfere with thread execution you're very, very wrong.
  - rcxdude 4y ago
    It is substantially less interference than debuggers though (especially if you use async logging). On a lot of embedded systems hitting a breakpoint means the system will not function when execution continues.
    - maccard 4y ago
      I don't work on embedded systems so I can't comment on that particular kind of work. Interference is still interference though, and while debugging things that are susceptible to this kind of interference you need to be very clear about what you know you can rely on and what may be wrong. Relying on printing to not interfere is not possible. At best it's more reliable, in my average experience it's about as reliable, and in the worst case it's the same and both are broken. > especially if you use async logging If you are async logging then pretty much all of this goes out the window though. Firstly is your formatting async or does it happen when the message is enqueued? Message formatting is expensive, and the longer the message the more expensive it is to format. If you're dealing with low performance devices, you can definitely expect this overhead to adjust the performance and timings of your code. Running printf("%s\n") on a 1MB JSON blobis going to mess everything up, for example. Secondly, assuming that problem is resolved, you still need to order the messages to be printed. There is absolutely no guarantee that two messages sent at the same time from two different threads will be printed in the same order unless you enforce that through some other primitives - at that point see above.

by mrwh 4y ago

DeathArrow 4y ago

I don't think using printf is wrong, but if you can use a debugger, you will solve the bugs faster and with less frustration.

kevin_thibedeau 4y ago

For embedded, a debugger can interfere with ISRs and thread execution and printed output is often the right tool for the job. Just think of printed status as console logging and ignore the snooty crowd who don't know any better. None of them bat an eye at the inefficiencies of slinging around the text encoded data structures we're inundated with. There's a healthy dose of hypocrisy in the industry.

maccard 4y ago
If you think prints can't interfere with thread execution you're very, very wrong.
- rcxdude 4y ago
  It is substantially less interference than debuggers though (especially if you use async logging). On a lot of embedded systems hitting a breakpoint means the system will not function when execution continues.
  - maccard 4y ago
    I don't work on embedded systems so I can't comment on that particular kind of work. Interference is still interference though, and while debugging things that are susceptible to this kind of interference you need to be very clear about what you know you can rely on and what may be wrong. Relying on printing to not interfere is not possible. At best it's more reliable, in my average experience it's about as reliable, and in the worst case it's the same and both are broken. > especially if you use async logging If you are async logging then pretty much all of this goes out the window though. Firstly is your formatting async or does it happen when the message is enqueued? Message formatting is expensive, and the longer the message the more expensive it is to format. If you're dealing with low performance devices, you can definitely expect this overhead to adjust the performance and timings of your code. Running printf("%s\n") on a 1MB JSON blobis going to mess everything up, for example. Secondly, assuming that problem is resolved, you still need to order the messages to be printed. There is absolutely no guarantee that two messages sent at the same time from two different threads will be printed in the same order unless you enforce that through some other primitives - at that point see above.