Supercard vs. Rev

[Richard Gaskin]

Chilton Webb wrote:

> I believe it's a difference in the demands of the users. Because SC has
> been around so long, if SC4 shipped with *any* major bugs, it would be
> seen a major failure on the part of the SuperCard team, so the
> development cycle for this version was considerably longer than I think
> anyone hoped it would be. But the finished product was worth the wait.
> 
> SC's installed user base is not as tolerant of the development team's
> mistakes as users are on this list.

I think you may be underestimating the supportiveness of the SC community:
searching for "bug" in the SC list archives brought up a few hundred
messages, and the conversations there seemed very friendly and supportive of
Mark Lucas' excellent work.

One nice thing about this community is that posts related to other tools are
never filtered out, so sincere posts with information useful to the readers
here are always welcome.



Along those lines, here's today's rambling sermon from Brother Richard of
the Church of xTalk (you can stop reading here if you have useful things to
do with your time):

I've shipped software with nearly every xTalk product on the market spanning
about 15 years, and in all that time the only two people who seemed to
readily grasp the value of multiple xTalk implementations were Charlie
Jackson (founder of Silicon Beach Software, SC's first publisher) and Jean
Louis Gassee (former Apple technology director).

Back in 1989, Jackson and Gassee announced an effort to promote
standardization among xTalks (I still have that MacWeek clipping somewhere
in my filing cabinet).  This important move was later killed by Apple for
reasons not unlike the short-sightedness that eventually caused them to kill
HyperCard itself.  Meanwhile, Microsoft was prototyping VisualBasic on a Mac
in SuperCard, and their commitment to high-level development over the years
has often been cited as a contributing factor to their hegemony.

But Apple's short-sightedness need not be ours.

Show me another language family that has chunk expressions and I'll show you
as few lines of code as we xTalkers enjoy every day.  Show me another
language family that allows full runtime editing with no compile-run cycle,
and I'll show you a workflow with orders of magnitude greater productivity
over more cumbersome alternatives.

Ironically, the most popular scripting language in the world is JavaScript,
used not only in Web development but also in the IDEs for a great many major
packages from Adobe, Macromedia, and others.  I say "ironically" because the
language was never designed for widespread use: it was a weekend project by
a Netscape engineer that got rushed into the browser when the marketing
staff heard about it.  All too C-like, it is a needlessly cumbersome and
tedious language design, fine for compilation but uniquely inefficient for
real-time interpretation (see Osterhaut,
<http://dev.scriptics.com/doc/scripting.html>).

In a world where most scripters are accustomed to working much harder than
they need to, writing dozens of lines for one-liners us xTalkers take for
granted, xTalk is all too often seen as "too good to be true", or more
specifically, "too much fun to be powerful".

These perceptions affect all xTalks, and completely miss the point of good
scripting language design:  ideally, a scripter is writing as few lines as
possible, letting the highly-optimized object code in the interpreter handle
most of it.  It's just not smart to walk through a string of characters
keeping track of white space when you could be writing "get word 2 of line
3".

At a glance, xTalk appears verbose to programmers familiar with C++ and
Java, but that's only at a glance:  while the language does extend Pascal's
preference for readability to an even more productive level, generally
speaking you'll need only a line or two of an xTalk to accomplish what would
take dozens, sometimes hundreds, of lines in C++ or Java (compare "start
player 1" to what you'd need to play a QT movie on Mac Classic, OS X, and
Windows using C++).

To fight the FUD ("Fear, Uncertainty, and Doubt" for those of you who don't
frequent Usenet <g>), it benefits all xTalkers to recognize that the more
implementations of xTalk that exist the better it is for all of us in
promoting the benefits of this language family.

Offhand, it seems there are four xTalks shipping, each with a different
market focus:

ToolBook - as a Wiindows-specific tool, it does things like direct API calls
that are pretty nifty if you can afford it and need the API.

SuperCard -  As a Mac-only tool, it offers some attractive options for
developers who can deploy solely to that OS.

MetaCard - The first truly multi-platform xTalk with a spartan UI
well-suited for its UNIX-centric customer base.

Revolution -  The next stage of evolution for the MetaCard engine, offering
the same support for deployment to nearly all modern computers with a more
feature-rich UI than MC.

None of these products is exactly like the others, each addressing a
different focus its users find satisfying.

But all of them share the same grace and ease inherent in xTalk, and
collectively they make a powerful statement about a very differnt way of
developing software than most of the world has yet known.

So I would encourage all xTalkers, regardless of dialect preference, to
consider this larger view rather than nit-picking among ourselves.  As Scott
Raney says, "Let a thousand flowers bloom".

With a few hundred million computers on the planet, there's plenty of room
for all of us.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc