Agreed. Stepping through your code in a debugger is SLOW and tedious. Make a change, run the code path again, make a change, run the code path again... boring.
It is much easier to print data in the area you suspect is wrong, then write a small script to get the program to call that code. You make a change and get nearly-instant feedback.
Stepping through in Smalltalk debuggers is (usually) easy and delightful. I had one student in a Smalltalk class (he was a quant, heavy math dude) declare the VisualWorks Smalltalk debugger came from God!
The debugger is so responsive, I routinely have 2 or 3 debugging sessions open, and write code in one of them. I'll write some exploratory code, evaluate it in the current stack context, examine the results, then dismiss it after copying the code back into the original debugger context and modifying it into an actual method. Sometimes, people will put a snippet of code in a comment and say, "debug this!" which is often informative and as easy to do as following a hyperlink. There's never a wait for a compile. It's not perfect -- you can get into trouble trying to debug parts of the system used by the debugger itself -- but for typical application programming, it's a joy! Oh, and with Smalltalk Server Pages, you can debug and step through in a completely natural way the rendering of a web page! (Yes, you'll see that HTML element there, then where you step into the message send for the dynamic HTML generation.)
It is much easier to print data in the area you suspect is wrong, then write a small script to get the program to call that code. You make a change and get nearly-instant feedback.