do you think scripting should be easyer

Lua would actually be a really good candidate. It is in use as a scripting language for a lot of games already, is small and easy to learn, and has decent performance.

I'd personally like to see Lisp- or Scheme-like scripting, since those languages are easily extensible, and have been used in a number of games as well, but I am probably the only one who wants that.

As long as I am dreaming, I'd like to use Emacs as an external editor.

I would absolutely love to see a perl implementation. I don't think perl would be that hard to implement as its open source, and the artistic lisence, under which it can be distributed is very unrestrictive.

[This is a repost from my browser cache, after the SL forums database crash lost many hours' worth of people's posts today.]


Ruby? Woohoo, language wars!!!

Execution times for recursive FP factorial(n)
Language / seconds for   n=1            n=180
---------------------------------------------
C                       0.001           0.013
Lua                     0.010           0.080
Ocaml                   0.130           0.180
Perl                    0.020           0.360
Python                  0.110           0.780
Ruby                    0.290           1.230

OK, having got fueling the language wars out of the way (they may be fun but they're all entirely irrelevant, and anyone reading anything into benchmarks has only got themselves to blame), now let's get back to reality.

The tradeoffs that make one language good in one environment can render it useless in another. LSL runs in an environment of a million state machines, massively concurrent reentrant scripts and automatically demultiplexed events, which is totally unlike the normal execution environment of every other language out there.

As a result, if your favorite language were to become the basis of LSL3, it would no longer be your favorite language, because (i) it would have most of its useful guts ripped out for security and because of size constraints, and (ii) it would need all the state/event features of LSL implemented and new syntax added if it is to cope with the SL environment in an uncludged way.

All of this makes many of the proposals that have been made pretty unrealistic. The open bytecodes one is probably the most sensible since it preserves environmental constraints while letting you play with syntax, but another one that hasn't been mentioned yet is to write translators from your favourite syntax into high-level LSL.

Personally, I don't care what the syntax is, since the semantics of languages and the precompiled functionality are vastly more important. LSL does a pretty good job in that area. It is mainly let down only by some basic access-related omissions like no proper O(1) indexing, and its rather limited inter-script communications that create a restriction on building from components. In the world of state machines, it leaves most other linguistic solutions in the dust, even when they are marginally relevant (most are not).

There's much that can be done to improve SL scripting of course, but advocacy centered around standard languages is pretty much a fish out of water. A different syntax gains you very little, and most normal fish can't swim in this field of tea cups.

[This is a repost from my browser cache, after the forums database crash lost many hours' worth of people's posts. Sorry if it's not exact.]


The syntax doesn't really matter too much, except to the One True Language advocates. Plenty of those around though.

Having been involved in a lot of large projects (and using a lot of different languages), I'd definitely recommend that anyone operating a live service should take an evolutionary approach, not a big bang one. That would tend to favor the LSL3 rewrite rather than a total change, although you could certainly run multiple different VMs alongside each other if each VM had equivalent bindings into a unified back-end core.

If I had to do this from scratch, I'd probably use the Lua VM because it's tiny, entirely safe, reentrant, screams along (ie. reduced server loading), and is unencumbered. I'd put an LSL2 translator in front of it, both as a migration path from LSL scripting and also to provide the clean state machine and event syntax of LSL. If Lua syntax were exposed within state code and event handlers, it would survive the newbie syntactic hurdle quite well I think, being even simpler than LSL's "safe C" owing to its lack of type declarations and type coercions.

Having said that, there's nothing inherently wrong with LSL that a bit of O(1) indexing and a few more control and data structures wouldn't fix. SL would gain vastly more from extending the LSL function library than from any change in syntax of its scripting language. And LL would probably gain nothing but pain from a change of language syntax.

You guys are mistaken about the syntax. C scares off a lot of people because it's so ugly and hard to read. In fact, the decision to go w/ a c-style language is the single worst design decision I've seen in SL. You get none of the benefits of C, and all of the limitations of that nasty syntax.

They should have gone with vbscript or something (ANYTHING but this crap) like that, since no matter what the language bigots say (and it seems LL has some of them on staff), basic is THE MOST WIDELY USED PROGRAMMING LANGUAGE ANYWHERE, except among posters on message boards who argue about this endlessly (and pointlessly... sales say it all, and the numbers don't lie).

That said, I do kinda agree that a complete change at this point is probably going to break a lot of stuff, and I don't know that I'm cool with that. I definitely agree that dataserver events are a pain. I don't particularly mind lists, but I don't really understand why you would create something like that and not just give us arrays. We could also use a lot more list functions, if that's the way we are gonna hafta do it.

And really, just to get this off my chest... the people who write documentation for this stuff are really really out of touch. C uses operators that don't exist anywhere else in the known universe. NO ONE who is trying to learn programming for the first time is going to to know x++ means, nor are they going to understand how == is different from =. Things like this are really an obstacle to new programmers. And that's a shame when there are so many better options.

As for the OO stuff... scrap it. This is a scripting language. Just give us a lot of functions.

I think you're slightly out of touch with computing, Mike. C is the programming language known to more people on the planet than any other, ***BY FAR***. The planet is a far bigger place than the Microsoft playpen.

When LL created a scripting language that is, in effect, "minimal safe C", they tapped into the largest vein of syntactic familiarity that exists today. It crosses all boundaries of operating systems, generations, academia and industry, professional and amateur communities, microcontrollers through to supercomputers, and is syntactically similar to countless derived languages, both scripted and compiled. While it makes no difference to me as a multi-language computing professional, LL could not possibly have made a better choice when trying to appeal to the greatest number of people, because no other syntax family comes even close to being this ubiquitous.

Your statement "it's so ugly and hard to read" is pretty meaningless -- it merely indicates that you have no familiarity with C personally. For anyone that does have good familiarity with any of the languages of that group, the syntax is incredibly clear, largely because there is so little of it --- few languages are anywhere near that brief. Hell, even a whole raft of application preferences files are written in a C-type syntax, just because so many hundreds of millions of people are familiar with it.

In any event, as anyone who knows a thing or two about computing will tell you, the syntax is actually pretty unimportant. It's the semantics that matter, ie. what you can do with a language in a particular environment, and semantically LSL bears little relationship to real C. If some other language were adapted to the SL state machine and event environment, it too would become an entirely different beast to its parent.

Language wars are for neophytes. It really doesn't matter, but for what it's worth, a C-type syntax does at least provide instant familiarity to the greatest number of people.

deleted and rewritten.....

Secondlife runs under two operating systems. It runs in windows and it runs on osx. Now I could look up what the market share is, but let's just say roughly, that 10 times as many people use windows as use macs. Can we agree on that?

The microsoft playpen is the whole universe as far as this discussion is concerned.

Microsoft has stated time and again that VB is the most widely used language.... certainly of the ones they produce. Why would they say that c++ is less used than vb if it wasn't true? they do sell both of them, you know. So I don't find any reason to disagree with that statement.

Here's the deal.... the only people writing code in SL are codeheads. We can fight about languages all day, but only programmers are writing code here. That's the bottom line, and the biggest mistake. In a world where all the content is user created, you need a language that can be used by all the users. And it's pretty clear that that is not what we have here, since you started this thread in the first place.

Basic is my first choice for a programming language here cuz I am already familiar with it, but the biggest problem is not that the language isn't basic, it's that it's c, which is so much more difficult to learn than anything else. Go ahead, someone say assembler is harder... I'm waitin' for the assembler based scripting language still.

Most of the people in SL are gamers. And light gamers at that. How many of the people didn't play games at all, then played the sims, then went to There, and then came here? THAT is the user base that lives in SL. And those are the people the tools need to be geared towards.

Fine Mike, that's your opinion. It's clearly not the opinion of the LL developers, or they wouldn't have made the choices that they did.

I'm a systems developer too, and an advisor for large companies with online deployments that have technical and business tradeoffs quite similar to those of SL. If I were consulting for LL, I'd probably validate the choice that they made because the rationale is pretty obvious. It's not the only possible choice, but it was a good one.

In contrast, frankly, the suggestions you make are not even in the ballpark of feasibility. In addition to the worldwide ubiquity of C syntax that I mentioned in my previous post, LL's technology preferences are clear from the fact that SL runs on Linux servers and uses OpenGL graphics technology at the client end. Just that fact alone is enough to make what you propose non-viable --- I bet half the LL dev team would rather leave the company than work with VB. It's a cultural thing which you may not have encountered if you come from a VB stable, but it's strong, believe me.

That's kinda my point.... this is a design decision that from here looks like language bigotry. And the community suffers for it. Meanwhile, the c programmers all rejoice while the rest of us are left out in the cold. "the rest of us" basically means most of the subscriber base.

While I'm sure that the c language is the preferences of the gurus, they are of the few, not of the many.

And sorry if I ended up hijacking this thread.... I'm sure I could go toe to toe with you on the topic for days

No language is harder to learn than C? How about you take a look at Intercal, Befunge, Malebolge, or Unlambda? Maybe you could try to wrap you mind around Lisp, ML, or APL? Prolog?

I've had experience with a *very* wide range of languages. To me, Basic, C, Pascal, and LSL are all effectively the same language, and they're all about equally difficult to learn. Assembler is easy but boring -- you need to type so much to get anything done. ML is nice -- it's a new way of thinking about programs -- but I find that many people have trouble understanding the basic principles of it. APL has the unfortunate downside of requiring a keyboard that wouldn't look out of place in a spaceship, and Lisp demonstrates the disadvantages of a completely untyped language.

If I had to replace LSL with another language, I think I'd go with Standard ML.

100% correct, Carnildo.

Yes, that's exactly so. Original Basic I'd class together with Assembler (in fact. some macro assemblers are a lot more structured than original Basic), but the references to Basic by the poster referred to VB which has very little in common with the original, so your classification is perfect. These languages really all have a common underlying syntactic form, and the differences are barely discernible except to those who play language wars/advocacy.

On technical grounds that would be a very good choice. Furthermore, Ocaml is one of the fastest languages around in that niche (see my noddy benchmarks post for an extremely rough and narrow speed comparison), so it would certainly be a possible candidate if LL were thinking of changing their script VM.

However, on business grounds I wouldn't recommend any form of ML as my first choice, because syntactic ubiquity is so important. If LL decided that power and coolness ( were more important than ubiquity then of course it becomes a totally different ballpark, and many other languages would then enter the fray, with ML one of the leading contenders. I'd recommend Lua above any version of ML though for this application because of its incredibly tiny size/power ratio, minimalist syntax, and first-class semantics that nearly rival ML's on this scale. In a different application, I would almost certainly choose very differently.

As always in software engineering as in so many other walks of life, horses for courses and you can't do a good job whacking in screws with a hammer --- a point that is always lost on those who know only one computer language, alas.

i defently agree with you on that one

Morgaine, it's that very elitist attitude that has this thread existing in the first place. How many programming languages do you expect the average SL players knows?

I think you've missed Carnildo's point entirely. The fact that you know one language from the most popular syntactic group on the planet, which includes many structured Basics, C, Pascal, and LSL among countless others, means that you are extremely well positioned to cope with any of them.

You don't know just one language, you know a whole family of them. Don't underestimate what you can achieve if you just take off the "I'm a VB-only man" glasses. You're quite strongly empowered, and you're in extremely good company.

As one who has helped a lot of non-scripters with their scripts, its my opinion that its not the specific syntax of LSL that is the barrier, its the fundamental concepts of any programming environment that non-scripters have difficulty grasping and using. Concepts like "variable assignment", and "function calls", and "expression evaluation", and "flow control" mujst be understood, no matter what the specific syntax of the language.

Whether the scripting language more closely resembles VB or "C", non-programmers are going to have to understand all of the basic concepts I listed above. And learning those concepts in one language or the other doesn't make it any easier.

If a person knows VB and knows how to program in that environment, they should have NO difficulty adapting to LSL. Making LSL more VB-like isn't going to help your average non-programmer in the least.

- Ace

I might add one more item concerning the LSL environment...

As a career software geek (20+ years), I found that the hardest part of LSL to get my head around was the event-driven, state-machine-driven nature of LSL.

But its this very nature of the LSL environment which makes it such an efficient tool for making objects interactive with the world. No matter what the specific syntax of the language, these features are essential.

And when one does get their head around these concepts, its amazing how much can be done with so little actual code. I've had several projects, which at one point in their development were a convoluted mess of spaghetti code with countless conditionals, that I was able to radically simplify just by rewriting and taking advantage of the state machine inherent in LSL.

I'd never want LL to get rid of this model for its scripting language, because its such a great way to have objects do absolutely nothing, and consume no sim resources, while waiting for someone or something to interact with them.

- Ace

editted for clarity

Ace raises some really good points.

All I'm saying is, you guys need to look at what is happening. And look at it with your 'guru glasses' off. It is not an opinion, but a fact, that C is not the easiest language to START programming in. I don't really know that Basic is either, really. But it's certainly more friendly to look at than C. It's almost english.

As I said, we can fight about language choice all day. I feel passionate about my position, and you feel passionate about yours.

But what we need to have is as many people writing code as possible in SL. And that is not what we have. Scripting DOES need to be easier. One way to make it easier is to make the language syntax easier and/or more flexible.

It seems like you guys are totally forgetting the barrier to entry because you've already crossed it.

It may be worth referring to a couple of older posts from the start of this thread:

And another:

I doubt if anyone that's contributed to this discussion would argue with either of those two points.

The average player knows no programming language at all, and will not understand what's going on whatever syntax is used. They simply don't have the background, and you can't expect LSL to provide them with an education in computing. LL has provided them with the ability to customize their objects with textures and sounds and animations etc, and even to populate their designs with intelligent functionality created by programming experts who have additional technical skills.

That's a pretty cool approach to creativity in SL, it seems to me, collaborative and community-oriented.

It's no different to the situation with artistic content. I couldn't create an artistic texture to save my life so I have to buy or acquire them from others. Should I be complaining that the facilities for texturing objects require too much artistic skill and should be dumbed down for my benefit? I don't think so. If anything, I would suggest the opposite, that artists be given even more esoteric facilities so that they can astound me with their creations.

LSL is dumb enough already. Let's try to make SL an even more remarkable place, not a worse one.

Compared to many languages, LSL is perfectlly understandable. What do you suggest? Implementing a form of SL Basic? As it is, I think LSL provides the perfect balance between accessability and performance. If you nerf the language too much, the experts will have to spend even more time trying to surmount limitations in the language, and you'll have killed off the most important part of the user base. You need hard-core coders to create the things which the rest of us consume.

Besides, you can always create wrappers and such to convert simple code to more complex code. Going the other direction is not as simple. If people are truly interested in simplifying the language, they could create a set of simpler syntax and write a program to convert that to full fledged LSL. I don't think it would be that difficult, but I'm not a "hard-core coder" either.

The argument that LL should provide all the tools for a user is somewhat flawed, LL as a small business (they are by no means medium or even a large business yet.) cannot possibly write a;

- High Quality Texture development tool
- High Quality In-world animator
- High Quality Sound editor
...


Scripting is no different. What LL does provide is a blessing. Simplifing programming so any idiot (no offense to idiots intended) can use it will have three major side effects:

1) Overuse of performance inhibiting functions (anyone for 10,000 listens? ) due to abundance of inexperienced coders not understanding the concept of 'lag'.
2) Take up LL's valuable time developing what computer scientists have been attempting to create for a damn long time.
3) Limit the capabilities of the language to power users (or people with prior programming experience.). LSL needs features, not simplification, however I would like to see more consistent naming in the future (ala llGetListLength vs llStringLength)

-Adam

Adam is right on all fronts; LL is a small business. Bad coders use up all the resources. Nicely named functions are good.

I think if we want LL to open up the byte code we should at least first make a syntax checker for LSL as that will finish off the SciTE-ez LSL / ESL Editor.

Seriously what would make coding easier then using an external editor that can upload code? We wouldn't be having the conversation as to which langauge is better.


<edited because i reread it and realized it could be taken a way i didn't intend>

Learning Curve
===========

We can simplify the learning curve in LSL by creating wrapper functions for newbies with useful defaults.

Example: someone wants to get an object to say something. They find this command:

llSay( integer iChannel, string sMessage );

Straight away, they must learn what a channel is. They might quickly discover they can just plug in 0, or they might not. In any case it's extra learning to do at the beginning.

Imagine now that we have a function in LSL defined as follows:

Say( string Message )
{
    llSay( 0, Message );
}

We all know what Say means, we can guess what a Message is, so this is a much easier function to understand.

For advanced people, of course, the llSay() function still exists, exactly as before.

Now, its true that the newbie does need to know what a string is, if he tries "MyAge=20; Say( MyAge )" then this will fail and he/she wont know why.

But its a good start.

Bytecode vs standard scripting engine
===========================

The bytecode route is interesting. Bear in mind that we'd need to write our own compilers, and that bytecode would almost certainly be tightly-coupled to its target language, ie LSL.

The advantages of using a standard scripting engine are twofold:
- people from outside of SL can jump straight in and use the language
- as the scripting engine itself evolves, the improvements are integrated straight into SL, for free

<Relevant example>
A while ago (ten years), I was working on a big development project run by Andersens. We were using a fairly obscure language to write the GUI in called "OpenROAD". It did most things you wanted, like displaying database tables and so on, but its editor lacked search and replace (so I used to use Notepad and vim instead), and the commands to manipulate the displayed tables were very wierd.

Anyway, I bumped into a girl the other day who I noticed with an Accenture pen. Turned out she had worked on this project too, recently (small world). She was like "OpenROAD? Whats that? We're using Java now".

It might be worth a little bit of pain in order to switch to a standard language for which there is a plethora of developers, libraries and experience.
</Relevant example>

Azelda

Well first of all, there is no way that SL's scripting can provide remedial education in computing, whatever you do. If a non-programmer can't cope with llSay(<chan>,<string> then he or she won't get anywhere at all in scripting, even if you did provide a simplified wrapper.

Secondly, such wrappers would pollute the namespace if present by default, since the 'll' prefix is the only thing that gives us any namespace protection at all. To get over the problem, they'd need to provide something like a beginner radio button to tick on the LSL editor, so that only those that need the wrappers get the pollution.

This would be pretty pointless though. LSL is already extremely dumb, and making the syntax any simpler will not overcome the semantic hurdles of computing for non-programmers, since these stem from a lack of the necessary background. They already have the ability to customize scripted functionality in a variety of ways, and it's up to us as programmers to make those user interfaces to our scripts as beginner-friendly as we can.

Instead of focussing on language syntax, if we want to help non-programmers we should be requesting more advanced dialogue windows so that non-programmers can more easily set the values that control the bahaviour of our scripts.

I'd like to throw in a vote for Lua with legacy support for LSL.

<RANT>

I am one of those "artty" people. I've worked in the gaming industry, specifically in internet-based packet-delivery-dependent systems. I've also done more serious hyper-real 3D artwork...

It is unrealistic to paint the visual developers into a certain category of incapable of comprehending programming. And let me tell you why.

3D artwork - including texturing - requires a lot of technical expertise and mathematical comprehension to do any kind of well.

The Linden modeler is a very simplified version of the more complex modeling software I use professionally, much like - I'm guessing - LSL is a simplified version of C. But there are plenty of docs explaining 3D space and how the modeler works, and the Ivory Tower is listed among the SL Picks, so it isn't prohibitively difficult to find good tutorials and get started.

Poser, for those of you who haven't tried it, is merely one tool with a specific application. People who use it for rendering final art and modeling are amateurs. But the documentation that comes with the program is very readable, although I had to really search for a tutorial on animation importing to SL (the one in the SL docs is gay)... and I had to figure out the hard way that Priority 1 didn't mean what I thought it did. This stands to be improved.

Photoshop is also one of those deceptive tools to the uninitiated. It is NOT a hyper-dyper version of Paint. Masking, color values, gamut, channels, raster vs. vector graphics, data management and compression... these are all extremely import concepts in digital imaging. UV maps and channel management are hardly "artty" concepts. But the tutorials available on the SL website are very good and there are a few other good tutorials that are linked from this site and/or easily googled.

The difference between the imaging aspects of SL and the programming is that there are enough good tutorials available that really, anyone can learn to texture and model at least passably well. Those of us with more experience will obviously make better textures and objects, so there is a market for our talent, but everyone can try it.

The documentation for LSL, however, is laughably bad. I can't believe they even called them "help" documents.

I think the more pointed truth here is that scripting is the most powerful function of user-development in SL, and therefore it is the most lucrative and coveted secret. If you look in the graphics forum, help is much more forthcoming to newbie questions, but here... it's almost mercenary.

I have found this very frustrating, because I have a number of ideas that I'd like to implement that are strongly based on my understanding of 3D object space and textures, but I am still struggling to find decent documentation for LSL so that I can learn the equivalent basics.

I don't expect to be able to write monster badass scripts. That's something for the script-specific people to do. But, I would like to be able to do a bit more than just open doors. Some basic scripting knowledge is ESSENTIAL to those of us who bother to create really great objects and animations. But if I can't easily figure out how to make a pose-ball, or how to animate my avatar from a worn object, without having to hunt for weeks until I find someone's script so I can break it open and scry into it like chicken bones....then there's something wrong here.

I am FORCED to go and look for someone else to do that for me, who will happily charge me an arm-and-leg for a no-copy/no-modify script that I can only use once... and I know that if I could just look at their code, I could figure it out through trial and error, intuition, and reference to the ...*cough*... "help" documents.

Instead, I waste oodles of time wandering through the wasteland of this forum, Wiki (which really isn't that much more helpful) and my heart goes all aflutter when someone slips and starts explaining things in conceptual terms, because it is so unusual.

There are many of us who are not too stupid to understand code. It's just that we've spent our time doing something else up until now, and haven't had to learn it. Well, now we do, but the programmers (including the Lindens!) are sitting on that information as if they are afraid of what might happen if suddenly more people could easily create more common scripts.

Yes, it means that programmers will have to come up with something more creative and innovative than pose-balls, because now all of us "artty" people will be able to do it, too. And that's a good thing, which many in here seem to be doing anyway.

It also means that you'll start to see more interesting holistic concepts develop because those of us who do have 3D and visual-development experience will be able to TALK TO serious scripters so we can work with them to develop something really nifty.

So, the bottom line is that there's really no excuse for the code secrets to be hoarded so miserly, except, of course, capitalism. But information wants to be free, and more profit will ultimately come if more of us understand our tools. I paid for SL... shouldn't I be afforded at least a basic understanding of what I paid for?

Thus I feel that we need real, actual tutorials that do not assume that we have the faintest idea what an array is (anymore than most programmers know what out-of-gamut means). Just walk us through the basic concepts of how programming works with SL, concrete examples of what is doing what in the script and we'll figure it out from there.

Do not assume that if a person doesn't make their living as a programmer, then they have some kind of anti-programming brain damage that precludes them from understanding the fundamental concepts. If you cannot explain it to the average SL player, then I'm inclined to agree with Richard Feynman... you don't really understand it yourself.

Besides that, I think Linden is doing the community a disservice by perpetuating this programming cabal. It's inhibiting my growth artificially.

</RANT>