This article summarizes my approach to just about every technical challenge I've encountered since school. In grad school in particular, I could never get my head around the approach of uploading code to a Unix server and running it blind overnight. Instead, I would write it in Windows, but with a graphical display of results coming out in minutes rather than hours. The errors would then stand out glaringly. This is not to argue Windows v Unix as of course you can do it either way on both platforms. But calculations you can see working are priceless.
with a graphical display of results coming out in minutes rather than hours. The errors would then stand out glaringly...calculations you can see working are priceless.
Back in the 90's in the workstation lab, I tried again and again to get fellow 1st year CS students to use the debugger. They'd always say, "I'm too busy for that now!" Then, around 3am, they'd be desperate enough to let me show them how to recompile with the debug option, and we'd take 60 seconds to find the pointer bug they'd been pulling their hair out over for hours.
This is also why I love Smalltalk. Your objects and your code execution become palpable, handleable things. You can even collect examples and put them aside in groups for further categorization and pondering. Yes, not only do I sometimes have little clusters of Object Inspectors on my screen, I have sometimes had little groups of debuggers with alternate executions. This is not the normal condition, but if you ever get into a situation where you are making lots of comparisons, it's nice to know you can do this as easily as you could for real-life objects on an actual tabletop.
EDIT: Yes, sometimes I will play around with little stacks of execution stacks.
The best part of small talk is all those inspected objects can come with live execution stacks wrapped around them, so if you fix your code bug you can re-invoke from a test example easily.
