I get the point this person is making, but at times (and depending on language) it's the fastest and most efficient option. "Oh, the value is not what I expected" -> fix -> "value is good after testing, can remove the debug print". It's not elegant, yes, but it does the job with zero preparation and works for every language. Now if things are so hopeless the debug print doesn't even work, then yes, get a proper debugger.
I clicked on this about to type exactly that phrase.
Here's why: the CORE PROBLEM of debugging has nothing to do with process, it's the need for the human developer to understand the operation of machine code when faced with a specific set of runtime conditions.
You can't debug by just reading code, because the bug only shows up at runtime. Most people agree with this.
Likewise, you can't debug just by WATCHING a program, for the same reason. You need to be reasoning about the operation of the abstracted code at the same time. And almost always you need to be inspecting and reasoning about the internal states driving the behavior.
Debugging tools, as nice as they might be, can only do the "watching" part. They are a fine way to do it, but you still need to be making the decision, based on careful analysis of the code, on which elements to watch.
So... given that you're staring at code in your editor and thinking about how to extract the needed internal state to validate your predictions... why not just print it?
That is: print/console debugging isn't a hard task you "have to do" in the absence of a fancy debugger, it's exactly the task that you must do if you're going to solve the problem. The fancy debugger, at best, is only saving your the time taken to TYPE the printf() expression. And in practice even that tends to parallelize with the analysis in my experience, as you realize things while typing out their expression.
https://pernos.co/about/expressions/
Notice in this demo how he clicked on a line number, and got back a list of all the times in the program where that line was executed. Not just a single breakpoint with the option to continue, but all of them. Then he queries for the value of a variable at all of those points, and gets all the values printed out simultaneously, as if there had been a printf at that line. Then he filters the list to show only calls made on a specific object, as if the printf had an if statement around it. All without needing to rerun the program, or even be on the same computer as where the recording was captured.
This is what the author means when he says that all debugging tools can be _better_ than printf debugging, if only we put some more time into improving our tools.
By all means, use fancy tools like replay debuggers (of which Pernosco is only one example) if they make you happy. I'm just saying that (1) there is a hard cap on the value that tooling can provide, because the real limitation is between our ears. And so (2) I'm going to spend the limited learning bandwidth between my ears on things like genuine new technology and not better tools that might provide a mildly incremental improvement to tasks I do already.
For example, I participated in a project recently to extend Flex so that it could generate both Rust and Go code, in addition to C. Pernosco was an invaluable aid here. I was able to get Flex to generate a C program and also a Rust program, then compare the execution of those two programs. I recorded them both, and opened them each in their own window. Keeping them side–by–side, I could probe the innards of both programs simultaneously. Since both programs were supposed to implement the same state machine (and thus recognize the same list of tokens), it was easy to find places where the Rust version went off the rails. I was able to do in hours what would have taken days with any other method, if I had succeeded at all. The behavior of that state machine is not at all obvious, and I might never have unraveled it without Pernosco.
See... I think that's just wrong. Here's how I'd do that (knowing nothing about flex but having written similar state machine generators for non-lexing problems):
+ augment the generated code to dump the sequence of state transitions and tokens to stderr or whatever
+ run it in both environments
+ diff the output
+ Go back and add some metadata like __FILE__/__LINE__ or whatever as needed to find the bad data or state
+ Repeat as needed
But I think that you’re underestimating the time that it would take you. Sure, if you knew ahead of time what you would need to log, it might take an hour or even less. In practice though you’re going to end up going through that loop dozens of times, adding some logging to both sets of source code (or removing something that turned out to be useless or confusing), rebuilding, rerunning the test case, and diffing the outputs.
Much better to record everything, and I do mean everything, using rr. Then you can add and remove data from your queries until you understand the bug (or rather, one of the handful of bugs that all existed at the same time) and how to fix it. No changes to the source code needed, no need to recompile them or rerun the test case.
However, I am perfectly willing to suppose that you could do in hours what would have taken me days. There are a lot of people in the world, and some of them are bound to be better engineers than I am. In that case, I suspect that using Pernosco, you could have done it in minutes instead of hours. I think it’s safe enough to say that gives me a straight 5× improvement to my abilities, and it would do the same for you.
Incidentally, roc has talked about adding automatic diffing of recordings to Pernosco. This would be diffing between multiple runs of the same program, rather than between two related programs that happen to be trying to accomplish the same task, but I can well imagine how much time it will save. Imagine those intermittent tests that fail one time out of a hundred. Currently you can rerun the test until you manage to capture the failure in a recording, and that helps to debug the problem quite a lot. But then imagine comparing a successful run to the failed run, so that you know the bug is in one of the differences between them. It’ll give anyone superpowers.
Of course there is some "cap" on the value tooling can provide, but whatever it is, for some people at least it's close to the total time they spend debugging.
Bullshit. I regularly find bugs in code review, just by reading code. I think this is true of most experienced programmers.
So yeah, in the text above I'd view "code review" and "static analysis" as distinct tasks from "debugging". And I'm only talking about the latter.
This is really the problem. Nobody has spent time and money to make debugging _good_ in the languages you use. Few people pay for good tools any more, and only a tiny fraction of users ever contribute improvements to the open–source tools they use (paid or otherwise). So the average debugger hasn’t gotten better since the 90s.
I do programming in multiple languages too. In those where I can use RR and Pernosco, I use them every time. In those where I can’t, I miss RR and Pernosco every single time.
* Debugging an 8 bit microcontroller in-circuit with an IDE, conditional breakpoints, step in/out/over, full stack visibility, and the ability to manually poke at values/memory/io
* Debugging an AWS lambda function with printf and high latency logs
It doesn't matter how hip, how modern, how fast, or how big the environment is. What matters is whether or not the ecosystem cares enough to make debugging nice.
Live by the sword, die by the sword.
As pg said, it's like scrubbing dishes with your fingertips: rarely discussed, highly effective.
Print debugging is like scrubbing dishes by hand, and neglecting your dishwasher.
Pernsoco is like those commercial dishwashers that blast the dishes with super–heated steam to wash them in a few minutes instead of 45.
I suppose I feel the same way with print debugging. Mostly that's all I need and the problems I have which would benefit from better tools are rare enough and diverse enough it isn't worth investing time in them.
Anyway I don't really care about some insignificant "environment" difference - the affect on daily convenience far outweighs it.
A tub setup would be more environmentally friendly considering the resources put into a dishwasher these days. Certainly drying via a towel is better then an electric heater.
Oh hell no they aren't. They're terrible at handling anything that's dried on plates.
I've never found a dishwasher that could clean truly dirty plates. NEVER. Even if you run them ten times in a row.
Of course I’m as lazy as the next person; there are dishes in my sink right now that could be put in the dishwasher, if only someone would empty the dishwasher of the dishes I washed the other day…
Even so, I can only recall one time where it didn’t get a baking dish fully clean. I just left it in the dishwasher and ran another load the next day and it was fine. Then I baked some more enchiladas in it.
You need to pre-wash everything before loading it anyway, and in the end I still need to scrub and re-wash some of the dishes in the sink.
I'd rather just do it myself from the beginning. Takes less time and effort, and comes out cleaner.
Are you using a rinse-aid? If not, you're doing it wrong.
I never pre-wash. I'll manually remove solids when I'm done eating (e.g. with a spoon), but most people do that anyway because it'll be a pain to hand wash if you don't.
I don't have a dishwasher. I don't know anyone who has a dishwasher. Heck, I don't even think I've ever seen a dishwasher on any appliance store I've been to. Our apartment was built with space for a dishwasher and a clothes dryer, and I've always wondered why, because nobody I know personally has either of these appliances.
I might imagine a Christian or Muslim (fundamentalist) society looking down on appliances that do 'womens work'. And I've spent some months in southafrican townships. Such places have no dishwashers. Or did not have them.
I'm not trying to doxx you, or attempting to get people to post prviate info, but I would love to know your demographic.
Southeastern Brazil, in the Rio de Janeiro metropolitan area.
Meanwhile there are no equivalent places where you can take your dirty dishes to wash.
Considering that "throwaway packaging and cutlery" is a common solution to this: Order food, the packaging, plastic forks and spoons and napkins included. And seeing that a large demography is trying to live off "less waste", I do see an opportunity here.
A community "diswashing service". It would need solid infra and tech to not immediately turn into a rat-infested-mould-party, but I truly think that a place where e.g. you drop your dishes, cutlery, glasses etc, and can pick them up in the evening filled with a meal, is an opportunity. For example.
Which reminds me, wasn’t room service once a perk you could get in some apartment buildings? You don’t often find dumbwaiters in apartment buildings any more, for example. I would pay for that if it were available.
That's extremely condescending, not to mention plain wrong.
I know from experience that the statement holds true for several Christian fundamentalists and Jewish fundamentalist (not all!)communities. I have only read (but not from experience) about how women (especially those of other sects) were treated in the Chalifate from ISIS and how their "work" was deemed slave-worthy.
It's still outright wrong. Your experience with Christian and Jewish fundamentalists does not apply to Muslims. Please stop with spreading incorrect information about Muslims.
ISIS is a fringe group whom we don't give any semblance of credence to, and even they would not look down at washing machines "because it's a woman's job". This is plain ridiculous.
The secular West continues to group all religions together and marks any religious person as some sort of sheep.
Also, let's stop with this "identifies as" business. A person is either a Muslim or a non-Muslim. A person who does not believe in God cannot "identify as" a Muslim for example. That being said, the religion is open to anyone who wants to accept it.
As long as you accept it is their right to define that, and not you!
One might use "identifies as" to avoid the classic response of "ah but x was not really a y because z". Someone who believes themselves to be a Muslim simply is. You can call them a bad Muslim, ignorant, misinformed, misguided etc. But they are what they believe themselves to be.
(I am entirely sympathetic to your original frustration. GP was applying very odd assumptions)
That's not how Islam works. That's how it was able to survive against the torrent of corruption that affected Christianity and Judaism. The Quran and Hadiths are preserved so that we're easily able to consult them to determine who is and isn't a Muslim. Note that this isn't gate keeping, Islam is wide open for anyone to accept. However, the tenants are strict enough to survive the passage of time.
> You can call them a bad Muslim, ignorant, misinformed, misguided etc. But they are what they believe themselves to be.
This already happens. I'm talking about the extremes that the secular West has adopted, whereby people can inherit their parents religion, even if they don't believe in it.
And yet those poor benighted souls believe they follow those very same texts that you say would reject them. How is that possible? Because their religious leaders interpret the texts differently, emphasise different aspects.
For a Christian equivalent. The Catholic church can excommunicate someone. They will no longer be Catholic but there is no power that can stop a person who believes themselves to be Christian from being termed that. "Normal" Christians might prefer not to be associated with various people, can call sects Extremist or Fundamentalist etc. We simply cannot claim they are Not Christians.
You'd be surprised to find that said "religious leaders" you're referring to don't know the basics of exegesis. This applies to ISIS for example. I invite you to read the many Hadiths about Khawarij, those immediately reject your premise that all interpretations are equally valid. They're not.
It is, also much much easier to identify a race condition with print debugging than a debugger.
Debuggers help immensely if you can reproduce the bug reliably and in relatively decent time, but if you can't logging/print debugging is your only hope, since no one is going to run their code in production with RR attached.
Have looked at, say, the Python debugger as used by PyCharm and thought "well this seems like a bludgeon, I only need to see how <variable> isn't working as expected" and bung in various print() statements in and around the Thing concerned, sprinkling them wider and wider if the bug isn't localised to a function or even the class it's in - I may have supplied naff information to a class when instantiating it, for example.
Debuggers are simply too much of a complicated bludgeon. I can understand a need for debuggers for machine code/assembly programming, or deep system programming when you're hitting the metal, or even low level languages like C.
I've yet to find a need for a debugger for high level languages like Python. Perhaps some day. Until then, I'll plough the time which would be required to Get To Know the debugger, into writing code.
Whenever I try to print debug, I end up missing the mark on my first print statement(s).
If I just set a breakpoint, I can jump back in the stack, or step forwards, so I can easily find the real place the error happens.
Of course I sometimes still print debug - when using languages with bad debuggers, languages where I don't know the tooling, languages with horrible control flow (javascript callbacks), or constrained environments, printing/logging is sometimes the best you can do. But that doesn't mean it's the best there is.
I put "if (condition): import pdb; pdb.set_trace()" all the time and almost never use "print".
So, clearly I don't love "print", I just hate debuggers that are annoying to set up.
I suspect that if other languages had such a convenient "drop me into the debugger" statement, more people would use debuggers.
You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
> You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
You could just put a breakpoint there, look at as many values as you want, and not have to re-run it if you think of another.
To me that's the key difference. If I know what I'm looking for, prints are great. If I don't know what I'm looking for, breakpoints are a must.
Still though, I reach for print debugging first.
But in a normal environment ? or using C++ ? It's generally quicker (though much dirtier) to find simple bugs using print statements to track down assumptions ; when you're in the weeds with a complicated problem or need to track down a crash, then yes, bring out the big guns. But for normal development, I don't think it's completely necessary.
Eg: tracking the values of a std::vector isn't obvious, since there is std:begin and std::end iterators in the vector namespace and you have to manually dereference the whole range in the debugger.
I used to print-debug a lot, but since I started working with a stack where I use an IntelliJ derivative - that is to say, where the debugger actually works - and I'm never ever going back. It's better by a huge margin.
I tend to use print debugs in two cases. One is when I'm pretty sure I know what the problem is, and it seems trivial. It's often faster to just confirm & fix that way. The other is when I am not even sure where to start, so I put a few canary prints here and there based on hunches until I start to narrow in mentally on what the issue might be.
Beyond that, it's a proper debugger.
I argue that printf debugging is more difficult if you dont know _what_ is incorrect, or if you dont know where a value is being changed. Stepping through your code is a great way to find out.
To me, actual stepped debugging is like having a print statement for every single line in the code base.
Or even impossible? I use print debugging often, not even only in cases where there's no step debugging possible and/or I'm too lazy to fire up a config/software which allows debugging, but from time to time I encounter bugs which I really can't even begin to imagine how terribly awkward it would be without step debugging. For example: finding a bug in a mark&sweep garbage collector written in C which only occurred in certain LTO builds. To get a picture of the problem I stepped through assembly code while looking at certain memory locations, regsiters, the C stack, and some related variables. How would one tackle that with print debugging? Plus the print statements would affect the very thing being debugged? That should be fun. Not to mention the effort it took to even be able to reach the exact code location where all of this happened. Would almost require to randomly sprinkle print statements all over the place.
EDIT: I don't want to go so far as to say that your example can never happen, but I can't believe there is any domain where it is the norm
I don't get your point, because that's not what I suggested someone should do. I think (on rereading my original comment) my point was the exact opposite: Develop an understanding of the code through the effective use of a debugger:
> In fact, the debugger can be a fantastic way to learn the code since the dynamic behavior of a system can often be hard to infer from its static representation (looking at you WPF and XAML, or any project where architecture astronauts went hog wild with certain design patterns).
You seem to have inferred something from my comment that I did not say.
Add some instructions to print "**1**", "**2**", "**3**", ... to see how far the program goes, which branches it takes, print a few variables that look interesting. If that fails print the uninteresting variables, remove "**1**" and add some "**2a**", "**2b**", ... in between 2 and 3 ...
After a while, you discover the correct spot and the correct variable, and the error is trivial.
Looking at the effort involved: here you have to spend the time to add a bunch of print statements throughout bits of code; then compile/run the program (repeating until you've found the right place).
With a debugger: you'd have to take the time to set up the environment and learn how to use it (e.g. set breakpoints in parts where things would be interesting). But then the "look at interesting values" wherever isn't significant additional effort.
(I use both)
No, it's quite possible to have a screwdriver in your pencil holder and turn it manually at the moment you need it.
"Low tech", yet quick and precise and no batteries to charge.
1. Ability to prevent wasting resources on a system that does not need to be debugged. 2. Retain most print debug branches that were useful. 3. See how the internals are functioning on a live system with the issue that has yet to having a lab level proof.
It's even worse if it's multithreaded as well. If you hit a breakpoint, one thread stops and the others keep going, but they keep going in an environment where one thread is effectively dead (the one at the breakpoint). Everything is invalid from then on, in all threads. So breakpoint debugging is certain to be doomed.
Print debugging is not doomed, but it's challenging. The problem is that the time to print out the message can change the timing, and therefore change what happens. It's not certain to do so, but it's something you always have to keep in the back of your mind: "What if this changed the sequence? What if what I'm seeing in the printouts isn't what I would see if the printouts weren't there?"
The reality is that you're not going to attach a debugger to a production service. If you are doing things correctly and have separate environments for test/integ/prod you are not going to attach a debugger. Even if you can attach a debugger, the odds of you catching something are pretty small (not talking about trivial things).
So you should: 1) instrument your code and have the proper debug/verbosity log levels for things 2) have a trivial way of altering the log levels 3) have a way to fetch the logs and diagnose what is going on solely based on the logs (and hopefully with something as simple as grep).
This is the way. There are times and places when debuggers can be useful, but in most situations I see them as a crutch that adds more friction instead of accelerating solving the problem
https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...