Coding in the Debugger (2007)
tidyfirst.substack.com
Coding in the Debugger (2007)
1–10 of 32 posts
Re: Coding in the Debugger (2007)
#2This is debugger driven development
In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly.
Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc.
Once you try this you'll never want to go back to print-debugging (except for specific cases)
Re: Coding in the Debugger (2007)
#3This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)
sometimes though when debugging multithreaded code, tracing/logging is easier to figure out what's going on vs pausing on breakpoints.
Re: Coding in the Debugger (2007)
#4This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)
sometimes though when debugging multithreaded code, tracing/logging is easier to figure out what's going on vs pausing on breakpoints.
>(except for specific cases)
Exactly, that's what I meant
Re: Coding in the Debugger (2007)
#5When I was young, we programmed in the debugger all the time! And we liked it!
https://everything2.com/title/Writing+.com+files+with+DOS+de...
Re: Coding in the Debugger (2007)
#6Earlier quoted context omitted.
sometimes though when debugging multithreaded code, tracing/logging is easier to figure out what's going on vs pausing on breakpoints.
>(except for specific cases) Exactly, that's what I meant
I just remembered the Tracepoint feature though (it's been a while since I was working in C++ with visual studio). Even when you can't pause execution to debug it's still better to add your tracing in the debugger rather than having to make code changes.
I was always doing stuff on windows/macOS/iOS/Android client libraries so I was always jealous of linux systems programmers who get to leverage Mozilla's rr tool. That's the coolest debugging tool I've ever seen.
Re: Coding in the Debugger (2007)
#7Earlier quoted context omitted.
>(except for specific cases) Exactly, that's what I meant
I just remembered the Tracepoint feature though (it's been a while since I was working in C++ with visual studio). Even when you can't pause execution to debug it's still better to add your tracing in the debugger rather than having to make code changes. I was always doing stuff on windows/macOS/iOS/Android client libraries so I was always jealous of linux systems programmers who get to leverage Mozilla's rr tool. Th…
Sadly rr cannot work on software that makes any kind of call to GPUs, so its usefulness is pretty limited on a lot of larger software. But when it's usable, imo it's amazing.
Re: Coding in the Debugger (2007)
#8And this, boys and girls, is why you want to use a real IDE with an integrated debugger.
Re: Coding in the Debugger (2007)
#9This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)
sometimes though when debugging multithreaded code, tracing/logging is easier to figure out what's going on vs pausing on breakpoints.
Which is also supported in IDE debuggers.
Re: Coding in the Debugger (2007)
#10Earlier quoted context omitted.
>(except for specific cases) Exactly, that's what I meant
I just remembered the Tracepoint feature though (it's been a while since I was working in C++ with visual studio). Even when you can't pause execution to debug it's still better to add your tracing in the debugger rather than having to make code changes. I was always doing stuff on windows/macOS/iOS/Android client libraries so I was always jealous of linux systems programmers who get to leverage Mozilla's rr tool. Th…
Tracepoints are supported in C++ and .NET, the JVM also has them, although the form depends on which implementation is being used.
Naturally similar stuff also exists in Smalltalk and Common Lisp environments.