Comments by "Vitaly L" (@vitalyl1327) on "STOP LEARNING LANGUAGES | Prime Reacts" video.

Printf debugging is limited indeed. Use proper logging instead, with multiple tiers of logging. It'll serve as an extra layer of documentation for your code and can be toggled by simply setting an environment variable.
6
Or any distributed system. Or, even worse, hard real-time distributed system.
5
Setting up an environment for debugging can be a hellish task indeed. First, not to forget to expose JTAG (even as unpopulated placeholder) on your PCB. Then, get a compatible JTAG programmer/debugger device for your target platform. Than configure your IDE, whatever it is (STM32Cube, whatever) to work with this particular JTAG programmer. And only after that realise that you cannot get execution traces over JTAG in real time without breaking real-time behaviour of the code you're debugging, so you just resort to debugging via a couple of available GPIO pins connected to a logic analyser. Or even blinking LEDs and capturing them with a high speed camera.
2
@PiratePawsLive lol, there is very little value in interactive debugging of this kind, especially for C++, where debugger will allow you to inspect the consequences of the problem (e.g., memory corruption), and will be useless in identifying the cause of the corruption that happened half an hour earlier of running the code under heavy load, in a very different part of the code.
1
@PiratePawsLive using an Arduino is almost cheating, as they (most of them) have built-in programmers with a USB interface. Although, if I remember correctly, Arduino IDE have a very limited debugging capacity...
1
@nchomey I'm not sure if I can name a single scenario where interactive debuggers would actually shine. Regardless of the type of the problems being solved. No matter what you do, you have data structures with complex semantics (e.g., if it's some GUI - you have your widget tree, etc.), while debuggers will only let you inspect the data structures on a very low level. Unless you invest a ton of time into implementing custom debug printers (e.g., see LLVM code base for quite a few examples of such). Even if the type of problems you're solving allows you to stop right where the problem happened, and not where it simply manifested itself, it's still a lot of extra steps you have to do vs. simply reading a well-formatted trace of the events that lead to the problem.
1
@PiratePawsLive automated code instrumentation is a very powerful tool for debugging (e.g., see Valgrind, or clang sanitisers). Until you know where the problem really is, you can instrument everything and log all suspicious events. Far easier to narrow down from having excessive information than to try finding a needle in a haystack without any relevant information at all.
1
@nchomey it's "print+trace+tons of other stuff" when bug happened. Logging is print+trace+tons of other stuff before the bug happened. See the difference? If you're preparing your comprehensive logging infrastructure in advance, you'll already have all the information you need to pinpoint the error when it happens. If you jump into an interactive debugging when you see an error, you start from scratch, you have nothing to work with.
1
@PiratePawsLive this is what logging tiers are for. You have an ability to log everything, ad nauseum, but in a normal operation you only log critical errors. Once an error happened - re-run with logging maxed out. You can also have logging tiers configurable per module, if you know where you want to look.
1
@bentomo I'd say I've seen (and done) far more logic analyser debugging than UART debugging. Reasons are pretty obvious: UART is slow, serialisation is slow, so you cannot possibly debug a real-time behaviour of your system this way. Overhead of flipping a GPIO is negligible in most cases, so using spare GPIOs for debugging with a logic analyser won't screw up the timing behaviour. And in the embedded applications you're more often than not concerned with the hard real-time scenarios.
1
@encapsulatio there is a lot of logging frameworks, available for every language imaginable. Or you can write your own. For C++, for example, there is google/capture-thread library. Also take a look at Iris. The proper logging framework requires the following: - log writer in a dedicated thread - lock-free communication between log producers from all the other threads and the log writer thread - convenient macros to turn logging off statically for select logging tiers - ability to turn the remaining logging tiers on and off dynamically (e.g., via an environment variable)
1
 @hypermiraclepositivegirl2415 see the answer above in this thread.
1
@NeoChromer yes, using logs and instrumentation is a far better way of doing it than an interactive debugging.
1
@NeoChromer you should have built in the comprehensive logging from the very beginning, not start adding logging when there is a problem. If you find interactive debugging more efficient than the static debugging approaches, you're doing it all very, very wrong.
1
@NeoChromer ever heard of ring buffers? I am debugging robots that produce megabytes of logs every second (and there is absolutely no way to use a stupid interactive debugger in a distributed hard real-time system), no problems here at all. Logging is a superior form of debugging, and if you need an interactive debugger crutch, you have so much more to learn before you can claim you're productive and efficient.
1
@NeoChromer you have so much more to learn, if this surprises you.
1
@adambickford8720 I don't think you can speak for "99.9%" of the cases. I did all possible kinds of developlent (excluding the web crap) in the last thirty years, and very rarely I had a use case for an interactive debuggers. Logging and instrumentation solved all problems far better. Look for an interactive debugging it is YOU who have to do the work and analyse.the output. For "gigs of logs" analysis can always be perfecrly automated.
1
@NeoChromer look, kid, it is you who mumble nonsense here. You really think your interactive debugging is an efficient way to solve problems, and it is hilarious. I worked on scientific number crunching, large industrial CADs, on GPGPU compilers, hardware drivers, video compression, high-frequency trading, industrial robotics, database engines - i.e., all projects shapes and sizes. Almost never met a case where interactive debugging would have been more efficient. And then, some web code monkey jumps up and babbles that my approach is "nonsense" and what monkeys prefer to do is much better.
1
Debugger, a crutch for the incompetent... How about debugging an FPGA bitstream with a couple of LEDs blinking?
1
@charlescoult clearly English is not your native language.
1
@nchomey debuggers make you fail in the very wrong way.
1
@isodoubIet it's really hilarious when code monkeys think they are superior. You realise that all your interactive debugging experience is utterly worthless? You simply have no idea how to debug the right way, yet your hurt ego does not allow you to admit your deficiency.
1