[double051]

> Not having a debugger is actually a liberating experience because it forces you to code in a different way.

Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.

[jdreaver]

I used to always use the VS debugger when I used C# in school (my research lab used C#). Now, I use Python and C for work, and I never use a step debugger. For some reason I just don't miss it, and using print statements is just fine.

This is especially true in multithreaded code. I do a lot of Qt programming, and everything tends to be executed in an auxiliary thread.

I will say that I like step debuggers that come along with a REPL. This is probably the one and only thing I like about Matlab.

Lastly, I program in Haskell for fun (enough at least to write a small unit conversion library [1]). Because of laziness, I find the step debugger impossible to use. I definitely rely on print statements in Haskell.

[1] https://hackage.haskell.org/package/quantities

[varkson]

I know what you're getting at.

At home I develop with C# and use the debugger all the time. However, I'm a PHP dev at work and we can't connect to our dev server with debuggers. We have all sorts of various tools we built for getting around it, like dumping objects to email and so forth. Although I kinda miss a step debugger at work I've got enough tools to deal with it, even if it's a bit slower sometimes. In other cases it's kinda freeing in a strange way.

[_random_]

Some developers need forcing I guess. I personally like many options: debugging, strong typing, static analysis, automated refactoring, unit tests, integration tests, tracing, logging, design-by-contract etc.

[pjmlp]

Fully agree. Some developers like to live in green phosphor vt100 days.

[seanmcdirmid]

80 column wides and fixed width fonts are completely left overs from vt100 terminals.

[bnolsen]

reliance on debuggers is a wierd strange concept. Debuggers are utterly incapable in multithreaded environments. Just write damn unit tests and simulations!

[bunderbunder]

Depends on the debugger, really. One thing the Visual Studio team's been doing lately that I appreciate is working on improving their multithreaded debugging story. Nice visualizations for keeping track of parallel call stacks and whatnot. The actual step debugger itself still leaves much to be desired - the UI doesn't give you a lot of help with keeping track of when a context switch happens, for example - but even there it's not utterly incapable.

[waps]

When was the last time that a unit test caught a race condition ? When was the last time a unit test caught a contract violation (one subsystem doesn't agree with another about the semantics of a piece of data) ? When was the last time a unit test caught the use of an O(n^large number) algorithm in a production system ?

Unit tests verify if the programmer's understanding of the code matches reality.

That's all. Not saying it's useless, but a) it's at best a start of proper testing, b) insisting on coverage is beyond useless.

What is needed is a test if the programmer's understanding of the problem is up to par. Since that's impossible, let's go with the programmer's understanding of the whole program : system and loadtests.

Unit tests, while useful for TDD for "fiddly" code, are useless to guarantee correctness of an application. System tests are better. Proper type system abstractions are best.

[jonathanoliver]

Funny you mention that, as the author of the blog post in question, I'm basically inside of a green-phosphor command line most of the time. I've got my cursor set to block and it doesn't blink.

[jonathanoliver]

Coming from C#, when I originally started using a language that didn't have a debugger I thought I would miss it. But I found that I'm more deliberate about my code because the debugger isn't there for me to fall back on.

[seabrookmx]

> I found that I'm more deliberate about my code

So your code never has bugs?

Any production piece of software is going to need debugged at some point. Sure, a step-through debugger like the one in VS isn't the only way to debug, but it sure as hell is one of the more intuitive ways.

Being able to expand objects and see their state etc. is extremely powerful and shouldn't be shrugged off as a nice-to-have.