Why Lua?
Chaser Zaks
As a programmer, I've never been a fan of Lua. It's cumbersome, and tries to "do things differently" than every other scripting language.
Take for example array indexes. Everyone is familiar with index zero being the first entry of an array. Lua uses index one. Going back and forth between the two when trying to interface stuff with LSL is going to be a pain, because if I have a index that is entry 14 in LSL, it will be entry 15 in Lua.
Or how everything is separated, and there is no object model, except for when there is a object model, but the decision of a object model is completely random. If you want to insert into a table, you don't do
MyTable.append()
, or MyTable.push()
, you have to call the "table" object, which has a function "insert": table.insert(MyTable, MyValue)
.Another is Lua's bitwise. I forget what the functions are specifically, but I remember when I had to do stuff in Garry's Mod, if you wanted to do bitwise operators, it was stuff like
bit.xor(a, b)
instead of what everyone else does like a^b
.Don't get me wrong, I
really
appreciate that there is effort going to do client side scripting, and it would be hella useful, but I don't see Lua as the future. It's been dying out of favor from what I've seen, even Garry Newman (The creator of Garry's Mod) has fallen out with Lua. (https://garry.net/posts/i-fell-out-of-love-with-lua)It would make more sense to use a language that is more in-line with what people are familiar with, such as Python or JavaScript. If sandboxing is a issue(EG: Preventing file access), the V8 engine is what NodeJS uses. NodeJS just implements interfaces such as file access into V8. Otherwise, V8 is just a engine for JavaScript without any bells/whistles. (https://v8.dev) Javascript even comes with the benefit of being able to do WASM, which is almost on par with native machine code.
If Lua is ultimately the decided language, I really
really
do not see myself using it. I had to use it recently to implement interfaces for a DNS service(PowerDNS), and it was horribly painful to work with, because it felt like everything I knew about programming was thrown out the window.I highly ask that a second look be taken on which language to use for client side scripting, I really do not feel that Lua fits with Second Life, and that there are much better choices to choose from, especially ones that would better align with what people who do programming in Second Life are familiar with.
Log In
Send Starlight
I agree with you that JavaScript would have been the perfect fit. I don't mind Lua, though, and I'm in the anything but LSL camp. Though, unfortunately, if they're deadset on Lua they're locking themselves into a language that is contrary in design to literally every other language out there so I definitely see your point of view. They're not preparing developers for the real world, almost no one uses Lua anymore and not really for anything serious when they do. This is going to be a language we're stuck with for a very long time on the platform sadly. If they had picked something like JS literally everyone in the world knows it. Though, honestly even Lua is a relief, they've saddled us with LSL far too long. I'd take Pascal at this point.
WolfGang Senizen
I know that lua is pretty much locked in afaik.
But I'd like to throw wasm into the "ring" as a direct target not via v8, just a straight wasm runtime.
With GC now in the formal spec there is very little preventing any language from compiling to / running on wasm directly.
For instance https://github.com/web-devkits/Wasmnizer-ts allows you to compile typescript directly to wasm.
There are aslo several projects that allow lua to run through wasm.
It may however unfortunately be a little too soon to integrate easily, as the C and C++ api is still a phase 1 proposal. (https://github.com/WebAssembly/wasm-c-api) but is implemented in wasmer-sdk for instance (https://github.com/wasmerio/wasmer/tree/master#wasmer-sdk)
It would however be harder for a new user to pickup without a premade workflow, or some sort compiler for say lua bundled with the viewer somehow.
Send Starlight
WolfGang Senizen LL probably has to consider heavily the security issues presented by swapping a new scripting system in and Wasm would probably have made them nervous. They do unfortunately have to deal with a pretty critical rogue faction on their platform that tests the boundaries of what is possible on a regular basis. If I had to guess that might be why they leaned towards Lua.
WolfGang Senizen
Client side that should be less of an issue, people are already using TPV's, for which they just download arbritary binaries for, as long as there is no way to load unsigned/unverified (see my suggestion) remotely then that security aspect is pretty much mitigated.
And wasm is designed to allow remote loading of arbritary code, so its view of security will likely be above and beyond most lua implementations, which are generally designed not to load arbritary remote code (roblox being probably one of the few examples of where it does i can think of)
Bleuhazenfurfle Resident
Lua's ugly, true, and I don't much like it myself, either. But it's not much worse than JavaScript, which also suffers from those same criticisms; Map vs. Array, as the simplest example. (Mainly as stress relief, many of my JS/TS projects contain an ever-growing file with a list of all the annoying horrible things JS does badly, which have caused me bugs in the project.)
I do also think Lua is probably a little more "beginner friendly" than JavaScript — though it is also a very distinct language, so coming from LSL, JS might be less of a shock. On the other hand, that may be a disadvantage — looking too similar, might well also be it's own source of confusion (especially being one is typed, and the other is not, some operators will have different precedence, etc.). Also, Lua isn't the first language to use 1-based indexing, I grew up on Pascal which lets you choose your own start index (and I distinctly remember starting with 1-based, and slowly gravitating on my own, towards the 0-based indexing we all know and love).
And Python, unfortunately, is really hard to sandbox — the curse of a language being "too powerful"…
Lastly, the Lua and JavaScript interpreters are at least specifically designed to be running potentially unsafe foreign code. (Seriously, JavaScript should never have been let anywhere near the internet — but, it's what we have, and a LOT of effort has been put into making it both performant, and safe.)
Personally, I'm ambivalent on the Lua vs JavaScript debate, and totally think C# on both sides would just be better all round, but either is a far sight better than some obscure scripting language almost no one knows (I don't recall hearing of the two previously mentioned here, and I've got a square dozen distinct real languages under my belt — over two dozen if you count esoterics and variants as well). A language that people actually use (unlike those other two, or LSL for that matter) also means there's plenty of resources to learn from (and ChatGPT might actually produce working code — maybe that's a bad thing).
Send Starlight
Bleuhazenfurfle Resident I love C# but it probably would have made a terrible scripting language, unless they integrated blazor or something. C# is just a bit too wordy otherwise. JS, Python and Lua make better options but each have their own caveats. I think a well tightened JS would have been the best bet. But, I'll take Lua over LSL tbh. Heck, let's stick Perl in there. xD
Bleuhazenfurfle Resident
Send Starlight: I'm repeating myself a bit here, but I think it's critically important for this application, not just looking at the languages on the surface. They have to fit the task, too:
I completely agree C# is too wordy, and I use it about as little as I can get away with – it was, after all, specifically Microsoft's answer to Java. The key as far as LSL is concerned, though, is that it compiles to the same bytecode engine they're already using (Mono), and it has "compiler as a library" facilities already in place that have been used for exactly this purpose, with hooks and all the lovely things to let it be sandboxed and twisted as necessary — and like Lua(u), it's already proven to the task. The biggest downside I think C# has, is it doesn't really have a simple mode — you've pretty much got to jump right into the fire (at least, that was the case when I was first learning it, that might have improved since).
In Lua's defence, it's a pretty complete language, though some things in it are rather painful. Most importantly though, it was intended for just this purpose, and Luau apparently doubles-down on that — they not only get a language both intended and proven to the task, but in a practically ready-made package, complete with a bow on top. As much as I'm not fond of it personally, I'm not in the least bit surprised they went with Luau for this.
As for JS… JS isn't fit for anything. It's a wonderful academic language — for the same reason Klingon gets taught in universities; it's a master-class in how
not
to design a language (though Klingon was designed that way intentionally). JS is also woefully incomplete, inconsistent, and has the feel of two different languages glued together in many places, and I'm sure is popular only
because it was shoved into an existing empty space, and by pure fluke, nothing decent has been able to dislodge it. That said, like Luau, the JS engines are designed to run untrusted code from the get-go, there's a raft of limitations in the language specifically to support that environment (because it wasn't designed to support it initially — it was barely designed at all), and a lot
of time and money has been spent making it performant, despite itself (not to mention shoring up the remaining holes).Python (my personal favourite out of this group) is a proper consistent and comprehensive language, everything you'd want, but it wasn't designed to run untrusted code and coercing it to do so is a major challenge (I've seen a couple efforts, but nothing concrete that could be applied here). Unfortunately, that power, expressiveness, and flat out capability that makes it so popular, also makes it seriously hard to optimise, although JS has shown the way (hard-core JIT'ing) and they seem to be finally starting to tackle that issue proper (Python has JS's difficulties with optimisation, but squared). As much as I love Python, I can't see it being a serious contender here, especially where untrusted code is a concern.
So all up, I see C# and Lua being the only viable options so far, out of everything that's been suggested to date. (And I'm not even going to grace Perl with a response — it gets a dishonourable mention.)
Send Starlight
Bleuhazenfurfle Resident Oh, I was joking about Perl. But, it's not such a bad language pretty performant and fairly easy to code in tbh. It gets a bad rap for being difficult because regular expressions, which is its strong suit, are hard in general to understand. But, I'd never use it for embedding into a game. They could use Visual Basic .NET... ;D
Woolfyy Resident
As mentioned by Garry Newman (https://garry.net/posts/i-fell-out-of-love-with-lua), JavaScript would be a much better choice and is already largely supported. Moreover it would be easy to integrate by LL even on prims too ...
It is always cautious to remember that opening the door to external languages is also the best way to open the door to all the crappy stuff that goes with it ... especially in terms of security and privacy.
Imaze Rhiano
LUA is good enough for very simple user interface scripting - but it is not good enough for larger viewer side projects - like games. Choosing LUA as your scripting language is going to limit SL viewer to simple user interface mods.
I don't understand why to go this way. Yes - integrating heavy duty languages like C# would have needed more work - but would have given much bigger platform to build applications for SL. This is going to hurt you in future, when you want to expand SL viewer out from its box.
Gwyneth Llewelyn
Imaze Rhiano not necessarily true. See how Adobe Photoshop, Autodesk (AutoCAD, Maya, and their ilk), or even Blender — and Emacs! — deal with expansions to their core applications. The application itself is written in one programming language; the extensions/plugins/expansions/external modules are written in something completely different, and even that doesn't remain static forever (except, well, for Emacs, which is — and always will be! — written and expanded in its own dialect of LISP). E.g. Photoshop used to require compiled-in plugins — a problem when porting from the Mac to Windows or vice-versa — and slowly moved to allow Python and now even Lua. AutoCAD used Autodesk's dialect of LISP, but over the years it started accepting others, too. Blender is also mostly Python and Lua, if my memory doesn't fail me. Lots of others (VLC comes to mind) have started by allowing a
lot
of different programming languages, but, over the years, converged towards Lua (not because it's the "best" choice, but it's likely the fastest to integrate).Also, you
can
extend the SL Viewer today
via LEAF — which is language-agnostic, since extensions/plugins are supposed to run on their own processes anyway. Internally, LL seems to be exploring LEAF plugins written in Python, but that's _their_ choice; you can use C# for that if you wish.No, the question here is to give end-users a
simple
way to be able to script changes to how the viewer
presents information — beyond simple XML-based styling, that is. We're not really talking about major changes, such as using the viewer as a component of a much larger system. Instead, I believe that what LL is aiming at is to have a reasonably standard (and secure!) way to do communications between the user, the viewer, and in-world scripts — such as it is possible to do with the Firestorm LSL Bridge, or the RLV protocol, used by every TPV, and notoriously absent from SL.It would also mean that things like HUDs would not require any in-world scripting, but would rather be elements integrated into the viewer, which just happen to communicate with in-world objects (and avatars). Similarly, parts of the whole system could (finally!) be removed from the "core" and pushed to the Lua VM — a good example being text chat, for example, or even inventory. After all, we do have
voice
chat running on an external process (via LEAF!), and have that for years and years, thus proving that there are many things that do not strictly require being a part of the SL environment as rendered by the viewer
) already — why not text chat?Coffee Pancake
Ideally it should be the same language as used to script in world objects. It also needs to function the same. I would vote C# for both.
A language that is superficially like LSL yet inherently different isn't doing any of our skilled content & in-platform creators any favors, plenty of whom learnt programming with LSL.
Client side scripting lives and dies by the depth of it's hooks, it would be helpful if these were consistent between client and server side. Practical use cases require that they go extremely deep into the viewer code. Deep hooks raise all manner of concerns, not least of all security.
I find it notable that SL viewers have had LUA on and off before with minimal traction. The active implementation in CoolVL appears to serve limited use cases - Keeping Henri busy updating it, minor (extremely limited) viewer UI additions, edge case personal use automation.
There is no possibility client side scripting could even come close to the functionality built into TPVs with C++. TPVs are not "skins".
Kristy Aurelia
Coffee Pancake C# is definitely a good fit. LSL states would pretty much map to a C# class 1 to 1, where each event handler is just an overrideable method.
Henri Beauchamp
Coffee Pancake
C# is not cross-platform... and it is relying on an enormous runtime.
Lua got the immense advantages that it is small , its library can be statically linked to the viewer (no need for a runtime), it is designed with a C API making it easy to integrate in the viewer code, it is fast and easy to learn, it is dead easy to expand with custom functions.
As for my implementation, it is extremely powerful (you can design your own floaters, with your own functionalities, if you want, you can also run up to 8 Lua threads in the background and have them interacting with the viewer). You should read the manual more carefully before drawing conclusions. :-P
Kristy Aurelia
Henri Beauchamp Unity runs C# cross platform just fine.
Henri Beauchamp
Kristy Aurelia
The viewer does not use Unity !
Under Linux, to use C#, you need Mono or Wine-Mono, and either of them is not guaranteed to be available/working properly in all distros (some distros don't even compile Mono any more, others got totally outdated versions, and Wine-Mono means you need to install and run Wine too just to use a Mono application, meaning it won't even work within the viewer but would need a plugin system)...
It is also an enormous, fat dependency (including under Windows , with .NET) which is best not turned into a requirement to run the viewer !
Coffee Pancake
Henri Beauchamp If a distro can't run mono off the shelf, it's not much of a distro.
Henri Beauchamp
Coffee Pancake
Some have "switched" to Wine-Mono, with the rationale that Mono stuff is mostly Windows stuff... Yes, it is stupid, but that's how it is.
This is also the result of Mono not being properly developed any more for native Linux.
Jeremy Duport
Henri Beauchamp FWIW arch, redhat, and ubuntu are examples of linuxes shipping native dotnet packages. https://packages.ubuntu.com/jammy/dotnet-apphost-pack-8.0
Diamond Caudron
Henri Beauchamp Is Mono even needed for C# in Linux with Microsoft now providing open source .NET Framework for Linux, macOS and Windows? https://dotnet.microsoft.com/en-us/download/dotnet
Jeremy Duport
Being the lowest common denominator of 2000s UI scripting does not equate to being the only option - or even a pleasant option. Lua is a major turnoff to be honest, especially with many equally embeddable and better-GCing options like (https://dascript.org) and (http://squirrel-lang.org/) floating around, many of which exist for the express purpose of addressing its significant shortcomings as a language.
Kathrine Jansma
Market share and knowledge is a significant quality of its own. While JavaScript probably dwarfs anything else in this domain, i would assume Lua is still at least a magnitude more know than both dascript or squirrel.
primerib1 Resident
Well, CVLV has already successfully integrated Lua. At this point, LL is probably going to adopt & adapt CVLV's implementation, because it's already operational for quite some time, lots of teething issues have been solved by Henri.
There is zero example of Python/JS being implemented in a TPV, which means LL needs to do heavy-lifting of not only building a whole set of interface, but also how to sandbox Python/JS.
Unless you can provide a working example of Python/JS being embedded into a TPV, I don't think LL will back down from their plans of embedding Lua into SLV.
Chaser Zaks
primerib1 Resident I'd consider it, but:
- I don't even know the scope of the project viewer. Is it just LEAP for developers but integrated into the viewer, or something intended for non-developers to use, or is it something thats going to be integrated with in-world content? LL has not made this clear yet.
- I don't know if it is going to die like puppetry. Why work on something if it isn't going to make it to production? Puppetry was looking good for a bit but then just suddenly "nope'd".
Kathrine Jansma
Actually embedding Python into anything multithreaded like the SL viewer is a absolutely horribly bad idea. It works fine for as embeddable language for other solutions, but once you do multithreading, Python starts to throw tons of problems your way that you don't have with JS, Lua and others.
Some people embedded Python for example in lldb, the LLVM Debugger, and all the problem of the talk at Europython 2011 were like "oh, that didn't work due to python threading gunk and we hacked around it" (https://pyvideo.org/europython-2011/combining-embedded-and-interactive-python-in-a-de.html)
Jessicatz Fairymeadow
I love LUA.