Are these SW Development Tools possible with LSL

I'm interested to know if a modern software development environment is possible from within SL.

Most software projects have automated build and test scripts and some sort of code repository with version control.

With LSL being an event driven and truly 'object oriented' language I'm wondering if any of the above are even possible?

For example can I write an LSL script that can automatically build my multi-prim, scripted object? Hmm, I know there are object rezzers so I'm guessing something like this *may* be possible.

But an automated test environment for running a daily 'smoke test' on the build ... eeek!!! I'm not even sure what that would look like ...and it would seem impossible for another object to be able to trigger the correct event (ie. by 'wearing' an object) because only agents can wear objects

And LSL script repositories with version control and script checkout/checkin ??

Of course, we can all work without this environment but without them I think there is an upper bound to the complexity of projects that can be develope/maintained. The environment outlined is also pretty much a 'must have' for the major benefits of collaborative team development to be realised.

There's a certain extent to which you can build automatic tests in-world, but really only so far as mimicking chat/link/dialog messages -- you can't manually generate events using LSL. However, for some of those features, LSLEditor can help. It's an offline tool that can run LSL scripts and help you debug them -- it's great, but is by no means a professional-grade development environment.

Repositories is an interesting question. Using standard SL features, the best you can do is have scripts transferred to other objects (using remote pins I think), and then rely on those scripts being entirely self contained. I guess you could make a master script which will delete old scripts before new ones arrive too, but there will always be difficulties and limitations.

However, since script entry is entirely client-side, I am sure the necessary functionality could be made possible using bots and/or client modding. I would personally favour the latter, so that an in-program option could be made available to check-out the latest version of a script, and either add it to my inventory, or update an existing script in there. Not sure if anybody's done that sort of thing yet... but if they, I would love to use it!


EDIT: by the way, I totally agree that there are limits to how easily a team can collaborate on LSL scripting without some of these features. The best alternative I have found was keeping all the latest scripts in an SVN repository, and manually transferring them to/from SL... not ideal, but workable if everybody does regular commits.

I'd say it's much closer to a purely procedural language than it is a truly object-oriented one. There are structures available like rotations and vectors, but no first-class objects.


You can, but it's really far more trouble than it's worth, and I have trouble imagining a situation where I'd want to do so that wasn't strictly for curiosity.


Not directly supported, though if you work offline (I work on scripts almost exclusively offline, for instance) you can of course have Subversion or Git or whatever you want for version control.


There is indeed an upper bound to the complexity of projects, and any kind of collaborative development is largely enabled outside of anything that Second Life provides directly.

It's really more of a testament to the ingenuity and persistence of Second Life content creators that some very cool projects have been done using LSL, and not so much to the suitability of LSL

It's interesting to debate the object-orientedness of LSL. If each prim contained a single script, then you could arguably call it object-oriented insomuch as all functionality for the script is encapsulated in a "black box" approach, interfacing with external code solely by means of whatever messaging mechanism you want to use... be it chat/link messages or whatever. Each copy of a prim would be a specific object instance, although obviously each instance has its own independent (and changeable) definition.

I know it's a somewhat hazy correlation to the conventional meaning of "object-oriented", and having multiple scripts per prim kind of blurs the line a little more, but it's interesting to imagine the virtual world as part of a programming paradigm, rather than a representation of a physical environment. It can be a useful exercise actually: change the metaphor, change the mindset... and hopefully come up with new ideas.

At one stage, I was developing a tool to present a survey question with various selectable types of dynamic graphical results, all integrated with an external database/website. I nearly ended up using a model-view-controller design pattern by accident... it's just the way the different parts of the prototype build ended up.

Short answer: no.