compileIt for revolution?

[Gordon Webster]

I would absolutely echo what Dennis has just said. I
was initially really impressed with rev and I should
say I still am in certain respects - comfort and ease
of use, the elegant and intuitive language and
stack/card paradigm etc. etc.

But I have been unable to get rev to do what I want it
to do behind the scenes (i.e. my application logic)
without jumping through the kinds of hoops that Dennis
describes - effectively negating all the advantages of
programming in Transcript that I just outlined.

And even when I could get the code working, man it was
SLOW. It was discouraging to see Python easily outrun
rev for the equivalent code - I mean I love Python and
all, but it's hardly the gold standard for speed.

I would think that the stack paradigm would neatly
allow for the creation of strongly-typed stacks that
could be jumped into from the kind of warm and fuzzy
typeless stacks that give rev its wonderful
flexibility. The compiler could then insist on
declarations for all objects within the typed stack
and compile it with far greater optimization than is
possible for the typeless stacks, perhaps even going
as far as native code compilation :-D 

Imagine what a superb development environment rev
could be with these features. Flexible and typeless
for all the UI/scripty/fun parts of the app; more
draconian but hellishly fast for the down-to-the-metal
hardcore byte-crunching parts of the app. Strong
typing would probably also make it a lot easier to
automate the process of calling externals from
Transcript without all those ghastly, clunky C
wrappers and crap.

There's a dream - a rev scientific application with a
beautiful interface rendering OpenGL objects in real
time and a typed, Transcript-coded stack running
energy minimization on a separate thread in the
background.

I doubt I'll put my hands in my pockets again and
upgrade my expired rev license just to have "deep
masks" on my GUIs - I'm not knocking it, it's just not
a feature I urgently need right now ... but fast
compiled stacks, easy access to externals ... now
you're talking ... where's my check book?

Best

Gordon

--- Dennis Brown <see3d at writeme.com> wrote:

> Dan,
> 
> I also would like to speed up array processing.  It
> kills me that my  
> friend won't move from VB to Rev because when I
> write the same array  
> processing problem that he uses, VB runs 10+ times
> faster than Rev.   
> I also have had to jump through hoops trying to
> figure out ways to  
> make my array processing go faster --it usually
> requires taking a  
> simple script and making it 5 times as complicated
> as the way you  
> would do it in VB or RB or any other ordinary
> language.  It is not  
> just for the type of math problems that I am dealing
> with.  As visual  
> effects become more important, being able to quickly
> process numeric  
> arrays like a pixel image array becomes important.
> 
> However, I don't think compiling scripts is the
> answer.  I love  
> having the interpreted environment for interactive
> debug and  
> experimentation.  The UI is where all the code and
> debugging time is  
> spent.  I don't want to trade that in for anything. 
> Rev is all about  
> UI, but weak on array speed.   The language as it is
> defined would  
> hardly be faster as a compiled version because of
> the type-less and  
> stringy nature of the variables.  Compiled languages
> get their  
> effeciency by the programmer telling them up front
> the data type and  
> therefore the correspondence to specific machine
> code operators.   
> There is no guessing or mixing of types.  The
> processing of numeric  
> (or fixed length strings) hardly needs any checks at
> runtime.
> 
> What I advocate is a cross platform runtime package
> that is a pure  
> fixed type, fixed operator, math orientated array
> language.  It can  
> be PCode or threaded with very low overhead. 
> Languages with no UI  
> considerations are very easy to create and code for
> a machine code  
> programmer. I would like to see the basic operators
> and control  
> structures to work on regular arrays of n
> dimensions.  I am not  
> actually referring to "array" operators, just the
> ability to apply  
> ordinary operators to one addressable array element
> at a time with  
> efficient looping structures.  That should result in
> an order of  
> magnitude increase in speed for the stuff that bogs
> Rev down, and  
> open up Rev as a universal development tool.
> 
> The key is to have an efficient and elegant way for
> Rev to interface  
> with such a package.   It needs to be able to pass
> the "program code"  
> and pass array elements, rows, columns, and whole
> arrays to the  
> coprocessor (really it just needs to be able to pass
> pointers to the  
> array memory blocks).
> 
> As long as Rev has this Achilles heel, it will
> preclude it's use as a  
> "real" programming language in the minds of many.
> 
> I did make a BZ enhancement request, but I think it
> could benefit  
> from a discussion on this list.
> 
> Dennis
> 
> 
> On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote:
> 
> > Xavier....
> >
> > I guess we'll just have to agree to disagree about
> this.
> >
> > How in the world would you expect a compiled
> script or handler --  
> > if such a thing were possible -- to then be
> smoothly integrated  
> > into a stand-alone app?
> >
> > We needed CompileIt! in HyperCard *far* less for
> performance than  
> > for code protection and the ability to deliver
> stuff that didn't  
> > require the player to be around. Neither of those
> is an issue today  
> > in Revolution.
> >
> > As for performance, tuning for such situations has
> produced  
> > staggering results. I was blown away in Monterey
> last weekend to  
> > watch a dynamically populated menu that was
> pulling its contents  
> > from 100 text files appear in under a second. I've
> never heard much  
> > here in the way of complaints about slow programs
> written in Rev.
> >
> > Dan
> >
> > On Jun 21, 2005, at 9:31 PM, MisterX wrote:
> >
> >
> >> Dan,
> >>
> >> Creating apps with rev has NOTHING to do with
> compileIt.
> >>
> >> I really would like to speed up some scripts to
> manipulate
> >> arrays (where rev has some serious limitations)
> and the best
> >> possible way to do that would be to have
> something like
> >> CompileIt.
> >>
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and
> manage your subscription preferences:
>
http://lists.runrev.com/mailman/listinfo/use-revolution
>