21–30 of 37 posts
Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
You had colors? Back in the day, all I had was an unused GPIO pin and an oscope. One pulse, assert code 1, two pulses, assert code 2, etc. (I’m kind of riffing on an old Dilbert cartoon, but debugging with a scope was common in my life in embedded systems.)
Honestly, I don't get this debate. If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available. Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to caus…
It makes total sense to insert a lot of logging statements into your code, which can be switched on when you need to diagnose something. This can be also used then in production, where you can't just change code (but switch the log level in the config). Very useful
Adding and removing print statements (== modifying code) as you are investigating is bad practice, because you are modifying the program you try to fix. It can be a lot of clutter inside the code, and maybe you fix/break the program by coincidence and didn't even notice. Once you undo your changes, before committing the bug is back.
Ah, a merveilles post! Haven't seen one in the wild before, only heard of it through the Hundred Rabbits site, great to see it.
Earlier quoted context omitted.
Multiple times I've had bugs that disappeared when print debugging was added. To say that that was frustrating is an understatement. (But where there's a will, there's a way. It just takes longer, sigh.)
One trick to minimize debugging footprint is to store logs in a ring buffer/array list and defer printing. It's not perfect, but if you use a ring buffer, you can avoid making any syscalls until you are truly ready to print. Thread synchronization can obviously still be a problem, but that can be mitigated by using thread local buffers or by using a lockless ring buffer. Ring buffers are also nice because you can als…
When I read "debug by print VS debuggers", I wonder: why versus? Why you can't use print AND logs AND debuggers AND REPLs AND asserts AND tests AND analyzers or whatever other tool whenever you need it, depending on the problem you face?
We use all those tools and way more, and it is probably the flexibility and ability to use all of those what gives us an advantage.
It is probably the effort to learn something new until it makes sense, most people just don't do the effort. I remembered the first time I saw asserts everywhere in one of the best programmers' I have worked with code. It looked ridiculous from my old mindset but I said to myself: This guy is really good so odds are it is me the one who does not get it.
So I started just doing the same the guy did, removing rational judgment for a while, so I did not let my brain to trick me into not doing the work finding this or that reason.
After a while, it made all the sense, my code become much better, I had almost no bugs compared to my early life, and bugs were catched instantly near the place they were and did not produce secondary bugs that were the ones that I catched before, taking me a long time to decipher.
Remember that reason alone is very poor for understanding the world. The world is a complex place and reasons are multiple and nuanced. You learn much better if you just copy what the best people do in the field and experience it yourself like kids do with their parents, then you will understand.
You will not understand by arguments alone. Your arguments could be brilliant, but you are always modeling the world, and if your model is wrong or lack essential constituents, it is garbage in, garbage out.
Honestly, I don't get this debate. If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available. Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to caus…
Stepping through can be a pain sometimes, because to find certain bugs it's easier to look through a log throughout a longer run of the program, and see how the state changes. Of course, a debugger that could generate a log like that instead of pausing execution would give you that benefit too.
I am always surprised by how a significant part of the population are purist or religious mindset about everything, specially tools. They take a rigid hard stand,idealized to Totem status and don't move from that as they consider anything else "Tabu". When I read "debug by print VS debuggers", I wonder: why versus? Why you can't use print AND logs AND debuggers AND REPLs AND asserts AND tests AND analyzers or whateve…
This is heresy in geek circles, where people believe they can reason from first principles and background knowledge through entire other fields of study without ever having to discover contradicting facts. But it's very true.
Sometimes you can't even use print debugging. I've debugged by modifying colors a few times.
Earlier quoted context omitted.
One trick to minimize debugging footprint is to store logs in a ring buffer/array list and defer printing. It's not perfect, but if you use a ring buffer, you can avoid making any syscalls until you are truly ready to print. Thread synchronization can obviously still be a problem, but that can be mitigated by using thread local buffers or by using a lockless ring buffer. Ring buffers are also nice because you can als…
This is genius. I hadn’t heard of this logging style before. I’m going to try it tomorrow morning.