Debugging VB vs LC

Calvin Waterbury cjw at eml.cc
Thu Jan 13 21:19:00 EST 2011


Hi Jeff,

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.

Fair winds,
Calvin

> ------------------------------------------------------------------------
>
> 	Jeff Massung <mailto:massung at gmail.com>
> Thursday, January 13, 2011 7:07 PM
>
>
> 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.
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> ------------------------------------------------------------------------
>
> 	Calvin Waterbury <mailto:cjw at eml.cc>
> Thursday, January 13, 2011 6:30 PM
>
>
> Hi,
>
> 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.
>
> TIA,
> Calvin




More information about the Use-livecode mailing list