Hey Jeff,
I'm afraid that I have no real experience of Groovy beyond knocking together a couple of quick toy scripts after reading a book on the subject. So I can't help you directly.
But having said that, remember that debugging is a great deal more than using a debugger. There are many alternative ways in which you can discover the information you need in order to debug your code - direct instrumentation, for example (which can be much more sophisticated than just scattering calls to System.out.println throughout the code!).
There's no doubt that your debugger is one of the most powerful tools in your toolbox, but as time goes on I find myself using it less and less. And it seems that I'm not alone - many other developers I talk to tell me that they're finding the same thing. So, what's going on?
What has changed is test-first development. Where in the past my first instinct might have been to break out the debugger, now it's to write a
test. To understand why, it helps to think about why we might use a debugger. It's particularly helpful at three different points of the development life cycle:
During initial development, it's helpful when single-stepping through code helps to convince us that what it's really doing agrees with what we thought we were implementing.If we have a theory about why the code is behaving in a particular way, we can use the debugger to confirm or refute this theory.Finally, a debugger helps us explore code that is behaving in a way we simply don't understand.
But add test-first development into the equation, and the picture changes. Now, rather than stepping through the code to check that it behaves as we expect, we write one or more tests that demonstrate that it does. If we have a theory about what's causing a bug, we create a test that proves it. And the beauty of this is that unlike stepping though in a debugger, the results of which are ephemeral, a test is permanent. Not only does it prove that the code works now, but continues to do so in the future and can be run (and even improved) by other team members. Not only does it prove that our theory is correct, but we can subsequently use it to verify that our fix addresses the issue.
So that leaves the debugger as an exploratory tool. It's a vital role to be sure, but it's a smaller one than it held a few years ago.