Hacker News Reader

Comment by julik | Hacker News Reader

For most modern languages, something like an @internal annotation would work better. With compiled languages that need to conform to an ABI or export RPC definitions, there is merit to specifying what exactly must be exported (or must never be inlined), but even that could be tackled by an @internal or @nodoc or @private annotation - not a language construct.

View on HN

That would be fine if the annotations were standardized. But if the annotations are standardized, then they might as well be a direct language feature.

It's a bit different. You'd expect to be able to have your tooling ignore the annotations and everything should "just work" which eases debugging. Annotations are generally expected to be useful for things like linting, optimization, and documentation (ignoring language extensions that change the semantics of course).

> You'd expect to be able to have your tooling ignore the annotations and everything should "just work" which eases debugging.

I'd expect any language that uses annotations to have a fairly-complete reflection capability. I'd also expect a good debugger to be able to use that to permit me to read, modify, and call methods and members marked as 'private'.

It has been decades (so perhaps my memory is incorrect), but I remember being able to access private parts in C++ debuggers. If this was true way back when for C++, I expect it to be a common feature now in debuggers for languages that have reflection & etc.

> in C++ debuggers

An awful lot of my debugging is done without a debugger. I generally expect a language to permit me to do anything that can be expressed in a logically coherent manner even when I would clearly be shooting myself in the foot. I also expect a bright neon sign warning me not to proceed.

I quite like python in that regard. You can monkey patch just about anything even when you really shouldn't.

My point is that even C++ (a language that somewhat-famously lacks built-in support for reflection) has tooling to access and run non-public parts of the program.

"I don't like making functions, methods, and members nonpublic because how would I access them when debugging?" simply isn't a credible complaint when applied to most mainstream languages.

    > An awful lot of my debugging is done without a debugger.

I would like to hear more about this. What are the alternatives? printf? To me, nothing beats a good debugger.

Suppose we can compile and execute our code at such a speed that a given line of code will be executed the very instant after we press run. In this case, a choice printf line will execute at the same speed as typing print in our debugger. The benefit of the printf line is that we are in effect scripting our debugger to print some data every time that line is reached, without having to type it over and over. For one thing, this allows us to more easily go backwards in the execution, since we are really rerunning the program from scratch each time. We can also much more easily execute a whole litany of prints, which we can then scan for some expected data. The advantage of the debugger remains in the first place in languages that lack strong compile time reflection, such that only the debugger can reliably print the data we want to see, and in the second place in the myriad instances where we cannot get the compile+execution speed down to an acceptable time. I suppose debuggers are also useful when you have a core dump you want to analyze. Besides that I would consider the printf strictly superior.

Adjacent comment pretty much explained it. Sometimes it's printf, sometimes it's subtle tweaks to program behavior in strategic places, sometimes it's adding asserts (that might very well call functions not intended for public consumption).

I always start debugging by coming up with a theory about why the observed behavior occurred. The fastest way to validate that is generally one or two tiny changes to the program.

I only break out the debug tooling for the serious stuff that has me scratching my head in confusion. Either because the behavior has me thinking "there's no way that's possible" (spoiler: almost always memory corruption) or because I'm segfaulting in a shared library that I didn't compile or because I'm well into some obvious badlands with concurrency or memory corruption or the like.

What are your primary languages? Even in 2025, C & C++ debuggers are light years ahead of 15 years ago. And Java / DotNet debuggers are mind-blowing they are so good, plus "memory corruption" isn't possible (that I know) in vanilla code that runs in a VM. I almost never bother with your techniques anymore.

Reply on news.ycombinator.com