Can SL convert LSL scripting to C++

[Qie Niangao]

11 minutes ago, Fionalein said:

if you understand at least 2 languages you should not have any problems with LSL whatsoever

I was all set to agree, especially if one of those languages is C++ (because of the syntactic overlap), but then I got to wondering: what must it be like to have learned only object-oriented languages? How big of a handicap would that be? Would an OOP-only graduate be able to work out how to write even a shell script, having none of the object-oriented virtues at their disposal?

Back when I was relatively new to LSL, I did feel deprived of stuff like a built-in preprocessor for #includes and #ifdef and etc., and the lack of a case construct but I've come to think of the stripped-down language as a helpful reminder that the execution environment (memory, processor time) is strictly limited too.

[Mollymews]

@Wulfie Reanimator

in the case of  c = 123 + "abc" then like in Microsoft Visual Basic when a smart parser can't resolve what it should be, a type mismatch error is thrown at compile time

edit: Qie got in the way so I edit add your name

 

 

Edited July 29, 2019 by Mollymews

[animats]

LSL isn't that bad for what it does. A few minor optimizations I'd like, to increase performance and reduce memory usage:

• For lists, if you write lst = lst + ["abc"]; the compiler should recognize that as an idiom and do a replace in place. This should apply generally to anything of the form lst = (some expression containing lst). Programs execute exactly the same, but use less memory and go faster. CPython uses this optimization on strings. They're supposedly immutable, and adding a character to a string should mean a copy. It doesn't really work that way internally, since that would be very inefficient.
• Along the same line, if you pass a list to a function, it doesn't need to be copied unless it appears on the left side of an assignment within the function.
• The "lazy lists" feature of the Firestorm LSL preprocessor should be standard, and optimized as per the first item above.

This gives lists array-like random access performance without affecting existing code.

 

[Da5id Weatherwax]

7 hours ago, Qie Niangao said:

I was all set to agree, especially if one of those languages is C++ (because of the syntactic overlap), but then I got to wondering: what must it be like to have learned only object-oriented languages? How big of a handicap would that be? Would an OOP-only graduate be able to work out how to write even a shell script, having none of the object-oriented virtues at their disposal?

Back when I was relatively new to LSL, I did feel deprived of stuff like a built-in preprocessor for #includes and #ifdef and etc., and the lack of a case construct but I've come to think of the stripped-down language as a helpful reminder that the execution environment (memory, processor time) is strictly limited too.

Well, you can write perfectly functional code that is acceptable to a c++ compiler without declaring or using a single object. Of course, you'd actually be writing vanilla c....

[Fionalein]

5 minutes ago, Da5id Weatherwax said:

Well, you can write perfectly functional code that is acceptable to a c++ compiler without declaring or using a single object. Of course, you'd actually be writing vanilla c....

It is actually what most college people with just one or two programming courses in C++ do.

Edited July 29, 2019 by Fionalein