Hacker News Reader

Comment by xnorswap | Hacker News Reader

This is why I enjoy writing C#/.Net, I don't need to deal with nonsense like print debugging.

I don't think I'd be anywhere near as productive without:

   - Conditional breakpoints
   - Debugger.Launch 
   - Debugger.Break
   - Debugger.Write

Conditional breakpoints are essential, just run as normal and it'll only break when your bizarre edge case is hit.

Debugger.Break and Debugger.Launch are like a breakpoint that gets hit even when you're not debugging, and prompts you to attach a debugger. ( Launch won't pause if you already have one attached, but especially useful when you want to attach to a start-up routine in an IIS hosted web-app. )

Debugger.Write writes to a different output stream, and like all Diagnostic.Debug statements, isn't even compiled into release builds, so there's zero chance of it ending up in prod.

These are essential tools for rapid debugging. Printing nonsense and hoping to spot it feels 20+ years out of date.

View on HN

There are endless numbers of cases where you can still end up having to just resort to print debugging, even in C#. Race conditions are a great example.

you can configure the breakpoint to log stuff to the console, instead of breaking

Real question: Does Java have equivalent methods? I have never seen them.

Get off your .NET high horse. Every reasonably mature language has powerful debuggers.

Well indeed, I could have said, "this is why I enjoy working in a mature environment". .NET just happens to be my experience.

The point I was trying to make is that you shouldn't be print debugging in 2024.

Unfortunately it is not always possible to debug for a myriad of reasons

Yawn. I’m all but certain that all the environments in these “print debugging fail” stories have debuggers. The fact that generation after generation of programmers fall into print debugging, despite there being “no reason” to do it in many contexts for…decades at this point, should tell you that you’re missing something, not that everyone is dumb except for you.

I'm not saying people are dumb, I'm saying we've failed to provide good dev UX for debugging, so that people find it easier to reach for print debugging than leverage their debugger.

It's also clear I got the tone of my original post wrong, I was always trying to make this point, not some point scoring "I'm better because I use X".

FWIW I didn't get the feeling at all that you were trying to come off as superior because you use .NET and its debugger.

Does the GP comment claim that other languages cannot have similar quality of tooling? Why reply with a swipe?

I wish it was true

My experience in cpp is 5 times worse than in .net

I still haven’t found a good way of debugging async code that also has timing restrictions…

.., the world runs off print statements sprinkled throughout by a very frustrated and angry developer

Cool story bro. Let me tell the guys at work that we should just run .NET on our multi-core digital signal processors.

And we should also teach them not to get their delicate timing out of whack because they'll immediately stop dropping incoming samples if any of them gets interrupted by a debugger.

I'm sure everyone will be delighted.

Reply on news.ycombinator.com