do you think scripting should be easyer

hey just outa curiosity does any of you think scripting should be easyer?

No, I don't.

No.

Besides, it can't get any easier without a brain upgrade.

Yes, its called learning.

No.

LSL is already so simplified in comparison to 'real' programming language that people have to jump through some awful hoops at times to get things to work. If you made it any simpler, you might as well not bother.

C++ is paradise compared to LSL. Things like #includes, makefiles, CVS, libraries, documentation. Programming in LSL is psychological torture.

Yes, I think LSL could be a *lot* easier.

That said, I assume your question is not about things like tools available to programmers so much as the ease of learning LSL itself.

Again, my answer is: it could be tons easier. LSL is very non-standard. Whilst it's based heavily on C, it's a very cut down version of C. A scripting language should be loosely typed: if I assign "test" to myvar, you know that myvar is a string variable. The ll prefixes on everything are tedious and pointless (detail I know but it's important for newbie readability). There are far too many commands with obscure names: why should I use llGetListLength for a list and llStringLength for a string? (off the top of my head; that might not be quite right). Make it GetListLength and GetStringLength or make it ListLength and StringLength, or just use overloading: GetLength.

Ideally the commands would be objectoriented / namespaced ( String.GetLength(...), Sound.Play(...) )

Azelda

I agree with Azelda fully on that.

It could definately be easier. Replace LSL with Python or ruby for example.

No

Nit picking I know, but CVS has nothing to do with C++ at all. In fact, I use my CVS repository for storing LSL scripts. Yeah, I have to cut and paste but it's only a minor hassle.

I definitely wouldn't call programming in LSL a psychological torture.

Sure, there's no fancy IDE but so what? To me, a fancy IDE is a modern luxury anyway

I would like to be able to use #includes though. That is a major annoyance but for the other stuff ... lets not bloat the language up too much with OO crap. If anything, I say give us the bytecode specs and let us go *down* a level.

-AP

Or... Give us the bytecode specs and let us build more powerful languages.

- Ace

Or, give us the API into the SL backend and let us build our own gamelogic directly in C++ for private sims.

Azelda

ah very intresting resoponses

I agree with most of what Azelda posted - except for the Object Oriented part.

I am also doing fine with having to include "ll" infront of functions, but I do agree that some functions could really use more of a standard in their name assignments, and darnit - I could -really- use some dimension-able arrays and includes.

That would be super cool too, although I prefer C. But either way would be fine. I also suspect it ain't gonna happen any time soon

-AP

The question actually spans a very wide territory, as different people are concerned with different aspects of easiness. The main issues are LSL syntax, language safety, execution model, system libraries, and development tools.

In an ordinary programming environment, this kind of question is often a pretty uninteresting invitation to another round of language wars, which are rarely helpful. A competent software engineer will usually know several languages and will program different parts of a non-trivial project using different ones, so it's usually a debate kept bubbling by inexperienced one-language advocates.

Here in SL though, it's actually quite an interesting question, because the execution environment is so highly unorthodox that a lot of the stock programming methods, tools and principles really don't apply very much.

For a start, the LSL language itself is extraordinarily simple and small, so there is remarkably little room for simplifying it further. Some have suggested making variables typeless or having inferred types (two somewhat different approaches) in order to cut down on the type declaration syntax, but doing so doesn't always make programming easier. Semantic complexity (what code means) often increases when syntactic complexity (how it's written) is reduced, because there's more room for ambiguity, and you end up needing to pop in coercions or other nasty things to prevent the compiler from making a choice that you didn't want.

The need for language safety in SL scripting makes some of the options that people have mentioned totally untenable. C++ is entirely unsafe so it isn't a candidate at all, and that rule applies to every other language that can crash a sim too. Of course, you wouldn't want C++ for a pile of other reasons as well, principally because it currently ranks as the most semantically-complex language on the planet by far, and the question was about making SL programming *easier*.

There's another problem though. While many good scripting languages like Python, Perl, and Java can satisfy the safety requirement, to do so they normally have to forgo their most popular libraries and extensions, so you end up having to endure a cut-down subset, and that's quite annoying.

That's not the biggest problem though. The thorniest issue is that SL is built around a pretty esoteric execution model (millions of state machines and event handlers), and LSL is designed to support that concept directly. If your favorite "normal" language were to be used for this, it would either have to be extended and become a wierd derivative, or else the clean model would have to be supported indirectly, and thus less cleanly. This wouldn't make anything "easier".

One easy solution is of course to improve the LSL function libraries, and they're working on that angle pretty much all the time it seems. More powerful functions mean less explicit coding by users and more efficient use of sim resources, so everyone wins.

And finally, better development tools often help to make a programming system more approachable, especially for non-proogrammers. The trouble with that avenue though is that it is very hard to make a tool that is both simple and powerful at the same time, so typically it only assists part of the community and everyone else is unsatisfied. Even worse, it uses up manpower to build such tools, to the detriment of other systems work. And as if that weren't enough, graphic front-ends for non-programmers often act as a brake on the development of more advanced system functionality. So, there aren't any easy answers in this area, unfortunately.

That sort of covers the spectrum of issues in this area. If I had to answer the question directly, I'd have to say that only one of the 5 issues offers much prospect for useful iimprovements. On balance then, the answer is mainly "No" .

That said, it's not as hard as it looks, and if you're the arty kind rather than teccie, you can easily team up with those of us who can program well but can't design a nice texture to save our lives.

Absolutely not.

my suggestions would make LSL more robust but maybe not easier to learn.

i would like to see C structures before full OO.

would like pointers and the ability to upload byte-code scripts. Pointers would have to be able to access all memory of the script.
*dreams of compression & pass by reference*

and i want in-line conditionals
test?true:false

One of the easiest solutions to the ease-of-use problem can be solved indirectly. If LL releases all information available on byte-code, and provides a way to add byte-code into the game, then I wouldn't be too suprised if we see not only people coding in assembly, but everyone's own idea of what is easiest in programming come out as custom compilers.

You could go the Lego Mindstorms route, with "blocks" for functions. But that would turn away all the cool scripter people.

Their time would be better spent developing powerful coding constructs, meaning both communication and composition concepts and world/model entities like vehicles, and better functions. Higher-level constructs would make life much easier for novice scripters, and low-level ones would make the language more capable for experts.

And both kinds would reduce server loading because the sims wouldn't need to process quite so much low-level user code to accomplish any given desired effect. Everyone wins.

Microsoft Quick BASIC was released in 1986, 18 years ago, and that wasn't the first IDE. CP/M was developed as the first PC Operating System in 1974. Using that as a rough guide, we see that the IDE has actually been around for 2/3 of the PC's lifetime.

What surprises me is that the IDE isn't a better tool than it is today. I guess it's because us tech types don't mind a little challenge, and it provides something of an "idiot filter" to prevent the terminally incapable from trying to write computer software.

Hey, ditching the IDE is fine by me. Give us vi or jed + cvs + the ability to easily copy scripts into objects (cp myscript.lsl MyObject) and delete old ones (rm MyObject.myscript.lsl) from a console and thatd be awesome!

In fact, y'know a Quake-style console could be a really easy way to add very powerful functionality into SL's client.

Azelda

I fucking HATE casting. Strongly typed languages are teh suck. Ditch LSL and replace it with python or something like that.

OHH!!!! I can see it now! Resizing / rotating multiple objects with a single line! Regular expressions! w00t!

The main reason LSL sucks is LL's obsession for security and its misguided implementation thereof. Im a developer, not a griefer. There needs to be a system for recognizing different user roles and assigning different trust levels. If I send LL 4000 dollars to get myself a 4-sim island that will cost me an additional $800 every month, then for the love of god let me do whatever I want with it and grant that power to a specific set of users.

Things that are fucked up about (L)SL's design:
-- Objects can only modify themselves. I should be able to modify whatever I own anywhere in the world from my own scripted creations.
-- Distance based restrictions. If I own the land then I should be able to do whatever I want on it. Including rezzing objects at an arbitrary distance.
-- Artificial delays. LSL is laggy enough already. I should be able to IM myself as often as I want, or have a way to laglessly output private debug messages to a debug console.
-- llPushObject. You should NOT have the right to push me or my objects unless
a) I am on your (group's) land or my objects are
b) I explicitly allow it
c) Your last name is Linden and you are in God Mode
-- Sensors. If I own a bunch of objects then I should be able to gather all information from them without having to drop a script in each and every prim or relying in a weird concept of sensor.
-- Keys. I should just be able to iterate over a list of all people or objects in my plot. Or select things by name using pattern matching. Why must I use weird concepts of sensors and keys. I shouldnt need sensors and keys in order to affect objects or retrieve information about them.
-- General guidelines. Protecting people from themselves is a bad thing. Programmers are used to having full control over their boxen.

Meh, I could go on forever but I'm hungry and sleepy. You add to it.