From: Austin Ziegler Date: 2003-07-30T12:18:58+09:00 Subject: Ruby => Rite, AST => Bytecode? Matz and fellow Rubyists, On pragprog, we're sort-of discussing the creation of a new language ("Pragmatic") as an exercise in extending one's programming experience. Now, there's a lot of discussion on the low-end, but the most interesting to me was this, and I was wondering if something like the idea behind Juice might be a good thing for Rite, rather than a "pure" bytecode setup. What do you think? -austin On Wed, 30 Jul 2003 11:57:26 +1000, Sumskas, Peter (Peter) wrote: [...] > The idea behind Juice was to encode a portable encoding of the > program not as bytecode (which is the usual way to do things) but > to encode the AST as the portable format. This lead to several > interesting features for Juice: > > * the binaries were actually smaller than the equivalent bytecodes > and smaller by far that machine-specific binaries. > * the binaries contained far more information about program > structure than the equivalent bytecodes did. This led to being > able to take better advantage of the target platform. A JIT > compiler would translate the AST into the backend representation > and it had a much easier time of optimizing the code than an > equivalent JIT compiler for a bytecode system would have. I saw > this demonstrated in '97 or '98. Given that Juice had less > resources than Java devoted to it you can imagine how impressive > it was to see a recoding of some Java applets executing > approximately five times as fast as the original Java did (I > realize this is highly subjective but the implication is that > wherever the limitation was with Java they had taken the wrong > approach to portability and performance). > * due to the small size of the binaries it was faster, on networks > and PCs of the day, to download a Juice applet and JIT-compile > them on the target machine than it was to download the > equivalent platform-specific binary and execute it. [...] -- austin ziegler * austin@halostatue.ca * Toronto, ON, Canada software designer * pragmatic programmer * 2003.07.29 * 23.18.28