6 ms·

This seems very much inspired by the `dbg` macro recently introduced in Rust. [1] Which in turn was inspired by Haskell s `Debug.Trace` functions [2]. It's de

This seems very much inspired by the `dbg` macro recently introduced in Rust. [1] Which in turn was inspired by Haskell s `Debug.Trace` functions [2]. It's definitely a convenient tool if you can't use a debugger or want to follow more complex interactions. [1]https://doc.rust-lang.org/std/macro.dbg.html https://doc.rust-lang.org/std/macro.dbg.html [2] https://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-Trace.html https://hackage.haskell.org/package/base-4.12.0.0/docs/Debug...

KenanSulayman 7y ago
Thanks for the Rust reference, I was hoping this exists for Rust. Very useful for everyday debugging!
masklinn 7y ago
> Which in turn was inspired by Haskell s `Debug.Trace` functions [2]. According to the RFC, the only inspiration from Debug.Trace was returning the input. The only other mention of haskell in RFCs 2173 and 2361 is the rejection of `show!`.
- the_duke 7y ago
  The author of the RFC was a big Haskell user and mentioned that idea came from there. You can't learn everything from official documents...
  - masklinn 7y ago
    That might be true but I'd still want a source on that because the assertion makes no sense: aside from the value-returning property, all the overlap between dbg! and Debug.Trace is already covered by println!. And as far as I can see Debug.Trace doesn't contain anything like dbg!: the closest would be traceShowId, which neither shows the traced expression (before evaluation) nor the location information.
    - the_duke 7y ago
      > but I'd still want a source on that Why don't you commence a formal inquiry, analyze the complete discussion history, acquire a sworn statement from Centril and report your findings here? It seems weird to get so hung up on the word inspired... but I'm looking forward to the report!
      - deleted 7y ago
        [deleted]
xtreak29 7y ago
Python 3.8 has similar feature for f-strings : https://bugs.python.org/issue36817 https://bugs.python.org/issue36817 print(f"{name=}") expands to print(f"name={name}")
- chrismorgan 7y ago
  Rust’s `dbg!()` macro also includes the source file name and line number; this C++ `dbg(…)` macro looks to add source file name, line number and function name.
  - xtreak29 7y ago
    I proposed the idea but the debugging notation seemed to serve a different audience : https://discuss.python.org/t/filename-and-line-number-in-f-string-debugging-output/1650/ https://discuss.python.org/t/filename-and-line-number-in-f-s...
    - giancarlostoro 7y ago
      Wow I had no idea you could do that with the logging class. I agree it would be smarter to be able to at least have a flag for that to print the rest. Overall I prefer logging to print. I do think you are right though: if you are trying to debug it is useful to know the line not just a variable name. Now you gotta add garbage to say hey this was from this method and line...
sharkdp 7y ago
Yes, it is definitely inspired by Rusts `dbg!(..)` macro (see bottom part of the README). A lot of my open source projects are written in Rust and I really liked the idea of the `dbg!(..)` macro, so I wanted something similar for my work in C++.
- the_duke 7y ago
  Ah, I missed that reference at the bottom.
solinent 7y ago
Debuggers are practically useless for me, they aren't complex enough to meet my minimum use-case. If I use a debugger--approximately two hours wasted if I'm completely unaware where the problem is. If I instead try to spend ten minutes logically explaining the program, usually I fix the problem and also gain a deeper understanding of the mechanics of the program. The program is usually multi-threaded, real-time. A debugger gives you the state of the entire program, and one point in time. A log allows you to focus, which gives you the state you actually care about, at all the points in time where you care about it. The time-evolution of the state of the program is practically the only thing I'm interested in. I find that code that has been written mainly with debuggers is often full of tons of errors, often simple negations which have been worked around an even number of times. Then you're stuck with the debugger, and there's no way to reason about the program. The result is low quality.
- pcr910303 7y ago
  > If I use a debugger--approximately two hours wasted if I'm completely unaware where the problem is. If I instead try to spend ten minutes logically explaining the program, usually I fix the problem and also gain a deeper understanding of the mechanics of the program. Er.... I’m pretty sure debugger advocates aren’t advocating using debuggers without logical thought. Usually, it’s more about that debugger is a useful tool when one spends three hours logically explaining the problem but can’t figure it out. If you can find all kinds of bugs in ten minutes, then great! You’re officially an endorsed 10x programmer. :-) I can’t, for some bugs, (reproducing bugs in complex programs is a difficult hurdle for me too) so I use a debugger. > I find that code that has been written mainly with debuggers is often full of tons of errors, often simple negations which have been worked around an even number of times. Usually, I find that code that is thoughtfully written and extensively debugged in the debugger is the most robust part of the program, but YYMV.
  - solinent 7y ago
    I'm not a 10x programmer, I just spend the time you spend debugging logging. And if I'm correct it's slightly less time than you spend debugging. > Usually, I find that code that is thoughtfully written and extensively debugged in the debugger is the most robust part of the program, but YYMV. Have you ever worked in a code base that is thoughtfully written but not extensively debugged? I'd wager they're pretty rare because of this extensive widespread use of debuggers, but perhaps these code bases are even more robust, since in my experience they're more thoughtfully written. Preconditions and postconditions everywhere!

KenanSulayman 7y ago

Thanks for the Rust reference, I was hoping this exists for Rust. Very useful for everyday debugging!

masklinn 7y ago

> Which in turn was inspired by Haskell s `Debug.Trace` functions [2]. According to the RFC, the only inspiration from Debug.Trace was returning the input. The only other mention of haskell in RFCs 2173 and 2361 is the rejection of `show!`.

the_duke 7y ago
The author of the RFC was a big Haskell user and mentioned that idea came from there. You can't learn everything from official documents...
- masklinn 7y ago
  That might be true but I'd still want a source on that because the assertion makes no sense: aside from the value-returning property, all the overlap between dbg! and Debug.Trace is already covered by println!. And as far as I can see Debug.Trace doesn't contain anything like dbg!: the closest would be traceShowId, which neither shows the traced expression (before evaluation) nor the location information.
  - the_duke 7y ago
    > but I'd still want a source on that Why don't you commence a formal inquiry, analyze the complete discussion history, acquire a sworn statement from Centril and report your findings here? It seems weird to get so hung up on the word inspired... but I'm looking forward to the report!
    - deleted 7y ago
      [deleted]

xtreak29 7y ago

Python 3.8 has similar feature for f-strings : https://bugs.python.org/issue36817 https://bugs.python.org/issue36817 print(f"{name=}") expands to print(f"name={name}")

chrismorgan 7y ago
Rust’s `dbg!()` macro also includes the source file name and line number; this C++ `dbg(…)` macro looks to add source file name, line number and function name.
- xtreak29 7y ago
  I proposed the idea but the debugging notation seemed to serve a different audience : https://discuss.python.org/t/filename-and-line-number-in-f-string-debugging-output/1650/ https://discuss.python.org/t/filename-and-line-number-in-f-s...
  - giancarlostoro 7y ago
    Wow I had no idea you could do that with the logging class. I agree it would be smarter to be able to at least have a flag for that to print the rest. Overall I prefer logging to print. I do think you are right though: if you are trying to debug it is useful to know the line not just a variable name. Now you gotta add garbage to say hey this was from this method and line...

sharkdp 7y ago

Yes, it is definitely inspired by Rusts `dbg!(..)` macro (see bottom part of the README). A lot of my open source projects are written in Rust and I really liked the idea of the `dbg!(..)` macro, so I wanted something similar for my work in C++.

the_duke 7y ago
Ah, I missed that reference at the bottom.

solinent 7y ago

Debuggers are practically useless for me, they aren't complex enough to meet my minimum use-case. If I use a debugger--approximately two hours wasted if I'm completely unaware where the problem is. If I instead try to spend ten minutes logically explaining the program, usually I fix the problem and also gain a deeper understanding of the mechanics of the program. The program is usually multi-threaded, real-time. A debugger gives you the state of the entire program, and one point in time. A log allows you to focus, which gives you the state you actually care about, at all the points in time where you care about it. The time-evolution of the state of the program is practically the only thing I'm interested in. I find that code that has been written mainly with debuggers is often full of tons of errors, often simple negations which have been worked around an even number of times. Then you're stuck with the debugger, and there's no way to reason about the program. The result is low quality.

pcr910303 7y ago
> If I use a debugger--approximately two hours wasted if I'm completely unaware where the problem is. If I instead try to spend ten minutes logically explaining the program, usually I fix the problem and also gain a deeper understanding of the mechanics of the program. Er.... I’m pretty sure debugger advocates aren’t advocating using debuggers without logical thought. Usually, it’s more about that debugger is a useful tool when one spends three hours logically explaining the problem but can’t figure it out. If you can find all kinds of bugs in ten minutes, then great! You’re officially an endorsed 10x programmer. :-) I can’t, for some bugs, (reproducing bugs in complex programs is a difficult hurdle for me too) so I use a debugger. > I find that code that has been written mainly with debuggers is often full of tons of errors, often simple negations which have been worked around an even number of times. Usually, I find that code that is thoughtfully written and extensively debugged in the debugger is the most robust part of the program, but YYMV.
- solinent 7y ago
  I'm not a 10x programmer, I just spend the time you spend debugging logging. And if I'm correct it's slightly less time than you spend debugging. > Usually, I find that code that is thoughtfully written and extensively debugged in the debugger is the most robust part of the program, but YYMV. Have you ever worked in a code base that is thoughtfully written but not extensively debugged? I'd wager they're pretty rare because of this extensive widespread use of debuggers, but perhaps these code bases are even more robust, since in my experience they're more thoughtfully written. Preconditions and postconditions everywhere!