I've made my first foray into LSL ... the Linden Scripting Language. This is the scripting language used by Second Life to do ... well ... all kinds of things with stuff in SL. After spending some time playing with it and even more time fighting it, here's my own personal point of view. Keep in mind, too, that this is coming from someone that's been working with the most advanced code editors in the world for many years ... these being the different version of Visual Studio (no, not Eclipse ... they copied).
That said ... well ... let's see ... where to start. I'll start with the most basic thing that a developer needs for any environment. No, it's not an editor, it's documentation!!! The official documentation for LSL is on the Second Life wiki's LSL Portal (http://wiki.secondlife.com/wiki/LSL_Portal). Finding this, at first, was something of a challenge. You have to know that it's part of the wiki ... there is no self-evident link (that I could find which, of course, means that it's not self-evident in my little world) on the Second Life home page or in-world. Now ... I do think that wikis are an awesome way to disseminate information and get feedback (MSDN has done a great job with this), but I do think that there should be complete documentation provided by the vendor, with wiki functionality as an enhancement. If you look at the wiki, there is even a list of functions that need examples. Can you imagine if Microsoft did this with .NET? People complain about out documentation all the time (and I agree ... it could be much better), but it is worlds better than the LSL docs and, in fact, a lot of the other documentation that I've seen out there. There is an alternative documentation effort as well (and why is that?) at http://www.lslwiki.net/lslwiki/wakka.php?wakka=HomePage which, it seems to me, is a bit more useful.
Now ... the in-world editor. Oh boy. Reminds me of the VB4 editor ... color coding but that's it. It is very lacking in some of the basic features that modern developers have come to expect in a code editor (regardless of their choice of editor). There is no Intellisense, no argument help, which results in constant flipping back and forth between the editor and the documentation. There is a combo box in the editor that lists all of the built-in functions and constants and will insert these, so that's helpful. However, I was expecting that a function gets inserted with argument placeholders ... this would seem to be easy to do (certainly easier than Intellisense) and make it a little more intuitive. The development involved to do that would be no different from what they are already doing with this combo box, so I'm somewhat baffled as to why it's not there. Yes, there are separate editors, but most lack a runtime environment and even those that do, the runtime debugging environment is merely an approximation of the real SL runtime. And then there's the quandery of taking the externally edited scripts and bringing them in-world.
Closely related to the editor (at least in my mind) is the debugger (after all, it's the editor that you use for debugging, right?). Ummmm ... what debugger? Seriously ... what debugger? There is no in-world debugger. Yes, there is a test harness posted on the LSL wiki, but it's not really an interactive debugger. Debugging your scripts involves the stuff that we used to do in ASP "Classic" (even with InterDev 6, debugging ASP Classic was something of a challenge at times). So ... yes, just like Response.WriteLine(). Except ... you have to use a dialog channel for it. Fortunately, there is a debugging dialog channel that goes into the Script Error/Warning Window. But peppering these calls throughout your code? Ugggh. Of course, just like in ASP Classic, I wrapped this in a function ... sendDebugMessage(string message)
llSay(DEBUG_CHANNEL, llGetObjectDesc() + ": " + message);
everywhere) with on line commented out. You'll also notice in there the "ll" before every function call. All of the LSL functions are prefixed with "ll". Most of the functions have names that are very obvious about what they do, which does make the code somewhat easier to read. But they are quite limited in scope (about 300 functions in all, I believe) and there are some functions that I would expect in there that aren't. There is, in fact, a section on the LSL Wiki that lists a function wish list (see http://wiki.secondlife.com/wiki/LSL_Useful_Function_WishList).Now, one of the very interesting things about LSL that I saw was that each script is actually state-driven. I can't say it's quite a full state-machine, but it is state-oriented. (Think VB 6 ... not object-oriented, but it was object-centric) Each script must have a default state, but also can have a number of other states, depending on what you want to do. Each state will have its own event handlers for LSL events and there is an LSL function that allows you to change states. This may initially be somewhat alien to traditional MS developers, but it's pretty easy to pick up. And if you are familiar with Windows Workflow Foundation, it'll be very obvious (even if you feel it's limited compared to WF). So ... state driven with events. Object oriented? Not even close. VB6 was closer to being object-oriented. Arrays (or Lists in the LSL type system) aren't even directly accessible but must be handled using a whole set of LSL functions specifically for manipulating them. You can run multiple scripts in an object ... in fact, all scripts contained in an object will run simultaneously and can be in different states at any one point in time. This does make for some interesting possibilities as well ... though it can pose some challenges if, for some reason, you need to synchronize states between the different scripts. Which brings be to reusability and componentization. These are core concepts of programming languages that date back to ... what? the Stone Age? Yet, in LSL, this is quite challenging ... there is no direct way to reuse scripts in multiple objects. Instead, you have to create a link channel that allows communication between them. Linked messages allow scripts in multiple prims in the same object to communicate ... or separate scripts in the same prim to communicate. This is, in fact, mentioned quite directly in the official LSL wiki:Using llMessageLinked in a single prim object allows developers to mitigate some LSL limits by breaking up functionality between cooperating scripts and synchronizing actions. When you do this, be extremely careful not to create infinite loops as mentioned above. It does strike me as a somewhat inelegant way to accomplish this. I can see the need for it, I suppose, between multiple scripts in separate prims, but between scripts in the same prim? I don't know ... slap me twice and call me silly (you wouldn't be the first, I can guarantee that!).
Wow ... looking over this, it looks like a major complaining and whining session. OK ... well, it kinda is. None of this means that I don't like Second Life and none of it means that I don't think that Second Life has huge potential as a new community and communication paradigm. And the Lindens have done an outstanding job creating the world and a rich, immersive client. There is, honestly, quite a lot of amazing stuff that they've put into SL. It just occurs to me that the scripting environment may not be their strongest talent. I have heard a rumor or two that they are looking to implement Mono in SL as a scripting language, which would take a great deal of the work off their plates. I think it's a fantastic idea. Some of you .NET purists may be frothing at the mouth ... "Why aren't they using the full .NET? Why Mono?". Well ... if you are one of them ... chill. The reality is that the Lindens have to provide a client for Windows, Apple and Linux. It's just a fact of their business. The full, Microsoft-provided, .NET Framework doesn't run on 2 of the 3. Mono runs on all three. Should this happen (and I hope it does!), we'll get real OO and C#!
And now I'm off to dabble in LSL now. Going to play with the XML-RPC (oh, how quaint!) and HTTP functions to start getting in-world scripts hooked up with .NET web applications running in the cloud. That could be many levels of coolness!!