Why is Remote Debugging Ideal?

One thing I have seen some users complaining about is that they want to buy one license for REALbasic and be able to use it on Mac, Windows and Linux all for the same price. Aside from my obvious thoughts on that being a very stupid business idea, there's the technical standpoint which I'd like to discuss. They claim that remote debugging just doesn't cut it.

Here's why they're wrong.

Anyone claiming that remote debugging is sub-par to debugging locally is missing the point to remote debugging. Remote debugging is unfortunately touted as a way for you to debug your application on a native platform so that you don't need a second license. That's just a silly marketing message which I've yet to be able to erase from people's minds. Simply put -- that's just a nice side benefit.

So if that's not the point to remote debugging, then what is? Easy! It lets you debug problems that are 100% impossible to debug otherwise. This is a debugging tool which will pull you out of the fire when you have no other choices.

In the olden days, people would just print debugging information out and that's how they'd debug. That model works quite well, and a lot of us are comfortable doing that. Then, along came MsgBox (that one API alone set us back a decade in terms of debugging code). People still use it for debugging, and it really is a poor habit to get into. The reason being is that MsgBox changes the state of your application. When the MsgBox triggers, your application goes into this funky half-running state. Some of your code is halted, while other parts of it are running.

So that gets people to the point of why you should always be using the debugger. When you're stopped at a breakpoint in the debugger, there is no half-state. The application is suspended. But there's a more deep issue that people fail to see which is that the local debugger still changes the state of your application. The debugger becomes the frontmost window which then causes your application to get deactivate, activate and paint events. If you've ever run into a problem that's exacerbated by these events, then you know what a royal PITA it is to fix them.

That's where remote debugging comes in, and it's really the reason I started writing it in the first place. You can run the application on another machine and debug it without any interaction from the debugger at all. Everything happens via user input, so it's possible to recreate the exact situation the debug displays itself in. Without the remote debugger, this is impossible to do, and you're back to step 1 (printing debug lines).

So when someone tells you that remote debugging isn't a good alternative to debugging locally with a separate IDE, feel free to let them know that they should be happy they've never had to debug problems in their Paint events. The fact that they can use it to view their application on another platform is just gravy.