[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