RunRev vs RealBasic
ambassador at fourthworld.com
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?
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 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: <http://support.runrev.com/resources/externals.php>
> What level of system integration does the software have;
> any direct access to system APIs?
Also from <http://revolution.runrev.com/section/features.php>:
* 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 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 "http://fourthworld.net/data.txt" 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:
Fourth World Media Corporation
Rev tools and more: http://www.fourthworld.com/rev
More information about the use-livecode