Robert Brenstein writes: >> What follows is a lot of code to implement a really short HyperTalk script. >> In fact, from the example provided in this article, I counted 52 lines to >> implement an 8 line HyperTalk script. Had Matt used Revolution, he wouldn't >> have needed to do that... >> > > Yes, but let's be clear that this is just a difference between the > environments not a clear advantage of one or the other. Such code > needs to be written once (or copied from elsewhere) and then can be > reused. So the advantage of xTalk is kinda short lived. The > strongest point that article makes is that for people who are not > afraid to do more "real" programming, RB is an option but it is a > give-some-get-some situation. However, for quite a few xTalkers, > Hypercarders in particular, the reason for staying with it is exactly > that they don't want to switch or have "reservations," as you said it > rightly, to that style of programming. One thing that seems to be > omitted is a mention that RB also supports extensions (in form of > plugins) to supplement the environment and address shortcomings.
If you're looking for a "clear advantage" between just about any two programming languages as similar in scope as Rev and RealBASIC, you'll likely find it's largely a matter of personal taste. But I can at least tell you why I prefer the tradeoffs of Rev over the tradeoffs of RB. I know I bring this up almost too often, but have you read Osterhaut's paper on scripting?: <http://dev.scriptics.com/doc/scripting.html> There's more here than stylistic preferences. For many, the preference of one language over another is driven by programmer productivity. As I was writing this, I realized is was getting almost too long to be readable (perhaps that's still true <g>). I've broken it into sections for clarity (as much as can be in such a ramble): PRODUCTIVITY With only a superficial view, it's easy to see scripting languages as being fully interpreted, and indeed the code you and I write is fully interpreted. But as Osterhaut reminds us, scripting is really just a way to glue together the fully-compiled-and-optimized routines which comprise the interpreter engine. Viewed in this more wholistic manner, the vast majority of executable code in a true 4GL like Revolution is compiled. A single line of Transcript can trigger instructions that were written in hundreds or thousands of lines in C++. (And with the MC engine, that compiled code is well optimized, and in my experience gets faster every few releases). RealBASIC and other "3.5 GLs" generally require more lines of code to acheive the same result. If this feels more like "real" programming, well there's no disputing tastes. But if you like working at that level, there's a good argument to consider going the extra mile and working in C++. Take a gander at Figure 1 in Osterhaut's paper <http://dev.scriptics.com/doc/scripting.html#921216>. Where you see "TCL", think Rev, where you see "Visual Basic", think RealBASIC. I think Osterhaut makes a very strong case for the benefits of typeless 4GLs in terms of programmer productivity. For vertical-market solutions and in-house workflow tools, time-to-delivery drives overall cost, favoring 4GLs. PERFORMANCE Many see 4GLs as trading performance for producitivity. But as Java's lackluster performance shows us, even a typed language need not necessarily be faster. Keeping in mind that most of the code in a Rev project is pre-compiled, this implies that any other language claiming to offer compilation may deliver smaller executables, but not necessarily faster ones. If I write one line of interpreted code in a 4GL that triggers a thousand lines that were written in C++, a "3.5GL" would need to have compiler optimization as efficient as Code Warrior's to compete. Of course, the number of lines of script will affect overall performance, as well as the intelligence of the scripting. It's possible to write slow code in any language (as we've seen with so many over-generalized C++ libraries used by major companies like Adobe, where apps get bigger and slower every year, trading off code efficiency to stay on top of feature-creep). REUSABILITY While it's true that copying-n-pasting code from a library works in many cases, by extension that was the promise of C++ portability that never materialized. There's a limit to how far one can generalize code before it becomes a rat's nest of slow-moving spaghetti. If it were possible to generalize to that degree efficiently, we wouldn't have seen the death of all iconic programming systems over the last decade. I suspect programmers will continue to type for some years. DEBUGGING We really can't compare development processes well without discussing the compile-runtime cycle. This is a new concept for Rev users, as the compile-time for Rev is zero. In other systems, there is a sharp division between development and runtime, with significant limitations on what changed can be made in-place during runtme (often limited to tweaking variable values). Also, the value of having the IDE available for every supported platform cannot be overstated. Limiting the IDE to one platform and allowing only debugging on the target is another time/cost hit to the development cycle. Maybe that's why so many RB-made apps are Mac-only, the authors having blown off the other 94% of the potential audience. I can't remember the last time I saw a platform-specific MetaCard or Rev app. EXTENSIBILITY Rev and RealBASIC provide means of adding new capabilities and objects to both runtimes and the IDE. In Rev, most object types you'll need can be built using groups. You can go further to move the code for those groups into a backscript for easier maintenance. The Rev IDE provides a means of adding custom tools as well. If you need something not supported by the host language, with both Rev and RB you'll need to know the API for the target platform. Rev provides a rich variety of hooks for such externals. Here's a question from a fella who hasn't touched VB in almost three years: can you create new objects on the fly in VB or RealBASIC, or do you still need to anticipate all objects in advance and show and hide them? If someone has enough experience with RB, it would be cool to see a "bake off", taking a simple app and comparing number of lines written and overall performance of the end product. RB may generate faster code in some cases, but I would be surprised if the performance difference were even noticable for most most operations, and very surprised if the performance difference were anything close to the difference in script size. I believe number of lines of script is a more meaningful measurement of productivity than development time, as dev time is driven by how much code one already has on hand, which can vary too broadly to make a useful comparison. Any other producitvity measurements worth considering? -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _____________________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc Fax: 323-225-0716
