Debugging VB vs LC
cjw at eml.cc
Thu Jan 13 21:19:00 EST 2011
Very nice! I really appreciate your taking the time to compose such an
illustrative post. I'm not sure I understood every step, but I do
understand how to compare.
This has been a most enlightening exercise.
> Jeff Massung <mailto:massung at gmail.com>
> Thursday, January 13, 2011 7:07 PM
> 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()
> ' in RssSocket, which is a subclass of HttpSocket
> sub OnLoadComplete(content as string)
> dim doc as XmlDocument = new XmlDocument()
> foreach(item in doc.FindElement("/channel/item"))
> ' ...
> 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
> on mouseUp
> get url "http://foo.com/rss.xml"
> set the cRssText of field "Headlines" to it
> 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
> 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,
> 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
> 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
> 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
> 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,
> the app in C# was just a painful experience.
> Jeff M.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> Calvin Waterbury <mailto:cjw at eml.cc>
> Thursday, January 13, 2011 6:30 PM
> My history has a lot of VB involved. I must admit, I really "loved"
> the VB debugger and tools. I have done some testing in LC with the
> debugger, but it is a different animal, which we all know.
> Given one can code in a few hours and the spend days(weeks?) debugging
> complex code, I would appreciate any comparative experience, if any
> and just your thoughts on the debugger.
More information about the Use-livecode