OT Re: REALbasic vs. Revolution

[Scott Raney]

On Fri, 11 Oct 2002 Troy Rollins <troy at rpsystems.net> wrote:

> On 10/11/02 8:26 PM, "Richard Gaskin" <ambassador at fourthworld.com> wrote:
> 
> > - What's wrong with the language such that a completely separate API in
> > needed for plugins?
> > 
> > I Rev/MC we can trade groups and other native objects without needing to
> > treat them as second-class citizens.
> 
> Personally, I think this conversation is spent. But since it seems to
> continue, I'll go ahead and ask where the SSL object is. Where the Open GL
> object is. Where the sheets object is. The sprite animation object. The PDF
> importer. The PDF exporter. The QuickTime capture object. The Firewire
> output object. The USB object. Even the throbbing button object (native, not
> simulated.)
> 
> I could easily go on. If these objects are out their for trading, send'm
> over. I take it that a different API isn't needed, and these things can be
> whipped up with a little transcript. Sounds like no big deal, right?

There's definitely some confusion here: these are not what would be
called "plug-ins" in RR, they'd be externals.  All of these things
*could* be done with externals, many of them quite straightforwardly,
at least if you know C and can find some sample code for them.  If
there is anything RR lacks here in relation to RB, it's the installed
base that likes to develop and release these kinds of things.  There
are at least three reasons for this I think:

1) The RB installed base has a much larger percentage of hobbyists,
shareware developers, and others for whom the investment in time in
building things like these is more easily justified.  More of RRs
customers (and an even greater percentage of MetaCard's customers)
have real jobs with real deadlines and so can't spend any time toying
with stuff like this.  They're also a lot less likely to be enticed by
making a few bucks selling such a widget if they did have the time to
make one.  Many of those that do work on externals like this, again
especially in MetaCard's case, do it for proprietary advantage and so
either can't or just don't want to make them publicly available.

2) As has been argued on the RB list on this topic, RB is much closer
in syntax to C and so I thing RB developers make the transition to
C/C++/Java more easily, a step that is required in order to build
these widgets.  Of course this has its downsides as in many cases RB
will be nothing more than a kind of waystation for developing
programmers (i.e. "Hey, I'm already taking a 2X hit in productivity by
developing in a third generation language, why should I also take a
2X-4X hit in performance and a big hit in flexibility relative to C++
too?").

3) We support more platforms than they do, have a much more balanced
ratio among users of the various platforms (RB only runs on the Mac,
so RB users and RB plugins are overwhelmingly biased toward that
platform and most don't work with Windows at all).  Furthermore, at
least in the case of MetaCard, a large portion of our sales are to
customers using UNIX workstations, which means a lot of extra work
developing your external and then either releasing the source to it so
that these UNIX users can build it themselves, or acquiring and
maintaining half a dozen workstations to build and maintain it.

All in all, though, I don't consider the lack of these things to be
significant disadvantages.  True, it means some projects will have to
be done using other tools, but that's true of any tool, including RB
where their development environment and most of these "plug-ins" are
written in C or C++ because you can't easily build these things in RB
itself either.

I've also had a lot of experience with these kinds of "add-ons" for
other scripting languages, Visual Basic, and Director and can only say
at best it's a mixed bag.  When the core tool is missing significant
features, it frequently takes a long time to track down what you need
and figure out how to use it, the quality of the add-ons and the
documentation for them are nearly always lower than what you get from
the main product, and the few really good quality add-ons tend to be
rather expensive.

As for the specific elements on your list, most of our customers (and
potential customers) don't need 3D, so that will probably have to wait
until someone releases an external to do it (I know of two of these
already, but they only run on UNIX systems and were done by companies
that can't/won't release them).  But sheets and animated buttons are
already done for the upcoming release, SSL is on the to-do list for
the release after that, USB and Firewire should be straightforward at
least on Mac OS X given the existing "open driver" feature (though
we've had very few requests for these, and very little interest even
in "open driver" itself), and RR is already working on some of the QT
recording features.

Our natural inclination when adding engine features is to do things
right, rather than quick.  This means it might take longer to make
some things available, the eventual product is of better quality and
easier to use than what you get with some other products (e.g. the
"player" object vs. the movie XCMD add-ons you get with HyperCard and
SuperCard, and the raw QT API you get with RB).  You can help by
requesting features you really need (not just "check-list" items), and
providing suggestions as to how they would be used and what the
scripting-language API for them should be.
  Regards,
    Scott

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...