IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.
Let us not forget the war to end all wars:
Tabs vs spaces
The unreasonable effectiveness of print debugging
161–170 of 366 posts
Re: The unreasonable effectiveness of print debugging
#162Earlier quoted context omitted.
I tried using it but got stuck on having to learn Lisp to understand my config file.
Apparently all the cool kids are using neovim + Lua these days. Lisp turned me off of emacs years ago as well. Recently I started digging into Neovim and have found Lua much easier to parse/internalize than Lisp, and kind of a joy to work with.
Great, I am at least halfway on the right track since I am using neovim. I know Lua a bit, I actually didn’t realize it was integrated.
Re: The unreasonable effectiveness of print debugging
#163Stupid question: why don't more programming languages and/or compilers natively support the alternative to print debugging, which is (afaik) tracing? I guess some languages have it, but some don't, or they are onerous add-ons?
Re: The unreasonable effectiveness of print debugging
#164Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…
Python easily has the best debugger I've ever seen in a language. ``` import pdb; pdb.set_trace() ``` that's literally all you have to do at any point in your code. Run your code in the foreground of a terminal, and boom you have a debugger exactly where you want it.
In recent Python, it's even easier -- just put `breakpoint()` in your code.
Re: The unreasonable effectiveness of print debugging
#165[deleted]
Re: The unreasonable effectiveness of print debugging
#166Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…
Print debugging always works, but also: it lets the programmer customize their view of the program’s (very, very large) hidden state in any way imaginable. Step debuggers are the “no-code” equivalent: extremely useful for the purposes for which they were designed—and often the better choice there—but inherently limited.
Geoff’s not wrong in invoking Bret Victor’s Learnable Programming argument that being able to track state over time is critical to debugging, and Geoff’s right that print debugging makes this easier than almost any existing step-debugger.
Bret’s deeper point, though, is that a major challenge in debugging is hidden state in general, and that variable state changing over time is just one example.
Not only is there a ton of hidden state in the execution of a program—the full execution trace PLUS state of every variable at each point in that trace—but there is also a ton of interpretation of that state that the programmer needs to do while debugging: “what does this sequence of events imply?” - “why is this pointer pointing here?” - etc.
Doing that interpretation is much easier when the programmer gets to selectively view that (again, HUGE amount of) hidden state. Print debugging gives the programmer complete control over what state is shown. No other debugger does that: they all show a ton of data and context (often useful!) and make certain operations easy (inspecting single variables! viewing call stack snapshot!), and these are often just the right things.
But sometimes they’re not. And often, when you start debugging, you don’t know if the fancy debuggers will be too much or not enough.
Print debugging gives you the power to write code to selectively view the (again, HUGE!) hidden state of your program, and this scales from the smallest code-tracing bug to the largest distributed systems.
Step debuggers, on the other hand, are essentially “no-code” debuggers — extremely useful for the purpose for which they are designed, still useful for adjacent purposes, and a great place to start if you know the tool well, but ultimately not as powerful if your needs exceed their capacities.
A good programmer will know how to use all these tools for what they’re best at!
Re: The unreasonable effectiveness of print debugging
#167Earlier quoted context omitted.
Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understanding what you are doing and your system. It's different every time. And while there's a general algorithm you can follow: 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 How would you teach that…
I think this is the standard algorithm and it's absolutely terrible. People poke at things, which ends up giving a linear search across a possibly huge system. Even if the "guess" is intelligent, it's not like you can trust it. If you actually fully understood the system, you would know what's wrong and you wouldn't be debugging. Do a bisect instead. The complexity is O(log n). It's probably slower than if you guess…
Your algorithm is for creating programs or adding new features. Not reslly for debugging already broken stuff.
I would agree that hoing from less to more complexity is a great heuristic for making those guesses on what to check.
Re: The unreasonable effectiveness of print debugging
#168Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…
Print debugging always works, but also: it lets the programmer customize their view of the program’s (very, very large) hidden state in any way imaginable. Step debuggers are the “no-code” equivalent: extremely useful for the purposes for which they were designed—and often the better choice there—but inherently limited. Geoff’s not wrong in invoking Bret Victor’s Learnable Programming argument that being able to trac…
If you've chased heap corruption printf doesn't really help you much but a data breakpoint is a godsend.
Same thing with watch windows, memory views and the like. There are classes of problems that do well with printf but calling them "no-code" is vastly underselling them.
Re: The unreasonable effectiveness of print debugging
#169Probably the most interesting thing about development as a discipline is the near radio silence on how to debug. There is a decided lack of academic success in engaging with debugging as an object that can be studied. There are channels to learn about debugging as a stand-alone topic. Programmers don't often talk about debugging techniques in my experience. For something that takes up the overwhelming bulk of a devel…
It's one of those things that is acquired with experience and from more and more peers one has had. I think I've learned a bit from all my peers, almost everyone had something interesting or an interesting way to tackle a problem. Once a lot of time is spent in the industry one starts seeing patterns as a new cycle starts.
As far as teaching debugging, it is one thing to show some examples and another one is to run into a bug yourself and get from having no idea how to debug to actually fixing it. That whole experience is hard to replicate in unnatural ways.. When I was in school they told me not to worry too much about debugging and that I'd run into issues in the real world and figure out ways to debug depending on the system and that turned out to be quite correct.
Re: The unreasonable effectiveness of print debugging
#170Debuggers are next to useless when dealing with today's distributed systems, all operating asynchronously in parallel. For the kind of bugs (race conditions, corner cases) that aren't easily caught by compilers, linters, unit tests or code review (in other words, the "Heisenbugs" that can stop a release in its tracks), aggressive logging is the only tool I've ever seen that is useful in-the-wild.
I would put forward that proficiency with this style of debugging (closely related to useful performance profiling) is a major factor separating mediocre programmers from the quasi-mythical 10X rockstars.