RunRev vs RealBasic

Richard Gaskin ambassador at
Thu Dec 30 19:31:17 EST 2004

J. Landman Gay wrote:
> On 12/30/04 4:21 PM, Richard Gaskin wrote:
>> A shotgun approach usually just turns into a pissing match, and 
>> there's plenty in the archives of both lists and elsewhere to feed 
>> appetites for that sort of thing.
> I hope somebody shotguns it though, because I sent him to the list to 
> ask. :)

After all the trolling we had coming through here this year perhaps I'm 
a bit oversensitive to such things.  In all fairness, I remain curious 
about why someone who describes himself as preferring RealBASIC and 
being uninterested in the main benefit of 4GLs would be interested in 
switching from RealBASIC to a 4GL.

Just the same, in good holiday spirit I'll help guide him to the parts 
of the web site which answer his questions:

 > how does RunRev handle database connectivity?
 From <>:
   SQL database access
     * ODBC access (with any edition)
     * Direct access to databases:
           o Oracle (Enterprise, or Studio add-on, only)
           o MySQL with SSL
           o PostgreSQL
           o Valentina
           o Frontbase
           o 3rd Party SQLLite module available
     * Point and click database connection setup
     * Automatically display data in text fields
     * Plus fully-featured database API, work with binary data,
       execute any SQL query

 > Does it do 3D or OpenGL rendering well?
Not natively, but there is a set of externals for this in development. 
It's been considered for native support, and as much as it makes a nifty 
marketing bullet point in real-world development very few apps actually 
use it.  As with other features for which Rev has added a simple 
omni-platform scripting interface, I'm sure if interest in 3D ever takes 
off they'll move it up on the priority list.  'Till then its the domain 
of third parties, as it is with most such general development tools.

 > Does it support a "plug-in" architecture?
In the program see Development->Plugins
See also Externals at: <>

 > What level of system integration does the software have;
 > any direct access to system APIs?
Also from <>:
   Extensible language
     * SDK for creating externals in any compiled language
     * Shell access (Mac OS X, Windows, Unix)
     * Interprocess communication (on platforms that support this)
     * Platform-specific technologies:
           o Apple Events
           o AppleScript
           o Windows registry

It should be noted though that the main benefits of Rev are much more 
akin to Java than perhaps anything else.  Rev has a single script 
interface for 99% of what most apps need, with engines available for 
nearly every modern computer on the planet for more than half a decade.

For example, in some languages you can access the OS API for doing 
things like making aliases, so in a few dozen lines you can get the job 
done. But in Rev it's a single line of Transcript:

   create alias <aliasPath> to file <filePath>

Not only is this convenient to type, but it saves you from having to dig 
through a dozen volumes to learn the idiosynchracies of each OS API. 
With Rev, most of the time all you need is Transcript.

Transcript is famous for its one-liners, like downloading a file and 
displaying its contents in a field:

   put url "" into fld "Display"

In addition to these one-liners, some of the biggest conveniences with 
Transcript (and all such HyperTalk-inspired dialects) are chunk 
expressions, which make short work of text processing in way which are 
not only onvenient but also rather efficient.

For example, in most languages if you wanted to get the second word of 
the third line of a block of text you'd need to walk through it 
character by character, keeping track of delimiters as you go.  But in 
Transcript these this is simply:

   get word 3 of line 2 of tMyData

Again, it's not just the productivity or self-documenting benefits of 
this readable language that I'm emphasizing here, or even the benefits 
of typelessnes that Osterhaut refers to in the paper I cited.  The 
strong point here is that the more you use the language the more you're 
relying on highly optimized C++ code, so that one line of Transcript 
executes what might be dozens or hundreds in other languages.  In many 
cases the engine is so fast that even though the scripts are executed as 
mere bytecode overall performance is often on par with "fully compiled" 

I've seen some "fully-compiled" languages begin to recognize the 
benefits of scripting, making early steps toward grafting a scripting 
language onto their compiled language.  This trend validates what 
Osterhaut talks about, and what Rev is all about.

Rev is definitely a very different way of working, but if you're 
sincerely tired of compile-runtime cycles you may find it a good tool to 
add to your collection.

You may also be interested in their actual pricing, ranging from $99 to 

Academic pricing is even lower:

  Richard Gaskin
  Fourth World Media Corporation
  Rev tools and more:

More information about the use-livecode mailing list