Throw LSL away!

Seriously, while it does its job more or less, it looks like a really awful hackjob to me. Especially the inconsistency in function naming, and the weird string manipulation, are really confusing. And what is the deal with these lists? Couldn't be clunkier! So, it'd be great as a longterm goal to rip it out, create a consistent object model and implement a real language. Python would be a good candidate! EVE Online makes extensive use of python, so there you have a case for suitability of the language.

I can still dream, can't I? Thanks.

Ahahahahahahahahaha...

*gasp*

AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA...

*gasp*

AHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

*falls over dead*

Anywho... Yeah, the naming conventions SUCK, and the text/list handling could be better, but... I like LSL.

Python? Why not suggest a sensible language, such as Befunge or Intercal?

I think this one deserves my big, fat, obnoxous
NO!
stamp(tm)

Though I do agree that it does need a cleanup, I dont think it should be outright removed. I first suggest the implementation of function overloading, that way they can at least patch some of their bad design decisions, (like not including a key in the changed() event)
==Chris

I figured you'd say no, because then you'd have to rewrite the whole Wiki. LAFFO!

If it were going like I want it, they'd host the .NET CLR (or the Rotor release in case of Linux) and let me write C#, which then gets compiled serverside and hosted in an appdomain, but that's about far-fetched as it can get.

We all know that LSL ain't gonna go ever. Why would LL make a decision which would break every scripted object in the universe.

OTOH... It would be nice to have a more powerful language. However in my mind, the solution isn't to have LL create a new one, but rather to rip the lid off of the byte code generated, and let us create new languages or port existing languages to generate SL-bytecode.

- Ace

If they were to introduce a new language, they had to keep the old scripting engine running side-by-side with the new one.

If you poke around the scripting forum, LL has seriously considered moving to python in the future. Of course LSL would still be supported.

This is the stupidest, most ill-informed feature suggestion yet. Sorry, but don't throw LSL away. That's just plain stupid.

Just add more language compilers.. (Or open up the native bytecode to us...)

Once SL goes fully distributed, I imagine they'll allow 2-Way XML-RPC, and you could use whatever language tickles your fancy.

But as long as we have a centralized asset server, I doubt that'll happen.

No offense, but I know how to code, and I know when I see a badly designed language / API. The only real advantage of LSL to me seems that it supports vectors as language construct.


Cool, thanks for the pointer!

No offense, but I've been a software engineer for over 20 years, and I know when I see a proposal that is just plain silly.

LSL is a fine language for its purpose. Sometimes, simplicity has its advantages, and SL scripting is one of those times.

Sure... there are a lot of things that might be nice to have in the language. Pointers and/or references, structures, function overloading, and a whole host of things might be nice in the language, but they're not necessary to accomplish the task at hand.

To propose that LSL be eliminated is nuts. There are too many existing scripts that would have to go away if they were to eliminate LSL and replace it with a more powerful language.

Name another language that has a built-in state machine. Name another language that allows you to setup the equivalent of interrupt service routines simply by declaring a function. Name another language that is as powerful and runs within the confines of 16kb (well... I can name one... Forth... but I wouldn't want to script SL objects in Forth).

- Ace

I can't think of one, but states can be easily implemented in any language without an built-in state machine. While tomfooling around with LSL on a trial and error basis before looking up the Wiki on the state machine stuff, I was implementing states on my own, and it worked just as well.

Hardly something noteworthy. Any highlevel language with eventing can do the same. The few lines needed to do the event subscription is negligable.

This argument doesn't count, since everything's serverside and likely just interpreted bytecode.



One way or another, LSL isn't well-designed. Trying to fix that, you can aswell introduce a new language while freezing LSL and leaving it running side-by-side until everything LSL is phased out.

You do realize that a large number of people on SL are not programmers by profession or hobby, and LSL is their first programming language...

*raises hand*

LSL isn't my first language, when i started with LSL it took me ages to get over the insane limitations and missing functions (when i joined there wasn't llLog).

I have used over 25 languages in real world applications.

Each one was chosen because it was the right tool for the job at the time.

My vote is: open up the byte code so we can create our own languages. Especially the ability to seamlessly create multiple script files so that we can overcome the 64K segment issues at the compiler level.

Yes it will be sad that people won't appreciate heaps and stacks as much.

The language is not really the problem. The main problem is getting access to the data we really want (read and sometimes write) access to.

Don't throw away LSL!
But another language would be nice ; I agree that LSL looks like a big hack.

Long time ago, I had a small server on a DSL line that I maintained, lock stock and barrel. I used it to host mucks, mushes, and moos, the text-based ancestors to SL and such, free to any friend that wanted to. If, in one mush, someone complained about how they could do better, or how it could be improved, I gladly set them up an account, set up the server program, and gave them the keys. Oh, how I long to grab a copy of the sim server code, to run my own little sandbox without fear of damaging LL, to text my code while the servers are down for maintenance. How about it, Andrew?

I can hear the laughing, and the lab's 40 miles away, according to yahoo maps.

Anyways, It is in that spirit, of giving one enough rope to hang themselves, that I delcare this: LSL sucks? There's better languages to use? Fine! Make one!

You heard me. Azelda showed that it is possible with his awe-inspiring ESL. To make a language that is cross-compiled into LSL, and then a simple copy-paste. I've never used Python, but it's powerful enough to cross-compile python code into LSL, given enough ingenuity. And that's just one way. LSL has string-handling capabilities, implement in LSL an interpreter! I'll even give you hints!

1. Make the code-loading front end seperate than the guts of the beast. That way, code can be stored as a note for ease of modification, or passed by spoken statements, or stored in a locked script that stores the new code in a massive string, passing the text via linkedMessage on creation.

2. Have the interpreter object contain, in its inventory, a simple prim, using llRezObject with it over and over again. This single prim contains a script, set to listen in on some odd channel, so that the language can shout out ways the prim should reshape itself with llSetPrimativeParams.

3. Make use of llRemoveInventory for this prim script, so that the end object, when done, can be made inert enough to reduce lag and stop malicious changes. Use other ways to lock down the script so that it only listens to who it's supposed to.

4. If you can work around the delay that events put into the flow of an interpreter, the world is your oyster. Put the symbol table into its own 16K script, or if that's not enough, use multiple scripts, with a hash to distribute the memory.

5. No, this won't be in bytecode, and yes, it will run slowly. But by reducing the work that LL needs to do to support it, mayhaps they can add it to the script abilities.

Yes, I myself am planning on making a language interpreter in LSL, but it's going to take a while, and it's rather a challenge. But I'd love the competition!

Side note:
Now THERE's a thought! In the old 68K mac C and pascal interpreters, there was a function (Or was it a macro?) called INLINE, such that you could embed 68K machine opcodes into the program. Maybe such a function could be put into LSL, to run bytecodes that were previously compiled?

I can smell the smoke already



I could design a better, *simpler* language with half my brain tied behind my back. There are some *huge* holes in LSL that _prevent_ code reuse.



but not having *any* basic *userland* library capabilities? Come on!



Err...you don't *seriously mean this at a deep technical level right? Turing Equivalence and all that. That said, this is the *one* good idea in LSL.



LSL is not just a language but also an application framework. And it is a *very* restrictive application framework. That's OK though because it's meant to run very restricted applications. If we allow application frameworks into the picture, just about every language qualifies. I've been writing an LSL emulator in Lisp just because debugging in-world is *such* a pain.



Nonsense. LSL does not run within the confines of 16K.

- C

Yes, and it is all the more reason for putting in something better. Mind you, I'm not entirely sure that *Python* is the right answer to that issue...

- C

>_> <_<


Yup.

Perhaps LL could add support for another language or two or twelve. If they opened up their runtime model or virtual machine or whatever they are using, it might be possible to port other languages.

I kind of like LSL myself. Yes, I am frustrated by the limitations such as lack of arrays, but I do like the event handling and state machine features.

Speaking of those features, HyperTalk, the scripting language for Apple's HyperCard (http://en.wikipedia.org/wiki/HyperCard) had a great event system and you could do states easily by spreading your code across multiple cards or backgrounds. I wrote dozens of stacks in HyperCard, and found it to be one of the best systems for building small, interactive applications I've ever used. It sure beats the pants off of LSL, and did it way back in 1987. My point? There are no lack of good scripting languages that have already been developed and polished. There is no need to create a new one.

I take it as a maxim that any product that relies on the invention of a new programming language is doomed to failure. There have been a few exceptions to this rule, but almost always what you get is either a good language and a bad product, or a good product with a bad language - in either case, the product fails. The jury is still out on SL, but I think it's shaping up to be a good product with a bad language. If SL is ever to make the leap to world domination, it will need to move beyond LSL. There are too many applications that would need to be ported, too many developers who don't want to spend the time learning yet another toy^H^H^H special-purpose language, and too many complex applications that won't scale.

I still think that waiting for LL to implement this is going to be a long wait, one I can't fault them for. Linden Labs has a lot on their plates as it is. I say it's up to us, the users, to demonstrate a legitimate need and avenue for multiple languages.

Make the interpreter, show the value in more than just LSL. Make a bytecode instruction set (Ideally, one that is the same as what is used by LSL, although this is not necessary. Perhaps Java code, just for portability?), then a bytecode interpreter in LSL. Voila, you have a means by which gcc, javac, xCode, etc. can compile to binary; After all, it's just another chipset/platform from the compiler's POV.

Once this support is in place, then LL can make an INLINE function, to remove the slowdowns of an interpreter, and you're up and running with Python, Lisp, Squeak, C, BASIC, Forth, whatever's your fancy. You don't like the language selection? Fine, make your own implementation.



I have much love for Hypercard, which had some great features that shame even high-end commercial scripting languages. (Cough, cough, Visual Basic, cough, cough) I still have the Hypercard 2.0 reference on my bookshelf. I remember seeing it on TV in 89 or 90, where they had a new feature of being able to click text in text fields, and using that instead of buttons to go between cards or execute code. I remember thinking, "Clicking text to navigate from card to card? That'll never catch on. Especially with that silly name, 'Hypertext links.'" Sad, but funny, and true.



Yes and no at the same time. The very nature of SL means even the most flexible languages will need a change, a custom API at the very least, to handle prims and other unique qualities of the virtual world. But there is a wealth of structuring, syntax, and other grammars to pick and choose from.

If you want a simple example, I've chosen to try to make a LOGO interpreter. Penup, pendown, and pencolor no longer apply. The turtle will now need, at the very least, up and down to help navigate, and prim creation is a whole new ball of wax. However, function declarations, eval/apply, and recursive lists still apply.



Toy language is the key word here, yes, but now I'm curious. What sort of applications would be ported to SL? More so, what applications would be ported without a radical change?