SC, Rev,and RB speed test

[Richard Gaskin]

Chris Yavelow wrote:

> David Vaughan's solution is incredible!
> I now have the following results up at http://www.yav.com/speed.html
>     * Revolution (2.2) -- 41 ticks
>     * RealBasic (5.5.1) -- 63 ticks
>     * SuperCard (4.1.2) -- 920 ticks
> It's quite a surprize!

That makes two for two:  last time I saw a comparison between those 
products the Rev speed advantage was about 40% over #2.

And that's only the beginning:  in evaluating products for a particular
project there are so many other areas where Rev shines even more
brightly than raw speed.

Before the advent of xTalks, Beginner's All Purpose Symbolic Instruction
Code was a great way to get started on your way to Pascal, C, or
Assembler.  But today, those not already enamored of BASIC have few
objective reasons to choose it:

If you're going to stay in a 3GL you'll usually find better performance
and a wider range of tools, libraries, and example code using C++, or
you can have the productivity benefits of moving up to a modern 4GL like
Transcript with little or no loss in execution speed.

Higher level languages offload more of the tedium from the developer
into the engine, usually resulting in fewer lines of code per project
with a greater percentage of the work being performed by
highly-optimized, compiled C++ in the engine.

And if you need raw speed or direct OS API calls you can still use C as
needed in an external, without saddling your entire development cycle to
productivity-eaters like data typing, garbage collection, and a
compile-runtime cycle.  Most OS vendors document their API in C.

Some implementations of BASIC have come to recognize the value of
scripting, like Microsoft's VBA, so developers can automate production
in the IDE.  But it's taken these vendors many years into their product
life cycle to catch on to the benefits Transcript first delivered 13
years ago, so there's little if any integration between the code you
write your application with and the code you automate your IDE with.

With less time spent waiting for a compiler to catch up with your brain
you can spend more time on user task analysis and translating the
results of that analysis into effective interfaces.  In short, it lets
you focus on the human side of software.

If you expand your evaluation matrix to include other factors beyond raw
speed of a core algorithm I would be interested in seeing the results.
If your experience bears out like mine the speed advantage may wind up
being the least impressive measurement. :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com