Its funny, as I am still not good at step debugging in lisp, but https://malisper.me/debugging-lisp-part-1-recompilation/ is a great example of basically the same concept there. Really, that whole series was amazing fun to read through.
Coding in the Debugger (2007)
11–20 of 32 posts
Re: Coding in the Debugger (2007)
#12This 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)
the power of debugging in interpreted languages is so far unbeatable. I have a shortcut for "import pudb; pudb.set_trace" in my IDE
(pudb is pdb with UI)
Re: Coding in the Debugger (2007)
#13I've seen so much absolutely crap code that I bet would never have been written if the author had just taken the time to step back and think and look at the big picture before writing a single line instead of focusing on microscopic bits and being hand-held through writing it all. After seeing what typical Enterprise Java looks like, I'm not surprised when I read articles about doing things like this.
TDD gives programmers a false sense of correctness. The temptation to "mess around with it until it passes" is far too great.
Re: Coding in the Debugger (2007)
#14I used to work with some ex-Smalltalkers who did this all the time, while complaining about his much worse Java's debugger was than Smalltalk's.
Re: Coding in the Debugger (2007)
#15Earlier quoted context omitted.
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.
Sorry this might sound stupid but does that include software with UIs? I’m thinking of a browser where it can be gpu accelerated or not.
Re: Coding in the Debugger (2007)
#16And this, boys and girls, is why you want to use a real IDE with an integrated debugger.
So emacs, right??
Re: Coding in the Debugger (2007)
#17I'm a big fan of repl driven development for some tasks but you do need to go back and refactor plus add tests.
Re: Coding in the Debugger (2007)
#18I often write some code, and then edit and correct it as I step through it, since I know there is a 99% chance that there will be bugs in it
Re: Coding in the Debugger (2007)
#19This 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)
It is also possible to do most of that with Python in Pycharm (except maybe jump behind?).
This is why going from Python to Go can feel like going backward. IMO, even compiled languages should have an "interpreted mode" for development. Once the development is complete, the code can still be compiled to get the benefits of runtime performance.
Re: Coding in the Debugger (2007)
#20This 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.
Yeah, I've found the Elixir debugger to be pretty useless when debugging multiple processes. I make have use of logging in such cases, and the language abstractions are usually easy enough to understand that I don't really miss a debugger. A huge benefit is that because I'm usually working w/ data structures that don't obfuscate the state within objects/processes, I can look at data the data and just figure out what's going on. The primary reason I want a debugger in Ruby is because some mysterious object from who-knows-where is hiding all the state & I'm just trying to figure out where the heck it came from, let alone what's actually in there.