LSL v LUA

Hi,

I would like to have the opinion of LSL scripters who have also used LUA. A new Virtual World, Blue Mars, will use LUA, and I was wondering what the advantages/disadvantages were over LSL.

Rock

The language is not so much the issue as the API and the limitations you have to work within in terms of memory and such.

As long as you have the important elements in place, and LUA does, it is all down to the interface.

Thanks for the reply. I have never used LUA so I have no idea what it is capable of. I have used LSL, and I am well aware of its limitations, which have been discussed at length in this forum, and I was mainly wondering if any of the main problems areas with LSL (writing to notecards, script memory allocation, data storage issues, 'missing' commands, etc) are solved by LUA.

Rock

it's really a matter of implementation... without seeing what's they've made available and what they haven't, it's anyone guess what issues it will and won't have.

Correct.

Rock, lua has the missing commands. Everything else you asked about thou; These are not restricted in LSL, only in the environment.

I'm not sure I'd go that far, even. I don't have any LUA experience, but just glancing through the language reference, I can't find even a "case" construct. (On the other hand it appears that closures are built in, and what seem to be function pointers, so perhaps one could implement the moral equivalent of a calculated jump?)

I'm pretty fuzzy on how one grafts a language like this into an event-based execution environment, but then I also don't know how that's being done for the current prototype C# Mono binding (https://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_04_22#chat57).

One could try the Metaplace beta if they wanted a sample of Lua programming in an active available virtual world.

Thanks for that SuezanneC. I visited Metaplace, then left as it wasn't my cup of tea, just long enough to write a brief report. I did not note the scripting language, and I must make a point of noting that on my travels from now on.

I was rather hoping that someone in the LSL Scripting Tips forum had already some experience of Lua, from WoW perhaps, and could give me an opinion on whether choosing Lua was a smart move by BM, or whether they think that LSL is superior in some way.

Rock

I have some minor experience with the LUA of wow. From wayyyyy back when the beta was running and a couple month after.

Well in regard of that game, you could rebuild the entire UI from scratch with this. Graphics, Layout and also programm the functions into the buttons.

It works in a very similar way i think.
Short example (right out of my mind .. so dont call me on it)

if TestVar == "TestText1" then

ChatFrame1:AddMessage("TestText1" --prints "TestText1" into ChatFrame1 (Chatwindow)
elseif TestVar == "TestText2" then

ChatFrame1:AddMessage("TestText2" --Prints "TestText2 into ChatFrame1

else

ChatFrame1:AddMessage("neighter TestText1 or TestTex2"

--prints "neighter TestText1 or TestTex2" into ChatFrame1

end


Very simple commands who are mostly self explanatory.
The usual boolean operators are aviable.

Another one is the creation of frames.
This is an example of a normal free moveable frame in this game

local MyAddonFrame = CreateFrame("Frame", "MyAddonFrame", UIParent)
MyAddonFrame:EnableMouse(true)
MyAddonFrameetMovable(true)
MyAddonFrameetUserPlaced(true)
MyAddonFrame:RegisterForDrag("LeftButton"
MyAddonFrameetScript("OnDragStart", function() thistartMoving() end)
MyAddonFrameetScript("OnDragStop", function() thistopMovingOrSizing() end)
MyAddonFrameetWidth(300)
MyAddonFrameetHeight(300)
MyAddonFrameetBackdrop({bgFile = "Interface/Tooltips/UI-Tooltip-Background",
edgeFile = "Interface/Tooltips/UI-Tooltip-Border",
edgeSize= 16, insets = { left = 0, right = 0, top = 0, bottom = 0 }})
MyAddonFrameetBackdropColor(0.0,0.0,0.0,0.9)
MyAddonFrame:ClearAllPoints()
MyAddonFrameetPoint("CENTER", UIParent)

Crates a fully moveable frame, variable (dragable) size, with a defined backgroundcolor, a defined backgroungpicture in the center of the screen.

Lua has some language constructs built-in that make it far better than LSL, in my opinion. LSL is purely procedural, while LUA allows for objects, associative arrays, inheritence, closures, function pointers, and on and on.

There is no question in my mind that LUA is a far more productive language to work with. While in either case the power of the language to control the virtual world is limited to the exposed API, there are clear advantages to LUA.

I'm frankly quite surprised that LL decided to roll their own scripting language in the first place. Implementing LUA and exposing the engine's internals to the LUA runtime is so well-documented and easy to do that I can only think it must have been a severe case of NIH (Not Invented Here) syndrome that prompted such a poor decision.


.

My main concern about existing languages like Lua is that the runtime environments for these languages assume a relatively small number of parallel instances, and are not well suited to frequent rapid snapshots.

* It's rare to have more than a few hundred active scripts running on a single system, let alone several thousand as is typical in SL. To get good and predictable performance from a runtime takes a LOT of work. Mono still has scheduling problems after two years of development and integration with Second Life.

* Snapshotting a running Mono script and starting one up is a lot more complex and time-consuming than doing the same thing for an LSL2 script, and region crossing with running Mono scripts is still more of a problem than with LSL2. Doing the same thing for a new runtime will require an effort of the same magnitude as the Mono port.

I have the feeling that a lot of the Mono problems come from trying to tie it into a long-established environment that started out with such a crumbly and ill thought-out scripting language and VM AND TRYING TO MAKE IT WORK EXACTLY LIKE THAT EXISTING ENVIRONMENT. I'd bet you anything that if SL had started out with a different scripting/programming system (Mono, Perl, Lua, Python, Java, whatever) things would be a lot different and a GREAT deal smoother today. There's a great deal to be said for taking advantage of a well-used platform that is constantly being contributed to by sources outside your own small company. And if you think none of those are used in contexts that rival the challenges of the SL environment, I beg to differ. There are plenty of enterprise systems with a HELL of a lot of concurrency that use some of those. Platform developers for many of them have to think a great deal about system security and performance, and the engines usually have a great deal of tuning, optimization, and security policies that can be tweaked for this sort of environment.

But anyway, history is history. It is unfortunate that we have to live with SL's poor history right now, but it is often our own fault for insisting that everything be absolutely, 100% backwards and forwards compatible. Poor LL. These new virtual worlds have a huge technological advantage in choosing languages/VMs in a more open and forward-thinking fashion than LL did 7 years ago (or whatever). Good for them! It'll be interesting to see how many of them overcome the business challenges as well as the technological ones. There's the key to SL's success IMO, not the bass-ackwards scripting language/engine.

Well, I've spent a lot of time over the past quarter of a century hooking virtual machines (interpreters, runtimes, whatever you call them) into real-time control systems, and I haven't found a single VM that can be depended on for hard real-time response under concurrent load, other than things like Forth systems that were written for real-time work from the ground up.
They're not providing real-time response.

<3 Forth.

We had a 3 user PolyForth development system with 12K of ROM and 4K of RAM. Before anyone could test anything they had to call out "testing" so everyone in the editor could save their buffers and drop back to "ok" in case they crashed the system.

LSL2 gives you a whole 16K of RAM all to yourself! LUXURY!

Remembers her Jupiter Ace <3 ..... And a wonderfull Forth on the Amiga 500.

I never looked at LUA - but if they actually have continuations, the event based programming of LSL could have been much nicer encapsulated.

considering the length of time for development for LSL and the the length of time it would have taken to implememnt lua, I imagine the conversation went like this...

Linden Ao I thinkwe should use lua for scripting, but it's going to take a little bit to implement.
Linden B: nah I can write ya a scripting language by the end of this weekend...
(historical joke)

I've made this same decision a dozen times, and gone both ways... and given the constraints on scripting in SL... it would have taken as long to get Lua or any other "high function" scripting language working as it took to get Mono working, and it's still screwing up scheduling after two years. An LSL script has to run indefinitely with about the same per-script resources as a mid-range Apple II, it has to be able to switch execution contexts as fast as shared microkernel threads, it has to be able to be reliably marshalled and unmarshalled with minimal execution time, and often launched and relaunched multiple times a second if it's in a vehicle or attachment.

So it would have been "we can do Lua or Tcl and I'm pretty sure we can get it working within 12-15 months, or I can write a straightforward standalone bytecode interpreter in a week".