IDE on a Mac and on a PC - Same ??

Jerry Daniels jerry.daniels at me.com
Mon Jul 26 11:18:53 EDT 2010


Great post, Richard!

Best,

Jerry Daniels

Join the Rodeo discussion:
http://rodeoapps.com/discuss-among-yourselves-0

On Jul 26, 2010, at 10:11 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:

> Richmond wrote:
> 
>> On 07/26/2010 02:25 PM, Richard Gaskin wrote:
>> 
>> <snip>
>>> then mine,
>> 
>>> <snip>
>>> --
>>> Richard Gaskin
>> 
>> Boy, I must have been asleep; do tell as would love to try it.
> 
> Your quote was trimmed a bit too short to determine what you were referring to, so I had to go back to the original message and search for "then mine," to find this:
> 
>    In Rev, any IDE is merely a collection of stacks that runs
>    on top of the engine.   The first IDE for this engine was
>    MetaCard, then FreeGUI, then Rev, then mine, then Jerry's,
>    and there may be others.  All just stacks - you can write
>    your own too if you're so inclined; it can be kinda fun.
> 
> What follows is a bit of a rant on complexity, which the reader is encouraged to ignore if they have anything better to do (I try to keep my off-topic comments here to a minimum, and save 'em up for one long post <g>):
> 
> 
> When I first started working with MetaCard in '97, I did what I tend to do with any new xTalk I pick up:  I made tools for it.
> 
> I had started Fourth World on 4/4/94 publishing tools for SuperCard, and did rather well with SC for many years, sorta the Heizer of the SC world (and for Heizer too; we had a page in their catalog).  But when SC didn't make it to Windows during the same period Apple posted two years of annual losses, my clients were scrambling for a cross-platform solution.  As much as I liked Toolbook, maintaining two code bases in SC and TB wasn't going to be cost-effective, so we started migrating work to MC.
> 
> Making tools for MC was almost a necessity, spartan as that IDE was. These tools kept growing, and by the time Rev was born in 2000 I was already spending relatively little time with MC's UI, using mostly my own stuff within its framework.
> 
> The first commercial add-on for Rev was devolution, a packaging of some of those tools, released long before Rev even had RevSelect.  More of a collection of utilities than a complete IDE, it was a starting point which has been in continual development ever since.  The publicly-available version is quite old; between the need to rethink the updater and being busy with an abundance of interesting client work, the public version has fallen quite behind the current tool set.
> 
> Today devolution includes a much broader range of stuff, from a Macromedia-inspired inspector to a standalone builder, and its MetaCard-bound history is nearly completely severed.  Once the last dependencies on MC have been purged from its framework, I'll use the new RIP Updater tool I've been working on to release it; extra bonus points that the RIP Updater will work with all RIP-savvy tools (for more on RIP see the Rev Interoperability Project at <http://tech.groups.yahoo.com/group/revInterop/>).
> 
> When devo2 is released it'll speak for itself, so there's no need to spend much time on it here.  Some may like it, some won't, and that's okay.  I made it for me and my clients, and will be sharing it as-is in case others find it useful.
> 
> I will however indulge in describing one small part of devo2:  the debugger, which I'm working on now with some help from Ken Ray.
> 
> 
> At the heart of devolution is my xTalk mantra:
> 
>    Know the engine.
>    Trust the engine.
>    Use the engine.
> 
> We all use any variety of scripted tools on top of the engine, but the engine itself is the one thing we all use, and the only part of the Rev experience our customers use.   So the engine is unusually well tested, having been through more gauntlets than any IDE can be.  It's the engine that binds this community, the well from which we all drink.
> 
> The engine employs a certain logic to how it deals with things, and I believe it benefits a toolmaker to understand that logic and use with-the-grain solutions whenever possible.
> 
> For example, stacks appear in windows and have a "style" property to govern the window's mode.  So if you're making plugins you could just use that property, and the engine can take care of rendering the window as palette, modeless, or whatever you've set its style to.
> 
> The Rev IDE, however, added a custom property to mirror this natural behavior, the cRevLoadInfo["mode"] property.  I can't claim to understand why this was used instead of the built-in property already available, but as you poke around in Rev you'll find other similar things in which the IDE adds additional layers on top of things the engine already does quite well.
> 
> Debugging in Rev takes a similar tack.
> 
> Historically, most Rev scripting environments use the same window for both editing and debugging, but the two are very different tasks.
> 
> Writing scripts and tracing their execution are almost opposite tasks in many respects, with the only thing they have in common being a need to display a script in a field.
> 
> Somehow even MC was seduced by this lone commonality into thinking that this meant the best way to serve both of those very different tasks was in a single window.
> 
> But because the nature of the tasks are so different, if you read through the scripts of both the MC and Rev editors you'll find a fair amount of branching code which the stack uses to alter its appearance and behavior depending on whether you're scripting or debugging.
> 
> The tools and controls you need for writing scripts are very different from what you need to simply trace through them.  This means a LOT of additional code is needed if you use one layout for both tasks, for both handling the switching and for making sure the scripting stuff isn't available when tracing.
> 
> In a word, complexity.
> 
> In 1976, Thomas J. McCabe, Sr. came up with an algorithm for measuring complexity in code which is as surprisingly simple as it is language-independent:  count the decision points.  He called this algo Cyclomatic Complexity, and FWIW I have a Rev-specific version which will be available along with some other code analysis tools in RevCloud later this summer, but that's another story.
> 
> For the moment just consider what McCabe realized:  a straight sequence of statements only has one possible outcome, and it either works or it doesn't and you'll know it straight away when you run it.  But the moment you introduce decision points (if-then, switch-case, etc.),  your program's execution path takes on a combinatorial explosion of possibilities.  This is what McCabe measures as "complexity", and in general the more complex a code base is the more prone it is to errors, and the more expensive it is to test, maintain, and enhance.
> 
> Debugging with a tool made in the very execution context it's debugging is an inherently difficult task, rather like making a watch where the only tool you have is another watch.  It's a bit challenging to stick your fingers between the fan blades while they're turning in order to fiddle with stuff behind them, but it can be done if you're quick and nimble.
> 
> But that nimbleness requires the opposite of complexity: simplicity.
> 
> In a tool that uses its own language to debug itself, a debugger will be reliable in inverse proportion to the number of lines of its own code it's executing.
> 
> If you dig into the debuggers in Rev and MC, you'll find a majority of the code there isn't about debugging at all, but instead about maintaining the current state of the dynamic dual-use script editor. Hence, the many issues people have reported debugging in Rev.
> 
> Looking at that code more deeply, we find that the engine messages involved are few and well-defined.  The only trick in using them is that you won't have a debugger available to help you if you're using them to write a debugger, but once you get the hang of it (and have become accustomed to saving before each test because it's likely you'll hang when you've screwed up <g>), there's a world of opportunity to make a much simpler way to debug scripts.
> 
> So in devolution there is now a debugger, implemented as a separate window which has very few controls, no menus at all, and its scripts are ultra-tiny.  It does only one thing, debugging.  And after just a day's work recently it appears to be rather robust.  Yes, it's being tested on Linux too.
> 
> I'm working with Ken this week to hone some of its UI, and then it'll be in the can and I can get back to finishing its companion script editor, which is coded with a similar eye toward simplicity, unencumbered as it is without the needlessly dual-purpose workflow.
> 
> Extra bonus points with the debugger: if testing continues to go well, it appears it will be possible to use it in a standalone, providing the Rev community with its first true runtime debugger.  With its integrated Variable Watcher and Message Box, and my Flight Recorder tool for watching message flows, you'll have the essentials you'll need to diagnose nearly any problem right inside your compiled standalone.
> 
> And for Rev users that's a bigger deal than it is for MC users, because among Rev's complexities are a good many differences it introduces between development and runtime (where are libraries stored and can you control all of them?).  Know the engine, trust the engine, use the engine.
> 
> More on all this as it comes together.  The good thing about these tools is that I'm able to build them because I need them.  But the bad thing about them is that I need them to work on products, and always need to balance my time between shipping code and crafting new things to ship better code faster.  Delivery timelines on tools are therefore unpredictable, contents may settle during shipping, objects in mirror may be larger than they appear....
> 
> --
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution



More information about the Use-livecode mailing list