Let's talk about Mono/.Net

Maybe I'm wrong, but my impression was:

1. LSL will ONLY be compiled/interpreted by the LSL scripting engine in Second Life.

2. Mono/.Net will support CV or C# scripting (as they're both available now via open source builds).

3. As a part of the upgrade to Mono, LL will supply assemblies that allow us to interface to the SL engine, in much the same way we use LSL function calls now. The difference would be that we're using true objects, complete with methods, fields and properties.

I can't see any incentive for LL to develop a LSL compiler for the .Net Framework if it's not necessary. Simply setting up some default imports and creating an assembly with all the current ll* functions would do the job.

The only construct that exists in LSL that's not in C# is the "state" system. The beautiful thing about the state system is that it automatically disconnects events when you shift states... useful for certain things but often not used at all. It wouldn't be too terribly difficult to implement a state system in .Net, but it would be cumbersome.

.Net already has a beautiful event handling system that allows you to trigger custom events in your own code. Likewise, it has a great exception and error handling system that is SOO much better than what we had with Visual BASIC 6 or native C++.

How would we implement the state system then? Simple: exceptions. An exception automatically kicks you out of any loop, procedures, or function. If any ll* routine that sets up a handler registers that handler on a table, it would be a simple matter to detach those events before shifting states.

Considering all this, I would urge LindenLab to not try to port LSL to .Net.Instead, leave the LSL interpreter as it is, and use "native" .Net languages: C# and Visual Basic. Give us all the ll* functions in a class library and see what we can do!

Assuming LL doesn't cripple the Mono implemenation too much (which is easy enough to do; simply don't include certain wrapper classes), we would automatically get no just true classes, but lots of other things: true Inter-process communication, direct TCP-IP, better error handling, custom events, and possibly some direct data storage and manipulation features. Perhaps we could even get a home directory with some place to store our own files. Woudln't that be neat?

But performance isn't one of the things I'm really expecting to see. There should be some increase, since the code is getting compiled and run on the CLR, but I'm betting it won't be the "night and day" difference that some are expecting. Compared to x86 native code, the CLR can be pretty slow.

I can't be the only person who uses .Net on a daily basis. What do the rest of you think?

Hi Aurael, we have developed a LSL to CIL compiler and it produces code that runs processor intensive algorithms 50-100x faster than the current LSL interpreter. Although we plan to run the existing interpreter and Mono virtual machine side by side initially, the long term goal is to phase out the interpreter and run all scripts on the Mono virtual machine. In addition to the performance increases it would allow us to open some of the .NET framework classes up to LSL as you mentioned as well as allowing other languages that target the CLR like C# and VB to be used to script SL. For more information, keep an eye on my blog http://secondlife.blogs.com/babbage

Cheers,

Babbage.

thanks! You are my new hero!



makes me want to get my comp sci degee as soon as I can so I can come work fo you guys

Mmmmmm

deee-licious.

Gosh this is encouraging for us wiki types. Thanks for the swell reply Babbage.

Babbage's Most Excellent Blog

True object orientation my inner kitten purrs...
=^_^= Meow!

Thank you sooo much I'm really looking forward to this.

Why can't we program in a more friendly, easier to use, easier to learn language, like BASIC?

I just can't get my head round scripting... and it's annoying, because there's so much I could do if only it was easier for the average user to pick up.

That, of course, is assuming that everything else worked as it was meant to *cough*joints and linking*cough*

Lewis

LSL is a friendlier, easier to use, and easier to learn language than any Basic that could serve the same purpose. LSL's running in an environment that makes an Apple-][ look like a powerhouse. Yes, LL is running SL on dual opterons, but those dual opterons are supporting 40 users, thousands of objects, and tens of thousands of scripts.

The thing that makes LSL hard isn't the language, it's the fact that you're working in an event-driven real-time environment with concurrency. The individual script isn't concurrent, events are executed sequentially (and this is a GOOD thing, it'd be ten times as hard if you had to manage mutexes and the like within a single script), but the rest of the virtual world is doing things to the object while the script is operating and you have to deal with that.

Given that environment, LL did a very good job of hiding the complexity and making LSL easy. I can't see how they could have done better with Basic. They could VERY easily have done much worse.

I can understand Basic, and write a program from scratch to do what I want to do.

I don't understand LSL, and I'm limited to modifying existing freebie scripts.

Not all of us have degrees in computer programming - or the time for one.

Lewis

And thus another promising thread decends into regular forum stupidity because a RFG (Regular Forum Goon) can't let something this promising of a discussion continue on it's productive course.

Wow. I've always hated programming, I knew a little Basic and HTML, but outside that have no serious programming experience. Yet I still can program LSL pretty easily - I can't do ALL the things I want to, but I don't find it overwealming...

How would you propose that LSL be made easier, more understandable and like Basic? I'm not joking or arguing a point, I just am curious because from my point of view it already is very comparable to Basic. Sure, I guess technically the format/syntax is like C... Are you saying the syntax/structure is difficult, or particular commands?

I'll let the mods decide whether that was a personal attack... in the meantime, as it is relevant to the discussion in the form of programming in SL, your apology is accepted in advance.

As you seem to know so much about me (even if it is inaccurate) after only three posts, whose alt are you?

Lewis

It wasn't promising. O.o

It was shutting the less knowledgable students out. Transpose LSL if you change systems..so us more script/programming illiterate folks can manage.

I find the syntax structure confusing, I also find the editor a little clumsy (like in the way it doesn't pick up errors until you compile, instead of as you write), and the actual structure of some of the commands (such as defining variables) temperamental. I won't go into the way that some things behave unpredictable (such as joints/linking) as that's another issue altogether.

What would I do to improve it?

Firstly, I'd add an interactive syntax list to the bottom of the panel, so that, for example, when you enter llMoveToTarget in the editing window, up comes llMoveToTarget(vector target, float tau) so that you know exactly what you are supposed to be entering (of course, being able to click on that to bring up the wiki or a help page would be a bonus),

Secondly, when you have a syntax error in a command, it highlights it as you go along much clearer - linked with the above, it may make troubleshooting easier too.

That's at least a strat, I'm sure there would be more.

Lewis

Lewis, the syntax is C based and very, very common throughout the programming world. It's really not that much different from basic, it just uses symbols instead of words in a few places.

The editor *is* a little clumsy, but creating a good text editor is a lot of work. What I hope they'll do is make it easier to work with external editors eventually. The way errors aren't picked up on the fly is a totally fixable problem and not anything to do with BASIC vs LSL, it's a property of the editor/runtime and not the language.

There is already a limited form of online help for the editor .... hover the mouse over an lsl call and you should get a tooltip with prototype data in it.

Erp! That would be a big abuse of what exceptions are .... a way to deal with exceptional conditions. Exceptions really aren't optimised for speed at all because they're meant to be used very rarely, so making it a fundamental part of scripting would be a bad idea.



Well, the limit on these things isn't really LSL, it's more a question of server resources. Scripts running in a runtime don't have much concept of "processes" in the traditional sense so traditional IPC doesn't make much sense either ... object to object communication is already possible in a limited way, but I guess the RPC stuff may prove handy. Unlimited direct network connections probably won't happen as they don't want the grid being used to launch DoS attacks. It would also require care to ensure nobody can hack the internals of the grid. Data storage is again a question of server resources .... probably better XML-RPC abilities will replace this, allowing people to provide their own external storage.



Depends what sort of work you're doing. I can't speak as to Mono but GCC isn't a terribly good compiler optimization-wise, so I can see Mono beating it quite easily.

But you're right, I wouldn't expect to see huge differences, if only because most scripts are likely to spend most of their time calling ll* functions and not doing lots of math. In aggregate it'll probably free up a significant number of CPU cycles.

Mack beat me to it, actually I seldom type the command and hover over it anymore, more frequently now I just keep the wiki open, go to the command, and then copy the syntax from there and paste it from there, and then rename my variables. Having it automatically put the entire line there automatically or bring up the wiki would be a good thing, and is a good suggestion.

Most of the problems I've had with LSL are as Argent mentioned above with timing, or with things where either the language itself is too simple (I.E. No object to object communication), or where SL itself is limited (Joint/linking as you mentioned, inability to have an attachment make an AV turn, run a pose to make my character duck and objects still "collide" with the area above their head, almost anything with physics, ect).

I propose everything be done in machine code.

I quite like the idea of using VB in Second Life. That's if I can still use it after being brainwashed with LSL for the past year.

I'm not a big fan of C#. So I sympathize with Lewis on this one.

I grudge being forced to place a semicolon at the end of every line. Infact, there is a small counter I have in my soul. Each time I am forced to add a semicolon to the end of a line of LSL, that counter increases by 0.00000012. If the counter ever reaches 10, then I shall snap off the semicolon key from my keyboard and go hunt down the guy who invented C# and force him to eat it.

I also resent having to use two equates in:- if (x==2). I want to be forced to use 13 equates, like'if x=============2' I love the equate symbol!!!. It makes me look so freaking clever!!!


Morning everybody!;

I am really excited about this change, as I am a .net developer (Snapzilla was developed in ASP.NET) who uses C# extensively (I don't like Visual Basic.NET - too wordy). It will be interesting to see how this all unfolds, since LSL uses an unusual concept of states that I have never seen in any other programming language. Having access to functions in the .net library will be a tremendous step forward (obviously some will have to be blocked for security reasons). I don't know a lot about Mono since I use the actual .net Framework and Visual Studio 2005, but hopefully they have been able to carry over most of the functionality.

As far as the == equate thing, I hate that too - I ran into it just the other day in LSL when trying to set up a vendor that only sold to one particular key - I kept setting the key in the if statement. Hopefully Mono uses the same system of warnings that .net does - it actually does warn you when you are compiling that you may be making an unintended assignment instead of a comparison.

That is one of the great things about the .net framework (and Mono's copy of it) - there are a wide variety of languages that can be used. Out of the box you can use Visual Basic, C#, C++ and J++ (Microsoft's implementation of Java). There are several other .net compilers available - Cobol, Python, Perl, and many more:

http://www.dotnetpowered.com/languages.aspx

I noticed from looking at that list there is a language called Boo - I have to check it out just because I like the name.

It will be interesting to see what support LL adds beyond LSL.net - that is an obvious first step. I hope they implement it in a way that many different languages can be used, depending on the preference of the developer.

Ahhhhhh!! The language wars must stop!

Currently, LSL is a layer over a propriatery bytecode, sent to a proprietary interpreter. What LL is trying to do is change the bytecode and interpreter, not the LSL layer on top of it. Once they switch over to Mono, it just means LSL will run faster then before, not that we'll have to learn C#.

Also, since the bytecode will no longer be propriatary (linden-made closed source), programmers will eventually be able to work in languages other then LSL that compile to the new open-source CIL bytecode. This does NOT mean LSL will dissappear, it just makes alternatives available. Once Linden Lab releases their CIL specifications, it is entirely possible to code a "BASIC language layer" over them, so you can use BASIC's syntax for SL scripts.
==Chris

Now that sounds like something I can support

Lewis

He can't understand it! Thus it must change! Can't you guys get that!

While I agree LSL is pretty easy, MONO does support Visual Basic - which is pretty much the same as older basic versions, but even easier with the "point and click programming" interfaces. Cristiano can probably share more on that topic, I'm a command line basher myself.

Lewis, what I've noticed is that most people who have trouble with the concepts behind LSL aren't going to have much more luck with any other programming language for the SL environment. The problems they seem to encounter (and yes, this is a generalization) are not so much with programming concepts as the mathematics required to simulate a 3-D virtual world. Those same issues will still exist.

Regards,

-Flip