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 <http://revolution.runrev.com/section/features.php>: 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: <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>: 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 "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" languages.
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 $299:
<http://support.runrev.com/pricing/license_pricing.php>
Academic pricing is even lower: <http://support.runrev.com/section/education_pricing.php>
-- Richard Gaskin Fourth World Media Corporation __________________________________________________ Rev tools and more: http://www.fourthworld.com/rev _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
