[sldev] Re: LSL and geometry hierarchy issues (Mark Meijer)

Argent Stonecutter secret.argent at gmail.com
Mon Jan 21 06:30:22 PST 2008


Crossposting stuff between mailing lists, particularly when digests  
are involved, is a bit dangerous. :)

On 2008-01-21, at 06:12, Kamilion wrote:
> On Jan 20, 2008 3:36 PM, Argent Stonecutter  
> <secret.argent at gmail.com> wrote:
>> What languages, though, do you think would serve significantly better
>> than LSL? The ones that come mind for me are Scheme and Forth, simply
>> because both have a simple inner interpreter that could readily be
>> wrapped around any axle. The other names that come up in these
>> discussions - Lua, Tcl, Javascript, and the like - are likely too
>> heavy already.
>

> What about Ruby 1.9?

Ruby is in the same general family as Perl and Python. These  
languages aren't even designed around embedding, let along fine  
grained microthreading... plus they all the overhead of any  
inherently OO design. If you're thinking about languages in that  
class you haven't even started thinking about the kinds of problems  
I'm getting at.

> However, make no mistake, I support Mono over all of the other  
> solutions.

Mono is based around a heavy interpreter core. Again, if you're  
looking at Mono at all you've either no experience in tight realtime  
environments or you've got answers for me that address the kinds of  
problems that tight embedded code has... and you're not even talking  
about those problems. Babbage Linden has come up with some answers,  
but what he's having to do for transportability is scary. Imagine  
crossing a region border and having to snapshot a couple of hundred  
CLI environments (waiting for them to get to a point where they can  
be snapshotted), cross the border, and instantiate them again. The  
LSL image is effectively *always* a snapshot, which is why it has a  
hard 16k limit. Forth and Scheme can work under those environments  
too... I've done it. I haven't run into anything else that's suitable.





More information about the SLDev mailing list