Can SL convert LSL scripting to C++

[Rob Huntsman]

I was wondering if SecondLife will ever decide to ditch the LSL scripting method and change to C++, Javascript, or other modern scripting tools. With the scripting tweak, would probably bring in more game, and web designers for it being easier to code and not needing to learn a completely new scripting language.

Edited July 25, 2019 by Haselden

[bigmoe Whitfield]

This is not ever likely to happen, I think at one point there was discussion on bringing in another language but it's not happend,  and the whole of SL scripting, everything is LSL, so it will never be gotten rid of.  

[kiramanell]

Extremely unlikely. LSL is an event-driven language, entirely unlike C++. And Javascript, outside of HTML, is a joke. And C++ is actually a lot more complicated. Not to mention the enormous breakage such a change would cause with existing scripts. Would be tantamount to an ELE (Extinction Level Event) to SL. Just learn the language.  It's actually pretty easy (compared to other higher high-level languages).

Edited July 25, 2019 by kiramanell

[KT Kingsley]

LSL itself is a pretty simple language with enough similarities to many others to be easy to learn by anyone who's ever done any scripting. It does lack some features, such as arrays, but it does have work-arounds for these that do work.

The big learning curve with LSL is the large number of unique functions for performing in-world tasks, and the way SL works and how you have to approach its specific needs, factors that'd still be present in any other scripting language. This would still present a significant challenge to anyone coming to SL, even if it used a scripting language with which they were familiar.

Having said that it was mooted sometime around the introduction of Mono that C# might be instituted as an alternative. I'm not sure why it never did get implemented: maybe something to do with some layoffs at the time.

Edited July 25, 2019 by KT Kingsley

[Rob Huntsman]

2 minutes ago, kiramanell said:

Extremely unlikely. LSL is an event-driven language, entirely unlike C++. And Javascript, outside of HTML, is a joke. And C++ is actually a lot more complicated. Not to mention the enormous breakage such a change would cause with existing scripts. Would be tantamount to an ELE (Extinction Level Event) to SL. Just learn the language.  It's actually pretty easy (compared to other higher high-level languages).

But colleges do not teach LSL....Colleges teach C++, C#, Javascript, and HTML. In addition, this next decade even more people will have college degrees knowing these modern languages. LSL is a dying language, I think its time to convert at-least do C#.

[Qie Niangao]

I really doubt any choice of language would bring more experienced programmers into SL scripting. After the first half dozen or so languages one learns, the language stops being a gating issue, instead (as KT suggests) it's all the functions in the library(-ies) necessary to do stuff in the target environment.

Once in a very great while I'll wish I could just drop in an algorithm written in a different language, but usually it needs a total rewrite anyway to optimize for the constraints of SL scripts -- memory in particular.

[kiramanell]

Just now, Haselden said:

But colleges do not teach LSL....Colleges teach C++, C#, Javascript, and HTML. In addition, this next decade even more people will have college degrees knowing these modern languages. LSL is a dying language, I think its time to convert at-least do C#.

 

Good thing is, LSL doesn't require a college level education.  Anyone who's ever done some programming, will pick up the basics fairly quickly. After that, the only hard part (for me) was quaternation; the rest is just familiarizing yourself with the various functions, and the somewhat awkward, but still doable, way of dealing with lists, instead of the usual arrays.

[Wulfie Reanimator]

There was a time when LSL had Classes like object-oriented languages, and when Mono was implemented, there was consideration about supporting at least C# as well. (But that was a long time ago.) The Boost library used for LSL is written in C++.

While C++ is not an "event-driven language," there's absolutely no reason why C++ couldn't be used in an event-based context. People do, it's nothing special.

[Chaser Zaks]

Technically speaking, it is "possible" but C/C++ would unlikely be on LL's radar as a secondary scripting language, due to it's complexity.

As of right now, LSL is transcribed into C# if using the Mono engine, so if anything, a secondary language would be C#, or maybe transcribing Python/Javascript into C#.

I'd personally love to see a more object oriented version of LSL, maybe one day we can have LSL3 and it'll add stuff such as dictionaries, array accessors(someArray[2]), modifying values, callbacks/lambdas, etc.

Edited July 25, 2019 by Chaser Zaks

[Rhonda Huntress]

LSL is not a programing language.  It is a scripting tool.  Its syntax may mimic C but it is closer to a batch file.  It will call functions defined server side and nothing more.  If you think malicious code exists now, just imagine what would be out there if it were able do something as simple as pointer math. Nope.  They will never expose end user systems like that.  We will forever be confined to working with "safe" functions and forced delays.

 

 

[Wulfie Reanimator]

3 minutes ago, Rhonda Huntress said:

LSL is not a programing language.  It is a scripting tool.  Its syntax may mimic C but it is closer to a batch file.  It will call functions defined server side and nothing more.  If you think malicious code exists now, just imagine what would be out there if it were able do something as simple as pointer math. Nope.  They will never expose end user systems like that.  We will forever be confined to working with "safe" functions and forced delays.

Two things:

1. Scripts are effectively "sandboxed," they cannot do anything outside of their own "space."
2. While supporting another language, like C++, you can very easily prevent certain things from being done.
   1. You can block memory access outside of the script.
   2. You can just... not support pointers.
3. Bonus: You can still enforce delays as well. The server is still in full control, even if the syntax is some "scary" language like C++.

[Scylla Rhiadra]

Although I know a bit of javascript, Python, and XSLT, I am by no one's definition a coder, which makes me uniquely unqualified to talk about this, except . . .

. . . there are an awful lot of people in SL, including creators, who, like me, are also not coders.

LSL is a simple, nicely contained language. It's simple enough that even I can produce simple scripts sufficient to do about 90% of whatever I might want to do. And it's simple enough, also, that I can generally go into someone else's script and mess with it to make it do the things I want it to do.

Introducing a much more expansive and complicated language like C++ would undoubtedly make things easier for trained coders, but trained coders surely are not the problem? Any reasonably competent coder (or, like me, even non-coders) should have the basic skills to learn a new language, especially when it is as simple and contained as LSL. If I can do it, they sure as hell should be able to, and with a great deal more facility.

The point is that moving to something like C++ would essentially disable anyone in SL who doesn't have a background in more complex languages from being able to code themselves. The change would be somewhat like what has happened to building since the advent of mesh: we'd end up with a much smaller, more highly specialized cadre of people doing scripts, and there'd be that much less creativity possible from everyone else.

We don't need to cater to the specialists: if they don't already have the skills to learn a simple language, then they are not worth considering. What we need (and, in fact, have in LSL) is a language that is accessible to non-specialists. A move in the other direction would just hammer another, very large, nail into the coffin of SL as a creative platform.

[Madelaine McMasters]

I'll parallel Qie's observation. Coding in LSL is much more about understanding the function library and event model than understanding the syntax and semantics of the scripting language. As a language, LSL is much simpler than OOLs. LSL may frustrate those of us accustomed to the power of more sophisticated languages, but catering to those folks would be akin to the shift from in-world prim building to out-world mesh creation that Scylla mentioned.

If the ditch between creators and users hasn't been made deep enough by Blender, C++ would be my shovel of choice.

Edited July 25, 2019 by Madelaine McMasters
If at first you don't succeed...

[Bree Giffen]

If LL were to ditch LSL for a new scripting language it should be for an even easier to use scripting language. Something that would only require a primary school edumacation. 👶

[kiramanell]

15 minutes ago, Scylla Rhiadra said:

Although I know a bit of javascript, Python, and XSLT, I am by no one's definition a coder, which makes me uniquely unqualified to talk about this, except . . .

. . . there are an awful lot of people in SL, including creators, who, like me, are also not coders.

LSL is a simple, nicely contained language. It's simple enough that even I can produce simple scripts sufficient to do about 90% of whatever I might want to do. And it's simple enough, also, that I can generally go into someone else's script and mess with it to make it do the things I want it to do.

Introducing a much more expansive and complicated language like C++ would undoubtedly make things easier for trained coders, but trained coders surely are not the problem? Any reasonably competent coder (or, like me, even non-coders) should have the basic skills to learn a new language, especially when it is as simple and contained as LSL. If I can do it, they sure as hell should be able to, and with a great deal more facility.

The point is that moving to something like C++ would essentially disable anyone in SL who doesn't have a background in more complex languages from being able to code themselves. The change would be somewhat like what has happened to building since the advent of mesh: we'd end up with a much smaller, more highly specialized cadre of people doing scripts, and there'd be that much less creativity possible from everyone else.

We don't need to cater to the specialists: if they don't already have the skills to learn a simple language, then they are not worth considering. What we need (and, in fact, have in LSL) is a language that is accessible to non-specialists. A move in the other direction would just hammer another, very large, nail into the coffin of SL as a creative platform.

 

^^ Very well said... as always, LOL.

The reason SL is so thriving, is precisely because it's easy. Or, another way of putting this, is saying Sansar is such a bust, precisely because you need an Advanced Degree in Blender first; aka, the threshold is way, way too high for normal ppl (like yours truly). SL itself should not repeat the same mistake with LSL.It should be kept delightfully low-threshold oriented, where you can write your first "Hello world!" within seconds.

[Da5id Weatherwax]

"But colleges don't teach LSL..." Of course they don't. They don't teach shell script or perl either. They don't teach Haskell, they don't teach whatever language... If you think your college is teaching you "a programming language" you are missing the point. They are teaching you to think like a coder - how to break down the process you wish to automate into generalizations that can be formalized and defined in A programming language, not necessarily THIS programming language. 

If you can code, you can look up the syntax to write that code in any language. If you can't it doesn't matter how many languages you know.

[Wulfie Reanimator]

I would reassure @Scylla Rhiadra and @Madelaine McMasters that in this hypothetical world, C++ would be an option just like LSO and Mono.

And I believe it's not even the specific language that matters, but some of the specific features they have. @Chaser Zaks gave a good example with list accessors.

list choices = ["A", "B", "C"];

// current LSL:
list item = llList2List(choices, 0, 0);     // ["A"]
string selection = llList2String(item, 0);  // "A"

// C++ array accessor, with implicit typecasting:
string selection = choices[0];              // "A"

Sure, in C++ specifically a "list" (array) must be of a single type unlike LSL lists which can have mixed types. That's not the point, the point is reducing the amount of typing we need to do what we want to do. I don't think this change/addition would be disliked or difficult to understand by most people. Another useful thing from C/C++ is grouping of different data so it is easier to pass around. Here's a practical example that I would accept as an addition to regular LSL code.

// Describe a user and pass that data into a function to make bad decisions.

// LSL:
    // No easy way to store all of this into a single list.
    // "inventory" might have more or less items.
    string name = "Wulfie Reanimator";
    list inventory = ["glasses", "hot chocolate", "pillow"];
    float awake = 129600.0;

    Function(name, inventory, awake);

// C-like structure (not exact syntax, but very close)
    // Define the structure and name it.
    define user {
        string name;
        list inventory;
        float awake;
    };

    // Now there is a new type called "user", just like "list" or "string"
    // Let's use it to define... me.

    // either
    user nina = {
        "Wulfie Reanimator",
        ["glasses", "hot chocolate", "pillow"],
        129600.0
    };
    // or
    var nina = new user {
        name = "Wulfie Reanimator";
        inventory = ["glasses", "hot chocolate", "pillow"];
        awake = 129600.0;
    };

    Function(nina); // The function call is now simpler too.

    // And it's easy to store and access grouped data to/from a list:
    list storage = [nina, rolig, chaser];
    user test = storage[0];

    llOwnerSay( test.name ); // "Wulfie Reanimator"
    llOwnerSay( (string)(test.awake / 60 / 60) ); // "36.00000"

I don't believe this would complicate LSL. A structure like that is almost like another list, but more flexible, and this could be one workaround for "LSL doesn't support lists-within-lists." (Did I mention C++ has lists-within-lists and multi-dimensional lists? Down with strides!)

Edited July 25, 2019 by Wulfie Reanimator

[animats]

It shouldn't be that hard to support C# on the Mono engine. Open Simulator does that.

The problem is keeping the size of scripts down. With a real programming language with real data storage, people would want much larger scripts. Those come out of sim server memory. If people started pulling in C# libraries in scripts, memory consumption would go way up.

You can do real programming in LSL. It's not fun, but it's possible. Here's a maze solver I wrote recently, for my NPCs.

[Kyrah Abattoir]

I wouldn't mind a language that supports references, just for the memory saved.

[animats]

Here's an idea: "remote scripts". This is something halfway between existing LSL scripts and using an external web site.

You'd check a checkbox to indicate a script was a "remote script". You'd get a choice of LSL or C#, because Mono can run both.

Remote scripts would run on ordinary web servers under LL control. They'd be associated with an in-world object, but would work a little differently than regular scripts.

• Remote scripts could make LSL calls allowed for the object, but they'd be slower, because they'd be sending messages to a proxy on the sim to ask for something to be done. Remote scripts would know the object and user to which they belong, and permissions would work accordingly. That's the big advantage of having this inside the LL world.
• Remote scripts and regular scripts could send messages to each other.
• Remote scripts would have access to a key/value store, like experiences do, and optionally to an SQL database, if you'd created one via some LL web interface. So you could store real data. There might be a charge for having a full database, but you should get 10KB or so of key/value store for free. This provides enough data storage for vendor systems, game managers, etc.
• Remote scripts would be able to open on-screen windows for dialog boxes, using the "media on a prim" mechanism. They'd be full web pages if desired, but normally they'd just be generated by some standard UI library. So remote scripts could offer a full user interface. As with media on a prim, there's a connection between viewer and web server that bypasses the sim servers once set up. So this wouldn't add to the load on the sim servers.
• Remote scripts would be semi-persistent. Variables would be preserved for a while, but not forever. If the script was idle for a while, it would receive an "idle" event, and the script would have to save its state to the key/value store if it needed to pick up from there later. On the next use, the script would start from  It will get a default state entry the next time it is used. This keeps from having to store huge amounts of inactive script state forever.
• Remote scripts could be much larger than server scripts. A few megabytes, at least.

This would essentially be LL offering shared web hosting with some extra SL integration. You could almost implement such a connection in LSL right now, using your own web server. But it would be better if LL did it, because the security and integration would be tighter.

Use cases:

• Appliers, resizers, and such.
• Anything that needs more dialog options than the LSL dialog boxes support.
• In-world creation and editing tools. LSL is too cramped for that, but with an external server and C#, it becomes possible. A good place to start would be in-world paint. (You'd still have to pay the upload fee to use the result in world, of course.)

[Da5id Weatherwax]

I like the way you think, animats....

And while they are at it could they please give us a working regex engine? We actually do at least as much string handling as math in a lot of LSL use cases and that's a huge hole in capabilities.

[Kyrah Abattoir]

@animatsSounds good as a premium perk

[Mollymews]

On 7/26/2019 at 2:13 AM, Bree Giffen said:

If LL were to ditch LSL for a new scripting language it should be for an even easier to use scripting language

agree

i would like a smarter parser/compiler. Example:

value = 1;   // the parser knows that value is an integer

value = 1.0; // the parser knows that value is a float

value = "1"; // the parser knows that value is a string

value = [ 1, 1.0. "1"];  // the parser knows that value is a list

value = 2 / 0.5;  // the parser knows that value is a float

llSay(0, value);   // whether value is integer, float, string or list. the compiler knows to output value to the console

 

am not suggesting that type-casting be eliminated. The smart parser/compiler can do both

 

 

 

[Fionalein]

On 7/25/2019 at 1:58 PM, Haselden said:

I was wondering if SecondLife will ever decide to ditch the LSL scripting method and change to C++, Javascript, or other modern scripting tools. With the scripting tweak, would probably bring in more game, and web designers for it being easier to code and not needing to learn a completely new scripting language.

if you understand at least 2 languages you should not have any problems with LSL whatsoever - if you don't understand even 2 languages I would hardly call you a scripter...

[Wulfie Reanimator]

35 minutes ago, Mollymews said:

agree

i would like a smarter parser/compiler. Example:

value = 1;   // the parser knows that value is an integer

value = 1.0; // the parser knows that value is a float

value = "1"; // the parser knows that value is a string

value = [ 1, 1.0. "1"];  // the parser knows that value is a list

value = 2 / 0.5;  // the parser knows that value is a float

llSay(0, value);   // whether value is integer, float, string or list. the compiler knows to output value to the console

 

am not suggesting that type-casting be eliminated. The smart parser/compiler can do both

This (dynamic/weak typing) is essentially what JavaScript does.

It has problems though, such as the compiler (if there was one) not being able to make sure that the script won't error or crash because of a type-mismatch.

a = 123;
b = "abc";
c = a + b; // no warning while saving the script, but will error/crash

Whether or not this would cause the script to crash entirely can be determined by how the feature is implemented. The script could, for example, just give a debug error and keep running, but it will either start producing more errors or not doing what was intended if the script relies on that third variable. What would the type even be?

 

22 minutes ago, Fionalein said:

if you understand at least 2 languages you should not have any problems with LSL whatsoever - if you don't understand even 2 languages I would hardly call you a scripter...

Look up "gatekeeping."

Edited July 29, 2019 by Wulfie Reanimator