IDE on a Mac and on a PC - Same ??
ambassador at fourthworld.com
Mon Jul 26 11:11:39 EDT 2010
> On 07/26/2010 02:25 PM, Richard Gaskin wrote:
>> then mine,
>> 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
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
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
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
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
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
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....
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
More information about the Use-livecode