At 4:22 PM -0700 10/1/01, Richard Gaskin wrote: >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).
... >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. I regard xCards (and scripting languages in general) as the best form of code reuse yet found. It allows the reuse of huge chunks of code. The distinction between the code that is being reused (the source for the MetaCard engine) and the code that is doing the reusing (our scripts) is crystal clear. The definition of the interface to the code to be reused is perfectly clear, since it has to be in order for us to be able to use it. All this combines to enable a depth and breadth of reuse available nowhere else. >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. Interestingly, I just did a brief comparison to REALbasic a few days ago. There was a discussion on the RB list regarding finding the chunks of a string. This is an area where the REALbasic function NthField is admittedly slow, because it is WorldScript aware. There is a plugin -- FastNthField -- that is much faster, because it looks at everything as straight text. REALbasic just got RegEx, so that's another way to do it. Finally, you could roll your own. Here are results from a test run by one of the REALbasic list subscribers. He parsed through the words of a chunk of text, about 700K. >>TextFieldIterator 24 >>FastNthField 17 >>NthField way slow >>RegEx 48 This was on a G4 733 Mac. I don't have a G4 733. So I tried it on my PowerBook G3 400. Here's what I found in Revolution: repeat for each word W in tString end repeat takes about 5 ticks. I don't have the actual string used in the REALbasic tests, but my string had lots of little words. In any case, for this particular task, it would appear Rev is significantly _faster_. regards, Geoff
