[Opensim-users] TechCrunch Article
Toni Alatalo
toni at playsign.net
Fri Feb 17 09:18:08 UTC 2012
On Feb 17, 2012, at 9:00 AM, Drew Hart wrote:
> money. The whole world is built on old, inefficient code, and if Linden tries to update it those virtual objects can break, triggering massive backlash from buyers and sellers." (Emphasis mine)
> I am just curious - is this statement true? Is it true of Open Sim? I feel like it's not true, but I am curious for comment. And are we sacrificing quality to ensure backwards compatibility? I guess this is a philosophy
I'd dare to say: yes. With some reservations.
Rationale: for example LSL itself, at least the current implementations of it, are AFAIK relatively inefficient. Not to mention not the greatest nor best known language around, with third party libraries etc. The LLUDP protocol is another problem point, but I'll focus on the scripting here as that's what your post seemed to refer to.
If you compare LSL with a completely from the scratch approach, where you would drop all concerns for backwards compatibility, you could use either Javascript and the powerful optimized V8 engine for it (used in Chrome and in many places that embed js now) or for example Lua which has gotten really popular in games, and is fast and light.
The reservations: I'm sure both SL and Opensim backends have done good things to optimize things e.g. in the script engines. Linden has been working on their viewer too etc. Usually it is possible to optimize, clean up implementations etc. while still keeping backwards compatibility. I don't mean to belittle that work nor say that it would be impossible. There might be some weird things with LSL that prevent some cleanup / optimization for backwards compatibility reasons but I'd guess those points are rare.
Anyhow my bet is that LSL will never beat V8, with the huge Google effort, nor Lua with the nice clean design that also allows great speed (with LuaJIT2) , in quality -- considering both the niceness of the langs and the efficiency of execution.
C# scripting for SL seemed promising in Babbage's demo and that would be plenty nice and fast, though. And with Opensim you get that efficiency by writing region modules.
In realXtend with the Tundra SDK we've been now pursuing the approach where dropped most our the legacy (slviewer and opensim) alltogether, compatibility as well. So there at least you have something to compare with: a nice clean efficient system, but with no SL compatibility. If someone is interested we can do benchmarks, just tell what to test & we'll report :) We currently use JS for apps (not V8 now though but there's a branch of qtscript with which we can get that) and may test Lua too. My wish is that we are still a humble part of the opensim community, even though use different technologies -- alternative tools that suite different purposes are good to have around.
And the fact that all you out there in the big world use Opensim happily and can't e.g. switch to Tundra is a perfect example why backwards compatibility is a big deal :) We here just have often cases where legacy doesn't matter, some new game or customer project where need to make a custom app, perhaps with no SL like functionality at all, so in those cases it's not a prob and we can pursue this route.
> Drew
2cently yours,
~Toni
> http://techcrunch.com/2012/02/16/littletextpeople/
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20120217/20a5f9b3/attachment.html>
More information about the Opensim-users
mailing list