I do not use a debugger most of the time either. Let me tell you why I don’t:

- Because I forgot how to use it (or never knew how.) There are many debuggers and UIs and I still know how to use some of them to decent effect, but I simply don’t know how to be effective with most of them.

- Because I’m pretty confident I have a good understanding of what code is doing nowadays. My intuition has been honed over the years and I tend to quickly guess why my code isn’t working.

- Because my code is all unit tested now. This contributes to my ability to be more sure about what code is actually doing.

There are still some cases where I may try a debugger. I had one recently where I was unsure what path my code was taking and I wasn’t sure how to printf debug. That helped a lot.

Not using a debugger is not really a choice I made or something I do to try to look impressive, rather it’s most likely a result of the growing diversity of programming languages and environments I work in, combined with better testing habits. I just feel like I have enough confidence to fix the bugs quickly. When I lose that confidence is when I break out printf or the debugger.

> Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

Of course the first tool is careful thought. But when forced to fall back to print or log statements it feels like a handicap.

If I have to use a print statement it means I'm not sure what's going on so I'm not sure what, exactly, to print. By breaking on that code I don't have to know exactly because I can execute arbitrary code in that scope. What takes multiple iterations with print is often just one with break.

I can compare directly, because on a production-only bug I'm forced to use log debug statements. And usually in that case I have the same code open locally in a debugger. The difference is night versus day.

Maybe it's like a chess master who really doesn't need the board. For the kid in Searching for Bobby Fischer, it may really be a distraction. But I notice that grandmasters use a chess board in serious competition. And as a programmer I'm no grandmaster, and I play this weird game better with the board in front of me.

When I worked at Google Search last year, running a service locally in the Debugger was just about the only way to figure out what it does. There are so many control flow transfers - async message passes and you have no idea what is coming back - and people that think they are Templating gods and idiots who want to use syntactic sugar to define a new language and people using functors just 'because' and lambdas and other BS C++21 features inside Google and inheritance/container trees that look like a 3-D house that the debugger is the only way you can trace the control flow of such a haywire spaghetti code base.

Sadly, gdb is running out of gas at Google - it takes 60s to load "hello world" + 200MB of Google middleware and often it would step into whitespace or just hang, forever. This was often because not smart people were maintaining the gdb/emacs environment at Google.

Debuggers a great tool to have in your toolbelt. They can arbitrarily modify the state of the program at any point, let you safely inject code (I’ve written “coroutines” in LLDB for applications I did not have the ability to insert print statements in), and can be extremely helpful when performing dynamic analysis. That being said, sometimes you don’t have access to a debugger, so you have to do your best with the tools you have available. Finding a bug is always a challenge of removing extraneous state you don’t care about (“where do I put this print statement so it doesn’t get called a million times”, “how can I visualize the value of this variable when it changes in a way that is important”) so not having a debugger doesn’t change this: it just makes it somewhat more annoying (and requiring more ingenuity) to perform these tasks because you now have more limitations.

Debugging complex multithreading or timing-related bugs is one of the areas where a debugger, or even a bunch of logging, is not going to help you at all, because the slightest change in timing can make them disappear; only (very) careful thought is likely to lead to a solution.

Thus I mostly agree with the author of this article --- blindly stepping through code with a debugger is not a very productive way of problem solving (I've seen it very often when I taught beginners; they'll step through code as if waiting for the debugger to say "here is the bug", completely missing the big picture and getting a sort of "tunnel-vision", tweaking code messily multiple times in order to get it to "work".) If you must use it, then make an educated guess first, mentally step through the code, and only then confirm/deny your hypothesis.

I use a debugger all the time. Why guess about any of this stuff, and why trust your fallible intuition, when you could have the computer tell you exactly what's really happening? I think of it as analogous to using a profiler in this respect.

I write scientific simulations in Matlab. Debugging, that is, stopping the programs and interacting with the data and functions, is essential to me.

To a point, this is due to me not planning through my programs. So I can see that for some areas a debugger may not be essential.

But in other cases, I am actually interested to trace what happens with data in my mechanisms. For this kind of work, a debugger is essential.

Most importantly, as someone who maybe does not use the absolute best practices of designing software, debugging allows me to write solid and successful programs without having completed a CS degree.

I would like to meet someone who writes code without any bugs. Now if you're not putting bugs on purpose in your program, you probably don't know what they may arise from. So why use a tool (prints) which is deeply influenced by your assumptions on the program and which probably where wrong in the first place? Some more arguments for the debugger: -No need to recompile for each print -Available for multi-threaded progs -possibility to see the state in libs you're dependent on, in which you can't put logs nor asserts.

That depends on what problem or code base you are working with.

The debugger is the best answer when you are working with bad code, which you cannot reason about the code locally -- a random bug only happens on the production env, a mutable monolith, or a complex system integrating with 3rd party services. Because debugging is to know what happens in the first step, then build a theory to reason about everything. Sometimes, fixing the plane in middle-air requires you need to know what happened to the specific plain, instead of building a theory to make a plane having the exact problem without looking at the plane itself. Like in control theory if there are too many possible states, it's not cost efficient to reason about the state from behavior -- wherein software you can cheat and inspect the state directly.

However, I agree with the author that in the ideal scenario there's almost no need to use the debugger. Like in SICP, in the first few chapters the mental model is about the substitution model -- it's not how a computer really works, but it's easier to reason about, you don't have to in specific step with the specific environment to reproduce the problem (that's where debugger really helps). The code is written is a matter which is more coupled with the environment (which reflects the environment model in the following chapters), the more one needs to use the debugger to work with that code. And that's why the virtue of functional programming and the referential transparency are praiseworthy.

Debugger is just an inspection tool that allows you to see in detail how your contraption (program) behaves while it's running. Treating it as the tool of last resort, only after you've exausted examining your program while at rest, is needlessly limiting. I can see how that could make more sense in physical engineering (if you turn the contraption on without fully understanding it, you're risking doing some damage), but there is no such risk in SE, so why limit yourself?

I feel like debuggers usefulness is directly correlated to how specialized it is. A good debugger is all about giving you specific information on your problem. I find the classical step-by-step debuggers do an incredibly poor job at this. I never use them.

A tier up from that for me are higher-level debuggers, generally specific to some technology. For example, the browser dev tools, GTK Inspector, wireshark, RenderDoc etc. I'd also put tools like AddressSanitizer, Valgrind and Profilers into this category. Because they are more specialized, they can give you richer information and know what information actually matters to you. I usually find I use these regularly when developing.

The highest tier is tools specialized to your specific application. This could be a custom wireshark decoder, a mock server or client, DTrace/BPFTrace scripts and probes, metrics, or even an entirely custom toolbox. Interestingly, print statements end up in this same category for me, despite being the possibly simplest tool. Being specific to the problems you actually face allows you to focus on the very specific problems you have. This tier is interesting because these tend to become not just something you use when things go wrong, but become part of how you write or run your code.

Under this lens, I don't think it's that surprising people don't really use general step debuggers that much. They are a primitive tool that allows you to have many of the benefits of tier3 debuggers without any of the effort involved in making custom tools. They are the maximum reward/effort in terms of debugging.

Another way to think of this is that the debugger is a tool, just like other familiar tools such as tcpdump, ping, traceroute, nslookup, nc (netcat) etc. Choosing the right tool for the right observations to make progress in squashing said bug(s) is key here. Sometimes, all you really need is a methodical approach in putting print statements in the right lines of code, or even pinging a host that doesn't seem like it's up in the first place.

My problem with debuggers is that they are too good of tools. You use them, solve the bug, and move on. In the process, you might have learned something additional about the code base, but the only improvements to the code are fixing that particular bug. In contrast, when you don't use a debugger, then every now and then when you try to debug, you find that some of your work is not simply a temporary hack to identify the problem, but something that should stay in the code long term to assist in future debugging (be it asserts you added, or additional logging calls). The end result is that the more you debug without a debugger, the more debuggable you code becomes.

I am currently working on a codebase where all the developers are adamant debugger users. The code is practically impossible to debug without the use of a debugger, because no one has ever had to build up the debugging infrastructure.

Complex/diffucult bugs still take about as long to fix, but simple bugs take far longer than they normally do, because every time you use a debugger you are starting from scratch.

This is actually well written article by a CS professor and cited with experiences of few very productive programmers. Especially Linus's no bar holds post on this topic is worth reading:

https://lwn.net/2000/0914/a/lt-debugger.php3

Many people say not using debugger is other side of the pendulum but perhaps it is not. You want to have assertions/prints in your program at critical junctions. That should be able to explain the behavior of the program you are seeing. If it doesn't then you probably have missed some critical junctions OR don't really understand your own code. There is actually a third possibility where you will need debugger. This is the case when compiler/programming language/standard libraries itself has bug. Instead of more time consuming binary search for where you first get unexpected output, debugger might be better option.

The author ignores a variety of points, but the major one seems to be that there seems to be some ignorance about debuggers being a "line-by-line" tool. I usually use it to understand big codebases, by stepping through the functions in the order they are called, and I am quite sure there isn't some other way to tackle this requirement.

Those who say kernels should be debugged with print statements inserted into the code should promptly hand in their register and backtrace dumping functions, lockup detectors, memory allocation debugging, spinlock debugging, "magic sysrq key", ...

Oh wait; all of that is judiciously inserted print statements.

My gut reaction is that the article is nonsense but I think there's a very valuable point in it.

When you work mainly on enterprise code where you're unlikely to encounter any code you wrote, rather than another team member, on a daily basis you'll need a debugger or print statements.

But the reasonable point the article makes is a debugger makes it very easy to solve the problem localised to a function or a couple of lines of code rather than take the time to improve the whole area and/or add test coverage. But the other thing people who don't work on enterprise code won't necessarily understand is you don't usually have time to do that. So it's a good thing to keep in mind but it feels a little too Ivory Tower to be broadly applicable.

As a professional support programmer (read that: I have to debug code someone else wrote), I don't use debuggers often.

But sometimes I do. And when I do, I'm glad they're there, because they are a great tool of last resort.

Single-stepping is just one use for a debugger. Breakpoints are far more useful. Inspecting local variables by clicking through the stack is generally faster than adding print statements.

A lot of people also have never used a debugger that isn't terrible to use. Most debuggers fall into that category.

As for all of this "read the code first and get a better understanding" talk - this is obvious highfalutin' bullshit. You're human, you made a dumb mistake somewhere, the debugger will help you find it faster than your brain going on an excursion.

On a similar note: I once did a project entirely in notepad. This really forces you to write clean, readable, well organized code.

I don't have anything against debuggers. I do - however - have a concern with people who rely heavily on the find feature in their IDE to search for certain code they need to change. Oftentimes they don't look at the bigger picture and miss how certain things might better be implemented elsewhere. They don't run into the problem of finding code that's poorly structured. They don't have a need to restructure it.

A step-through debugger is a ridiculously useful tool when you don't have a serial console. Or when adding in tons of prints would violate timing constraints and compiling takes a significant amount of extra time compared to just restarting the device under test & moving the breakpoint until you find where things go wrong. Much nicer than having just a logic analyzer.

Of course embedded systems aren't the focus of the article, but they're all over and a very good place to have a debugger.

I debug sometimes, but if it's a simple script I'm working on, I usually don't. I'll just log where I think the problem is (usually indicated by an error, perhaps). I'll pull out the debugger when my best guesses at the problem aren't panning out.

Do whatever works for you. But it's good to have more tools in our toolbox - use puts debugging if that's easier (often is in very complex environments), use a debugger if you need to.

I never got comfortable with debuggers for the work that I do. Thus I rely heavily on "print debugging". There are tools such as "icecream" [0] (in Python), that improve print-debugging ergonomics a lot. I wish every language had something like "icecream" built-in.

[0]: https://github.com/gruns/icecream

I read this blog post in full and geez.

Since the author quoted Guido van Rossum, I'll share a recent anecdote from my interaction with Guido at PyCon. I first met Guido this past Wednesday, I'm guessing after he attended the Python language summit. He honestly seemed to be bristly at the time, probably because he's heard many of the same arguments raised over thirty years (I can imagine something like "hey why not get rid of the GIL" -> "Wow, why didn't I think of that?! Just get rid of the GIL!" although hopefully it was more higher-level than that). One of the other language summit attendees was talking about a particular Python feature, which I don't remember, but the underlying notion was that even if you get testy with contributors they'll still be a part of the community. I remember thinking, "No. That's totally not how it works. If you get testy with contributors they'll just leave and you'll never hear from them again, or you'll turn off new contributors and behead the top of your adoption funnel meaning your language dies when you do".

Python has such great adoption because it caters to the needs of its users first. Take the `tornado` web server framework. I haven't confirmed it myself but apparently it has async in Python 2 (async is a Python 3 feature). How? By integrating exceptions into its control flow and having the user handle it. But it shipped, and it benefited its users. IMHO, `pandas` has a decent amount of feature richness in its method calls, to the point where sometimes I can't figure out what exactly calling all of them does. Why? Because C/Python interop is likely expensive for the numerical processing `pandas` does and for the traditional CPython interpreter, and ideally you want to put together the request in Python once before flushing to C, and because people need different things and so need different default args. `pandas` also ships, and benefits a lot of people.

Shipping is so important in production, because it means you matter, and you get to put food for you, your family, and the families of people you employ. You can't just bemoan debugging is bad because somebody isn't a genius or not in an architect role. Debugging means you ship, and you can hire the guy who isn't aiming for a Turing Prize who may have a crappier job otherwise and he can feed his family better.

Don't cargo cult people you're not. Use a debugger.

Debuggers also double as an instant profiler. "Hmm, this program is running slowly, I wonder why..." -> gdb -p $PID -> a few random Ctrl-C's and c's -> finding the bottleneck and the state that led to it (which a real profiler won't usually tell you).

Also watches are invaluable when you know something is getting a wrong value but you don't know where.

Try reading the manual for Boto3 and writing code blind without being sure of the response format without just calling it first and looking at the response.

https://boto3.amazonaws.com/v1/documentation/api/latest/inde...

For the most part, C++, Go, TypeScript. At work I mostly write (micro) services or web UIs, and at home I do whatever (Tetris clones, small studying apps, utilities for reverse engineering, I’ve even done a couple Gameboy emulators in Go.)

Nope, just when necessary; usually I don’t read very much of the code. Intuition, comments, unit testing and editor help does the rest.

Well designed APIs are self explanatory.

No, what I am saying is that your definition of a bad API is one that you can’t intuit is a case of the “No True Scottsman” argument. The Boto3 API is well organized, it just covers a massive surface. It’s much easier just to call the API and inspect a real world response.

For instance, of course I know all of the databases instances in our AWS account, I read the Boto3 docs to see what API to call to return them, but it was much easier just to call the API and look at the response in the debugger to see the response than just guess from the documentation. The Boto3 module covers every single API for every service that AWS offers. Of course the API isn’t going to be consistent between S3 (storage) and DynamoDB (a no sql database).

And what’s the difference between using a REPL where you are running code line by line and using a debugger where you are running line by line?

On the other hand, why look through log files with print statements when you can just let the program run and set a breakpoint and look at the entire stars of your app including the call stack? But these days I wouldn’t even think about using a regular dumb text logger. I use structured logging framework that logs JSON to something like Mongo or ElasticSearch where I can use queries to search.

Heck even in my C days when I would make a mistake and overwrite the call stack, stepping through code and seeing where the call stack got corrupted was invaluable or seeing whether the compiler was actually using my register and inline hints by looking at the disassembly while the code was running.

The debugger is just another tool in the toolbox.

Turning a blind eye to one of your tools is disingenuous. Step by step debugging has its uses and some work environments may favor it. And in fact, I'm am quite sure that guys like Linus are competent in using them and will do when needed. It is just that it is not their favorite tool and it is not well suited too their project.

More pretentious and self-serving claims by academics and other “elite” programmers who are in reality far removed from frontline coding

So the argument is a debugger makes fixing bugs so easy you won't want to improve process?

I think I'll keep using them.

I work with embedded software. About a decade ago, when we switched to a new target processor with a JTAG interface (in-circuit debugging), my boss decided to buy an in-circuit debugger to help development. The target was an high-end (at the time) SoC, so it could run uClinux and we could also have GDB too.

I tried hard to use the hardware debugger because it was rather expensive (this is I think a case of sunken costs fallacy). Problem is, our system is soft real time; stepping in the main program causes the other things connected to the system notice that the main program does not respond, and act upon this.

The hardware debugger was quite capable so we had watchpoints and scripting to avoid this problem, but you had to invest considerable amounts of time to learn to program all that correctly. Amusingly, this was another occasion to make more bugs. Now you need a debugger to debug your debugger scripts...

Moreover, the "interesting" bugs were typically those who happened very rarely (that is, on a scale of days) - bugs typically caused by subtly broken interrupt handlers; to solve that kind of bug in a decent time frame with you would need to run dozens of targets under debuggers to test various hypothesis or to collect data about the bug faster. That's not even possible sometimes.

I also happen to have developed as a hobby various interpreters. The majority were bytecode interpreters. There again debuggers were not that useful, because a generic debugger cannot really decode your bytecode. Typically you do it by hand, or if you are having real troubles, you write a "disassembler" for your bytecode and whatever debugger-like feature you need. Fortunately, the interpreters I was building all had REPLs, which naturally helps a lot with debugging.

So I'm kind of trained not to use debuggers. I learned to observe carefully the system instead, to apply logic to come up with possible causes, and to use print statements (or when it's not even possible, just LEDs) to test hypothesis.

One should keep in mind that debuggers are the last line of defense, just like unit tests that will never prove the absence of bugs. So you'd rather do whatever it takes not to have to use a debugger.

My current point of view is that the best "debugger" is a debugger built inside the program. It provides more accurate features than a generic debugger and because it is built with functions of the program, it helps with testing it too. That's a bit more work but when you do that functionality, debugging and testing support each other.

Often when dealing with layers of code that I am not familiar with, the debugger helps.

But when there is a bug in code I wrote, I can reason about it and place prints where I need them. For side projects I hardly ever use a debugger.

I do 99% of my development in the chrome debugger. I usually step through every line of code for the first run through. It catches an incredible amount and variety of subtle bugs. Printf debugging is for chumps.

Bart Locanthi wrote the debugger for the BLIT (Bell Labs Intelligent Terminal) and named it joff because most of the time you’re in a debugger you’re just ....

A lot of this is appeal to authority. It seems to be a contribution to a growing sort hip- or leet-ness around not using debuggers. Implicit in this seems to be: I don't need a debugger, neither do these famous people, why do you? Aren't you tough enough or smart enough like me and these famous people? You're clearly doing this programming thing wrong.

Well, I use debuggers. I think they're great tools. My feeling is that I'm very happy to use any tool that helps me create, understand, and improve software. When people tell me that a tool that is useful to me in that endeavor is not actually useful, all I can think to do is roll my eyes.

Having said that, something I am very interested in is learning new approaches to interrogate software complexity and solve problems. So, "here are some approaches to understanding and debugging code that have worked for me" from someone who doesn't use debuggers would be interesting to me. But I actually don't see any of that here.

To heck with that. Ever use a gdb watchpoint? Amazing feature that's saved my bacon more times than I can count.

I think print statement makes it quicker and obvious to expose the internal state I want to observe at the precise point I want, thus fulfilling the hypothesis cycle faster. Debugger, on the other hand, seems effort taking to set up and expose too much additional details, it becomes overwhelming very quickly.

Just "test first"; TDD your code. I'm so tired of working with and being surrounded by crappy, uncontrolled codebases.

We "control" our code when tests prove it does what we think it should.

Debuggers are rarely-usable, inefficient tools for software development. I agree with OP, debuggers don't scale.

The debugger is a valuable tool. I don’t not use X. It is meaningless.

I also lie in my headline:

> there are cases where a debugger is the right tool

Would you get the job if you said that at a job interview?

I use whatever tools I can to solve the problem.

I think while this article doesn't really prove its thesis very well there is a kernel of an idea here which is useful to investigate. That is the idea that line by line stepping is a crutch that weakens the programmer.

Out of the 5 beliefs he quotes from celebrities we only have reasons for 3. Of those 3 the common thread I see is that we should be able to reason about our code and debuggers act to derail that. Furthermore, it appears that the aspect of debugging most being maligned here is stepping through code line by line. I'm fairly certain that is specific to a certain type of mindset. If I was writing a title for a talk in this area it might be more like "single stepping bad for students" and then talk about how to build code that is easy to model and think about and then use that to work through most problems. If you've got yourself past that student part (and yes, you'll dip back into this with new tech / languages) then being able to single step when it makes sense (don't have docs, processor isn't doing the right thing, etc.) makes you more powerful. Not less.

The focus on printing is a bit annoying. The writer seems to have never worked in embedded systems, distributed systems, or systems where reproducing the bug isn't an option. In the last case a debugger is your tool for grunging around in a core dump. In the embedded case some type of debugger or forcing a core dump (and thus using a debugger) might be your only choices.

I also question if he has ever worked on web systems. Reasoning "harder" about how some new CSS or javascript "feature" behaves across different browsers is useless. Writing little ad hoc uses (maybe in a debugger) and carefully tracking how they act in a debugger is powerful.

A lesson from my history is that of systems that take a long time to build and upload. The one I worked on early took 60 minutes to build and 30 minutes to upload to test hardware. You didn't fix bugs one by one. You fixed them by discovery, fixing on the platform (inserting nops, etc.) in assembly while replicating that in source (probably kicking of a build in case that was the last bug of this run), and then continuing to test / debug and get every little bit you could out of the session. And if you had to single step then that was worth it. Is this entirely a historical artifact? I havn't worked with anything that bad in decades but I still work with embedded (and some web) systems where the time to build and upload can be a minute to minutes. Getting more out of the session is useful and debuggers are part of that.

Refactoring as a response to a bug seems like a mistake worse than line by line stepping to me. Not understanding a cause but making a change propagates incorrect thinking about the system.

But I think the real missing part of this article is a discussion of what are other useful tools. The last comment in the article mentions "Types and tools and tests". It is easy to say tests are table stakes but a similar article about testing would create a flamefest so it is a bit hard to tell what kind of table (or is it stakes)? So what are those tools beyond testing? I'd love to have DTrace everywhere I worked. The number one best tool I've ever seen for working with a live system. The ideas in Solaris mdb about being able to build little composable tools around data structures is awesome. Immutable methods of managing databases are wonderful. It would have been nice if this author talked about design and refactoring "tools" (could be methodologies) he liked or thinks should exist.

This reminds me of the more generalised "I do not use IDEs". It's a fascinating kind of phenomenon similar to ludditism to me where programmers reject the very premise of their own existence: that computers are capable of adding value or assisting with a task. It feels to me that this is its own form of dogma, no better justified than people who lean on the IDE or the debugger to do everything.

I don't pull out the debugger very often, but knowing how and when to do that, and do it well is a significant tool in my arsenal. There are times when I can guarantee you I would have spent a massive number of hours or maybe never properly resolved certain bugs without doing it.

The opinions stated are incompetant.

The thing is, your imagination of what I’m doing (littering code with printf statements) and the actual reality of what I'm doing (solving AT LEAST 95% of my problems using extensive automated tests, strong linting, strict typechecking, and modern programming practices) is leagues apart. When I say I break out the debugger around every few months, I am not exaggerating. I may insert a printf or two once every other week. This is not the common case, it’s just significantly more common for me than attaching a debugger, because it’s quick and easy.

The practice I adhere to is to break code up into small modular bits then unit test the living hell out of those bits, then integration test larger combinations. Maintaining test code takes time, but I take it very seriously. I can’t share any of my actual work at Google but I can share my open source work; a project that I wrote this way is Restruct and it normally has around 98% line coverage. If someone finds a bug I add a new test. I have never used a debugger on Restruct or projects built on Restruct.

So then, what do I do all day? Console.log and printf everything? No, honestly no. I spend little of the day debugging because unit tests tell me nearly exactly what codepaths I broke, printing out helpful diffs of the expected behavior versus the actual behavior. This almost always gives way to the problem, even when I’m working on a brand new piece of code with tests I just wrote (sometimes before the code, even.)

So I would say printf is my goto debugging tool, but if I want to be accurate, it’s probably really automated testing. Automated testing used in this fashion basically acts as small little debug routines. We don’t call tests debugging tools though, because that would undermine their usefulness; they do so much more. Which is why I don’t sweat it when I have just as much or more test code than actual code; unlike other code, it often pays for itself if you do a good job.

And besides, if unit tests explain a bug to you before you actually run into it, did you really do any debugging or did you bypass it entirely?

GDB and LLDB allow you to put a print statement anywhere; they’re a strict superset of what you can do in code.

Alternative to what?

I guess we are implying different objectives here. To convince someone, appeal to authority might be quick effective. But I don't care about convince you or anyone. I care about reasoning. So I show you how I debug, and I say something about my reasoning behind it, and I also think I understand how someone would not work and think the same way as I do. What results I am seeking? If you find there is flaw in my reasoning, blind spots in my thinking, point/comment back to me, it is an opportunity for me to improve. If you find my reasoning makes sense, but the conclusion does not, feedback to me and I may also improve. If you fully agree with me, I may get a boost in my ego. The last one is in my instinct, but I am not sure I really want that.

I will, however, most likely argue back for the potential feedback. Only through arguing back and forth, I truly can understand the feedback and morph into a form that I can use to improve. I often do improve my reasoning even there is no conclusion for the argument yet. It is easy to gain when background and reasoning are provided. So I always provide them, hopefully who ever participates also gain.

I didn't assume that dynamic languages are more concise. I only said that each of both (with the addition of interpreted languages) usually require less tooling and less to keep in mind than their respective opposite

How much you need autocomplete and refactoring to be reliable also depends on your situation (language/framework, app structure and number of contributors).

More people use IDEs with dynamic languages because Visual Studio Code now exists so people who always prefered IDEs now have a good option

>No authority told me to use a debugger, I use them because they work for me. They save me time, help me make money, and make it easier and more fun to code.

Well, I already wrote: "Few things in development are not based on idiosyncratic preferences, fads, snake oil salesmen, tradition, or appeals to authority". So your case would fall under the first option: it's an unscientifically tested personal preference.

>If I ever saw a "research study" that said "print statement users have 12% fewer bugs than debugger users" - or vice versa! - I would dismiss it out of hand. What possible relevance could it have to my work?

It could have all the relevance in the world.

It's not like if you believe strong enough that your preferred methods are the best (or the "best for you"), that you can't still be using an objectively worse method and get worse results...

>And nothing has to be "settled", nor should it be.

Well, if software development wants to be like an engineering discipline, many things should be (studied and eventually settled).

"Works for me" and letting developers improvise and come with their own hodgepodge of practices, preferences, and cargo cults, is how we got into this mess.

>I use debuggers because they are useful to me, not because I of quotes about them from famous programmers.

Which is an equally fallacious reason to use them (scientifically wise) as appeal to authority.

"Useful to me" doesn't mean anything by itself. Something else could have been more useful to you, but without measuring it appropriately (just some personal anecdotes with trying some thing and then another and seeing which you prefer or which seems to you to give you better results, with no real measuring system or rigor), you'd never know. And the industry would never know which direction to invest, and how young programmers should be taught best -- not just about debuggers but about almost everything.

How about 'state inspector?' This is, of course, exactly what this article proposes doing with "print" statements, but print is a paltry state inspection tool compared to them, ahem, debuggers to which we are accustomed.

Yet the most prevalent tests these days for SE are based around the old problems. Then again these tests are less about how good of an engineer you are and more of how submissive you are.

That was my dad. He eventually wrote the first Pascal compiler in North America, to tame the pdp-11.

It's easy to see this as a wrong opinion when computers are extremely cheap and fast. Was von Neumann wrong about computers being more expensive compilation tools than grad students at the time?

My experience is the EDI and debugger depedent programmers have a very hard time when those things are taken away or unavailable. The reverse is not true.

If you don’t use your brain first you’re not a good professional. Any other tool isn’t as important.

> I use print statements, but seriously, what's the difference? You use watch points in the debugger. Same thing. Once I have tests I find it easier to run them and look at the output of my prints as opposed to stepping through the code.

Maybe I have been spoiled by Visual Studio but as you said there are plenty of options in the debugger for winding back execution, changing execution, inspecting Objects, inspecting the state of the stack at the time, I can debug other people's assemblies, I can debug machines remotely.

Writing out to the console / log is my last resort.

> Stepping through the code requires you to remember what you have done before and what the output was (granted debuggers that allow you to go backwards are helpful).

No it doesn't require you to remember what you have done before. Even relatively basic debuggers such as the JavaScript debuggers in most browsers have a stack trace with what has been called where.

>If you can do that, then it's all good, but I find that it's easier for me to essentially create a log and read through it. It's just a bit more structured, but in the end it's exactly the same thing.

I don't understand why you would claim an inferior tool is better when a far superior one is available. It would like saying that a Impact Wrench / Spanner and a Spanner are the same thing, technically they both undo bolts, however one makes it far easier than the other.

> "Thinking hard" is about trying to isolate the problem. RMS famously said that you should try to only debug the code that is broken rather than trying to debug the code that isn't broken (this is especially true in big systems). Where is the error happening? How are these things connected? Etc, etc. When you write very tight unit tests around the sections of the code, you have to do exactly the same thing (and I would argue that writing those tests is a good tool for "getting into" the code).

Except it doesn't help you find the code. With a debugger I can stick in some breakpoints where I think the code is going to get hit and then walk myself back from there on what is called and in what order. I work with some terrible systems where it isn't obvious how the code is even executed because "senior" developers have abused IoC / DI, Reflection and Delegates in such a way to obscure what it is actually doing.

As for writing Unit-tests around sections of code. In quite a few areas I have been barred from doing it (for political reasons) and other times you realistically can't because your test setup would be just too complicated.

> Single stepping is fine when you've got 100 lines of code, but when you have thousands or millions of lines of code, it's not going to work

Yes it does work. I did it on Friday. I stick a break point on the entry point (in this case an ASP.NET MVC controller) and F10 and F11 my way down through the stack. I learned more doing this for 30 minutes then I did the previous 2 hours of looking at how the project was structured.

This "think harder" is akin to telling a man to dig harder with a shovel when they have a JCB excavator sitting round the corner.

I assume you meant an unmaintainable mess, and not a maintainable mess, but nevertheless, debuggers are not the cause.

You get messy code at least as quickly without a debugger, possibly even faster since bug fixes in my experience tend to be even more shallow, in many teams.

The values of the management, the values of the team, and resource availability is what matters in regard to writing, and keeping code maintainable.

I've worked with people who have had a similar idea, that using debuggers are somehow "bad", I have also had to rescue them by using a debugger to understand issues with code they had struggled to figure out for days, or even weeks, meanwhile causing severe issues for clients.

When you claim tools as the cause for your mistakes, then it could certainly be the case that the tool is of bad quality, which clearly is not the claimed issue with debuggers in the article. More likely though is that you haven't really learned when, and how, and why to use the tool.

Debuggers are brilliant for validating if you mental model of the code is correct, or more commonly, to understand how it's wrong. This can have a side effect of solving bugs, especially bugs in your own thinking

"Maintainable mess" is the apotheosis of every human endeavor.

> Some cases where your imagination could be limited are:

> - Code that you didn't write.

This has become the norm with software written by a team; and to my stress, I find many coders have given up understanding code that other people wrote and reduce to the minimum that get by. My premise is the necessity of understand the code -- not only how the code work, but also how the code is conceived and where the code is evolving toward. After that premise, there is no difference between code that you didn't write or you did.

> - Code that you wrote long enough ago that you don't remember the details.

That says a lot that the code was not written in its optimum way. Treat that as a bug, and debug why the details cannot be easily retrieved.

> - Code that you know very well, but you're having a bad day and can't figure out the problem just by thinking about it.

You should always take a rest and tackle it the next hour or next day when you can work effectively. Continue to push through a bad day only has the opportunity to make the day worse.

Did I say "always"? If I did, that is not the point.

So now you have the rule book and the comments and if there is a bug in any of the code, an I suppose to remember what all the code does and think through it? Am I suppose to be able to just think through why the one set of hundreds of records that came from one of 200+ repair yards is giving back erroneous results or should I just use a debugger and set a conditional breakpoint?

It makes sense to use a programming language for the rule logic. I'm just suggesting you need to conceptually separate the software code from the rule code. Have the rule code in a separate repository that can be deployed independently (by people with different roles). You can't just deploy new code. You'd perhaps want to apply previous versions of a rule.

In any case. The people maintaining/using the rules might not have a debugger available. They still need to have some kind of "rule stack trace" on how the system came to a certain answer.