Debugging VB vs LC

[Jeff Massung]

Calvin,

I think you'll be pleasantly surprised at how much less debugging you'll be
spending in LC vs. VB (or C# or other compiled languages).

Most debugging (in VB, ...) is based around inspecting variables and
objects, because those things are only available to you while the program is
actually running. Let's take something that I've done recently and I'll walk
you through what I mean.

Let's say you wanted to make a simple RSS reader. Assuming you've laid out
your controls and are actually "programming" now. In VB you'd do something
like this in the script for a button:

sub OnClick()
   dim socket as RssSocket = new RssSocket()
   socket.Load("http://foo.com/rss.xml")
end

' in RssSocket, which is a subclass of HttpSocket
sub OnLoadComplete(content as string)
   dim doc as XmlDocument = new XmlDocument()
   doc.Load(content)
   foreach(item in doc.FindElement("/channel/item"))
      ' ...
   next
end

Let's look at this a bit more. First, you had to write code to subclass
HttpSocket to make RssSocket so you could override OnLoadComplete. Now, you
discover that somewhere in all of this is a bug. So you sent breakpoints in
OnClick() and OnLoadComplete(). Breakpoints hit, you examine the socket
object, the document object, maybe you find a bug. You stop the debugger
(and the program), you edit some code, recompile, try again.

Now let's look at the same process in LC (again, like th VB this is pseudo
code)...

on mouseUp
   get url "http://foo.com/rss.xml"
   set the cRssText of field "Headlines" to it
   parseHeadlines
end mouseUp

command parseHeadlines
   put revXMLCreateTree(the cRssText of field "Headlines") into tDoc
   put revXMLChildItems(tDoc, "/channel/items") into tItems

   repeat for each line tItem in tItems
      # ...
   end repeat
end parseHeadlines

I tried to keep the spirit of the VB code alive in the Rev code. First off,
we didn't have to subclass anything. We just created a custom property of
the field control on a whim because it was convenient.

Second, there's no "debugging" yet. Sure, we can set breakpoints if we
needed to, but there's no real separation of code-time and run-time, because
there's no compile-time like there is in the VB. Let's say we click the
button but we don't see any headlines? We just open up the inspector for our
field control and look at the cRssText property we set. Does it have XML in
it? If not, we'll what is there instead (maybe an error message).

Maybe there is XML in the property -- so downloading the RSS worked, but
there's something wrong with our parsing code. So, we set breakpoints check
some stuff out and modify code. But there's no need to click the button and
try again. Instead, just r-click the field and send the "parseHeadlines"
message to it. After all, you never actually stopped running your program
and the RSS XML data never went away. Just try parsing it again.

That's a trivial example. But the principle holds true for much larger
projects. Imagine you wrote some code that took a whole ton of data and did
a lot of processing on it. At the end of that processing (let's say 10
minutes later), something didn't work. Making a change, recompiling, and
running through that 10 minute wait again just to see if your change worked
would be horrible - talk about wasting time/money! With LC you don't have
that problem. You just make a change and continue from where you left off.

Try it yourself. A friend of mine finally grokked LC once he made something
stupidly simple: and RPN calculator in LC (which he didn't know) and then
remade it C# (which he did know). After a little while in LC and he just
figured out that his program was live (pun intended) all the time, remaking
the app in C# was just a painful experience.

Jeff M.