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

[Richard Gaskin]

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