do you think scripting should be easyer

Case sensitivity is a problem?

If you eliminate case sensitivity you have.... er, what's it called? Oh, DOS! (or BASIC)

You're not going to avoid case sensitivity. But having to specify what class a variable is that's tedious. Probably necessary also, so that the compiler is less taxed. I do a lot of scripting in PERL and there are really only three variable types, Scalar, Array, and Associative Array.

Scalar takes care of string, integer, floating, those kinds, and the other two are really basically the same except that one is indexed numerically and the Associative Arrays are able to be accessed with other various indicies (indexes? whatever). I guess I'm spoiled!

That's APL - the original version let you type programs in incredibly short spaces -- but required a large number of characters not found on normal keyboards.


What's wrong with RPN? It's much easier to understand than infix notation.

Pfft, Brainf*ck's easy!

++++++++++++++++++++++++++++++++[>+>+<<-]
>>+++++++++++++++++++++++++<<
++++++++++[>>.-<.<-]

It's simplicity itself!

I don't thuink lsl should be easier. Its not that hard to begin with.
I guess easier would mean higher level, which in my mind would be a little less powerful, not allowing more precise controls over things. Thats where the power in assembly lies, in its precision to control basically everything.

Secks Saito

many people don't know anything about RPN and would be very confused by it (at first at least; fyi xylors xycalc supports RPN, i've made a build of xycalc for ESL that works in 1.5.x)

no slight was intended towards brainf*ck. (and i guess you would be using fingers to represent bits to be able to count the 8 commands on one hand)

I probed a linden on that topic earlier, summary answer was 'not yet.'. Although, I agree, that would be an extremely advantageous feature, but as to be expected, developers have a lot of other things which need to be done first.

-Adam

I want it all now! Hehe

But talking seriously about resources, LL is not really all that distant from the open source community in many respects, in that they use several FOSS packages in SL already and are considering more. Furthermore, with the Linux client hopefully coming out early in 2005 by latest estimates, they're going to get hugely more interest from that quarter pretty soon.

It's all going to add up to a collosal development resource being available that can, with some creativity, be tapped. There are many ways in which only small sections need be exposed to external workers while still working perfectly well when plugged into the SL framework --- the LSL compiler is a good example.

If what Philip Linden said about SL taking over the world is an honestly held goal, there can be no better way of striding out on that path than by harnessing the largest development resource on the planet.

Should LSL be made easier.

Easy is a state of mind. What is easy for some is difficult for others. Take Eggy Lippmann (I hope Eggy does not mind me using him for a reference), for example. (I've read some his posts) For this individual, LSL is EASY! Why? Probably because this individual has years and years of practical experience in programming in RL, probably knows 15 to 20 languages. Eggy, from what I have read, has also been around SL for a long time. Eggy, is very FAMILIAR with LSL. Eggy and others like him are the exception.

I used to teach Programming: C, Pascal, Assembler, Shell scripting, Basic, Fortran, and Unix/Vax Operating System Internals at the Collegiate Level.

I can tell you for a fact that NOT everyone is suited for programming.
Everyone is wired differently and from my experience some people are just not wired for programming.

No matter how hard or how intelligent some people were, some could not get the"programming" light bulb to turn on. A mentor of mine from a long time ago, who used to teach also, used to say this: (before political correctness came into being) "Darlin, maybe you should consider driving a truck!"

But, you know what? That's OK! If everyone was at the same level as Eggy, then where would all of the Naked SL dancers be?

Easy, comes with being familiar with something.

The more you dinker with something the easier it gets.

For me I have a wish list.
1) Add some more meat to LSL:
.....BETTER DOCUMENTATION (updated in a timely manner)
.....FIX CURRENT LSL THINGS THAT DON'T WORK CORRECTLY
.....7863% more coding examples!
.....Arrays (single and multi-dimensional)
.....Structures
.....string handling functions (strcmp, strcpy, strncpy etc.)
.....switch statement
..... and C style /* */ comments to block out code large chunks when dev/debugging

(none of those features would be intolerably difficult to work in to LSL and it would add, IMHO some richness)

2) Minimal Debugging

3) An off line engine that could handle scripts for particles, states, and messaging
(I can't get online as often as many of you and would like to have the opportunity, when I am gone for weeks at a location w/ no broadband, to mess with some scripts.)

So, for the question of making it easier? You can't make the language easier, However:
.....The Linden's CAN make the documentation more readable.
.....The Lindens CAN provide more concrete code examples.
..... - A variety of examples for each function.
.....The Lindens CAN create several WORKING no frills skeleton programs
.....(not code snippets) explaining different SL World functionality.
.....Here is one plausible example that would illustrate states,
.....communication between prims, multiple scripts, and object modification. Newbies
.....could see and work with them to get a better understanding of LSL.

_____ You create a block and three balls.
_____ Each time you touch the block the balls either
_____ can change color, or change texture, or get larger etc.

Beyond that, the rest of the community can do what it has done so well in the past and that is share and encourage the new people

Regards,
wizzie

That was exactly my experience when I was in academia. I used to teach both total beginners (in those days many would reach university without previous exposure to programming, so it was to bring people up to speed for engineering) and also advanced classes, both practical and theoretical, and I couldn't agree more.

It just doesn't click for some people, no matter how hard they work at it, and no matter how much dedicated hand holding they receive. There's some sort of algorithmic planning block, the lack of a strong ability to put stepping stones B, C and D in place in order to go from A to E. No doubt this is something that those who study the psychology of education understand in far more detail.

Anyway, it was pretty common to hear those who couldn't master a language say that the language was too hard, shouldn't engineers use something simpler? Hehe, echos of LSL. No, the problem isn't the language, but programming itself.

As you say wizzie, LSL is already at extreme ground level, beyond simplification. Just removing some required punctuation or making the variables untyped and similar proposals won't help. That's not where the difficulty lies, it's with the semantics of programming, and with people's very diverse ability to handle the process. The language gets the blame, naturally but incorrectly.

Spot on.

Well, here's an example: asynchronous calls.

There's no logical reason, outside perhaps of ease of LSL implementation, why Sensor calls, ReadNotecard and so on are async. Async sensors would make sense if they worked like VolumeDetect: sending an event each and every time something enters/leaves the zone; but thats not how they work.

How cool would it be to be able to do:

integer iNumSensed = llSensor( ... );
llSay( 0, "I see a " + llDetectedName(0) );

Ditto for LinkMessages (ie Xylor's proposal of sync linkmessages).

Along the same lines, the fact that scripts are single-threaded is limiting. Other languages with an event paradigm allow events to execute effectively concurrently (albeit with something like a DoEvents(), depending on the language). Again, it makes it easier to write the LSL VM, but it doesnt do any favors to the people writing the LSL code.

Azelda

Ah, environmental semantics, now that's a very different issue, Azelda. And at least for me, it's a pretty interesting one too. The difficulties you've just mentioned would apply whatever language SL used for user scripting, because they're a property of the infrastructure or framework in which the VM lives, which makes this a great topic outside of any considerations about language.

The poor newbies have 3 different hurdles to jump over:

1. the language syntax, which doesn't usually trouble many people after a few hours or days exposure, although they often think this is to blame (dig deeper with questions and you usually find it's not),
   
   
2. the semantics of the language itself (eg. what does A+B do when their types differ) and of its simpler non-systemic libraries, which can be a difficult hurdle for those who are not natural programmers,
   
   
3. the semantics of the computing environment, which can range from very simple and obvious to so totally wacko and obscure that even hardened binary code sniffers gibber in disbelief.
   

LSL is very clean and simple on item [1]. The language semantics within a function or event handler make hurdle [2] just about passable if one is slightly generous (it's complicated unnecessarily for newbies by the rather messy set of functions and by the fact that you need to use functions at all for elementary data handling). Unfortunately, item [3] may be raising the barrier substantially beyond what the beginner might expect, not only because the entire SL edifice is erected on rather unusual foundations, but because there are some pretty bizarre features scattered around it, like those sensors. Or notecards even more so, because reading a line and having it come in as an event is truly bizarre.

The problem is partly that the SL infrastructure is based entirely on a state/event architecture and split-transaction computing, and neither of those are taught in Programming 101. It's also outside of the "sequential recipe" experience that people acquire naturally not just in the kitchen but through problem solving in general. It's not entirely novel: for example, we are given a ticket when we take clothes to the dry cleaners, and we have to go back with the same ticket in order to continue the transaction. Despite the occasional precedent though, we seem to find it more natural to wait for events, rather than to suspend them, go do something else, and then pick up the necessary state later, and this is what you're alluding do.

Having said that, LL has really done a lot to hide the unusual preference of the architecture that all program activity be transient. We are given a language framework which at first sight seems pretty conventional, but in reality it's a state machine dressed up in modern clothing, and we're not really meant to be doing much in each event other than react briefly. That's pretty foreign to most programmers because event-driven programming is usually restricted to the callbacks of UI applications, whereas here even the "main" entry point is just an event handler for the default state.

Fortunately, LL made a key decision which averted an even greater increase in scripting complexity, namely to force concurrency into separate scripts. Happily, SL programmers seem to have adapted to the single threading and limited event queuing easily, probably because with normal event handlers being short-lived they don't even notice it. It's an extremely good approach by LL because otherwise you get into the O(astronomic) complexity of interacting address spaces or you get into locking or you get into event space separation plus data transfer issues, all of which are utterly no-go areas for beginners. Personally I'd love to play with some shared-space concurrency because I did my research in process interactions, but fortunately LL have more sense than to grab a tiger by the tail. Item [3] is fortunately just unusual and tedious, not diabolically impossible.

None of this is terribly hard for anyone with reasonably broad experience in computing, but I suspect that the combination of the 3 hurdles together creates quite a high barrier for a novice. While LL can't be expected to provide customers with an education in computer science, on the other hand they shouldn't unnecessarily create complication where there is no need either. I think you raise a good point about one-shot sensors and notecards.

LSL is not too bad. It definitely has its wierdness with some of the async events. I do hope they introduce better functions that will eventually depricate some of those. Will that be easier? probably not, just cleaner. If someone can script they can usually figure out the oddness of the async functions.

That said, NO, don't make it easier. I like being good at something most people have trouble with .

LSL isnt hard to code, its just freaking castrated compared to a real language!
It's horribly slow and we have next to no memory to work with. On top of that, we have zero ability to structure data, no switch-case branching and absolutely no direct control over anything, in order to prevent "griefing" or "stealing" or whatever the excuse is today.
In addition, the server-centricness and the streaming paradigm further cripples us because we have zero way of knowing when a texture, sound or object has loaded on this or that user, and the default way of interaction is "an object is always visible to everyone in exactly the same way", which comes in real handy for any game where some data must be both visually displayed and kept secret.
*yawn* have i mentioned how sensors are horribly limited and how we get LL imposing further artificial restrictions on top of the technical ones? Like, ever wonder exactly why it is that llRezObject is limited to 10 meters?
In all my time as an SL coder I have wasted more time and code getting around artificial restrictions than being productive. It's amazing how LSL can still be fun after you've been fighting with it for a year and a half

This is a great conversation. I just wanted to chime in with one of my philosophies: computer science is just as much of an art as it is a science.

Anyone can monkey around with a canvas and make art, however it takes a certian type of brain wiring to make good art. The same goes for programming.

Well put Kex.

Eggy, I like your post.

Kex, I understand what you're saying.

That said, even the most dedicated scripter can jump in and create prims, link them together, add textures. It'll look like sh*t but he/she can do it.

The most well-rounded SL artist will have an awful lot of difficulty making even the most trivial script in LSL.

Azelda

Pffft, assumptions and stereotypes... Az, you know better than this.
Photoshop and gimp can be scripted... so can macromedia flash... just because someone is known as an "artist" in SL doesn't mean they are IDIOTS!

That's just silly.

I know of *many* who have great aptitude for both visual art and coding. Just look around at the vehicles of SL, you'll find many gorgeous builds signed with the same creator stamp as the script that makes them pleasant and fun to drive or fly.

Technical and artistic skills are seperate faculties and can occur seperatly or simultaniously in an individual without effecting one another. If there is a disparity, it's probably due to neglecting one in favor of the other out of personal interest or pressure to focus on whichever is deemed more valuable by family and community.

> Photoshop and gimp can be scripted... so can macromedia flash... just because someone is known as an "artist" in SL doesn't mean they are IDIOTS!

Right. I'm not sure why you're implying we are disagreeing. We agree that it *should* be possible for artists to script in SL.. and yet this thread is rampant with people saying "oh artists cant script, it's a waste of time for them even to try".

Azelda

That's actually pretty insightful, Eggy.

Why is LL so unwilling to even discuss those artificial restrictions, let alone relax them, despite repeated requests?

I don't think that anyone from either camp (if they are not camping in both camps at the same time) will truely believe that because you do not know both that you are deficient in your brain for not knowing the other.

Consider the jokingly said: "Wow these French Children are REALLY SMART, 8 years old and they ALL SPEAK FRENCH!"

Of course they do. They were brought up that way. As obvious as that is, I can see why some people might say that "Programming" is hard. And whether you want to call it by any other name, programming is still a means of communicating that is determined by a protocol or a set of rules. Just like a game is a means of starting at one point, and getting to the end and winning, scripting is similar. Just like in the game rules, a scripting session will also have a place here and there where the rules can be broken, and "winning" is still accomplished.

The point here though, even if you know the rules, it does not mean you will win every time.

Another consideration, compare scripting to playing a game like Reversi/Othello. You can learn the "RULES" to that game in under 10 minutes. You can spend a lifetime getting good at it, or never get good at it.

Programming (to me) is a LOT like that. Many have already said, and I agree. Not everyone can PLAY Reversi/Othello. There's little difference (in the limited respect) between the two!

Ok, I've seen people who dont look scripty at all who can script. They're not brilliant, but you'd be surprised at what people can do. Enough of the "you gotta have a certain type of brain to script". You shouldnt need a degree in MiS to get your object to sprout particles y'know?

Azelda

Whether or not everyone should be able to script or not is a different question entirely though, Az. I'm certainly not competent to answer it, and maybe it's unanswerable outside of the debating room since it gets into issues of rights etc which are matters of opinion.

But the plain fact is that a substantial proportion of even the technical community can't get their heads around programming beyond the most simple bits --- those of us who have been in academia trying to impart that skill can testify to that. Wizzie Baldwin's post on that issue and mine are on the previous page of this thread, based on experience teaching, lecturing, and tutoring. That's just how it is, I saw it daily even among young engineers who you would expect to readily grasp the subject.

And like I said earlier, the problem is the semantics, not the front-end words and symbols. Most normally-reared humans except a small proportion with lookup disorders (dislexia contributes) can handle an enormous number of random words and symbols. The problem is in attaching useful meaning to them and turning them into problem-solving tools. And that isn't a universal skill.

Python gets my vote!

Okay, from my personal perspective -

I've never done any scripting outside of SL. Over the past year, I've taught myself LSL on an as needed basis. It has somewhat felt to me like being immersed in a foreign language.

My experience has been that LSL has been extremely easy to learn when taken in these as-needed chunks. At this point, I'm very comfortable "speaking" in LSL.

So, no, I don't think that it should be made any easier, I believe it is currently easy enough. Doing the amount of scripting I do (which is a fair amount, I like it a lot) I run into a lot of people who ARE scripters outside of SL. Often times, it seems that they are complaining that LSL is too simplistic and weak, but they have found ways around this with hacks.

My thinking is that LSL is, as those bears would say, just right. It's accessible to anyone if they are willing to put some time into it, and if you don't have Time in SL, then you're not playing it right.

It may be weak in someways, but additions and improvements to the functions will over time correct for this.

So yeah, just right. Accessible enough for new people. . . powerful enough for the experienced even if they do have to do some hacks to get things they are used to.