4 ms·

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 defini

• rerdavies 1y ago
  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.
  • fc417fc802 1y ago
    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).
    • simoncion 1y ago
      > 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.
      • fc417fc802 1y ago
        > 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.
        • simoncion 1y ago
          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.
        • throwaway2037 1y ago
          > 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.
          • bmandale 1y ago
            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.