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).

OK ... LSL is pretty flexible.  You can do some interesting things in-world with it.  If you look around Second Life, this is pretty obvious ... there are a lot of things that are scripted in there.  And it really does add to and enhance the experience.  Things like particle systems, bling, payment and vendor systems ... basically anything that does more than just sit there ... is based on LSL scripts.  It's very similar, structurally to C and C-derived languages such as C++, C#, Java and JavaScript, so if you already know these languages, you have a leg up. 

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);
}