Survey for project priorities

Studio Blighty, part of Linden Lab's Core Platform group, is trying to prioritize projects for the next quarter. Babbage, Scouse, Kelly Linden, and myself have plenty of possibilities to choose from, but we need the help of the scripting community to help us decide what is the most important to focus on now. Please take the anonymous survey at:
https://www.surveymonkey.com/s.aspx?sm=Vyp_2fn74VLvZqjvu_2fbMvp3g_3d_3d
and let us know what you think.

Thank you,
Periapse Linden

I definitely like the way some of these tasks indicate things will be going. I'd like to see more security-oriented things in the near future (e.g. scripted estate tools), but lots of this is really top end and long needed functionality.

Thank you, and keep it up!

I've already put my two cents in (bump)

alot of nice posibilitys can be done with those

comments submitted, thanks

Interesting stuff... but some of that stuff is kinda buggin' me. I don't really wanna learn C#. And how would all the SL-functions be implemented into C#? I have NO idea about that language, but I don't think that the regular command-set provides functions for manipulating SL-objects... Having arrays and sutch would be VERY nice though...

And: what the heck is CLI-Assembly?

I feel like I was living in the woods for the last couple of years

Anyone can shed some light on this?

[edit]

I'm not very fond of .NET (had to do some stuff in VB.NET which is a pain, sorry) nor do I like the MS-Stuff... I somehow fear, that SL would become even more unstable than it is already...

Eh. I'm not very fond of C#/.NET either, but at least it is a relatively modern object-oriented language and platform, and it goes with the Mono VM that SL is already migrating to. C# is very similar to Java, C++, and a few other languages that are widely used at the moment, so it won't hurt you to learn it even if it IS an ugly M$ (by)product. It is a language/platform with half the computer industry behind it, so it WILL be a step up from LSL.

As for the functions, you just have to think of them as a library, (mostly) independent of the language. LSL is not the LSL/ll function library. The function API can easily be translated to another language, and probably most of the work has been done during the Mono integration already.

EDIT: Oh, and a CLI assembly is a bytecode library that will run in Mono or .NET. The Java and .NET platforms were essentially built as a middle layer between the hardware/OS and the user application (a so called "virtual machine", so that the latter can run unmodified on top of different underlying machines. It is a step between interpreted code and fully compiled code, and often involves a runtime compilation step that bridges the performance gap.

EDIT: Hewee beat me to the punch.


Any .Net language that compiles, compiles to CLI. This means you wouldn't be limited to C# or LSL, you could write your code in any (.net) language you wanted. And there are many .net languages. It won't be executed by MS's implementation of .Net but with Mono, which is it's own reimplementation of .Net. Basically it's how we become liberated from LSL.

You may wonder why Mono was picked as the VM. Here are some bullet points.
* Programming language agnostic (if it compiles to CIL you can use it).
* Easy interoperability between supported languages
* Cross Platform
* Open Source
* Free

While the last 3 bullets describe pretty much every VM available, the first one is very important and rather rare. Other VMs rarely support more then one language. The only other VM besides Mono that fits this niche is Java. When it comes to developing code Microsoft has made it easier to write code for .Net then Java. .Net was designed after Java so MS was able to learn from some of the mistakes made with Java. The Java VM was designed primarily to run the new programing language Java, while .Net was designed for C# it was also designed for VB and C++ which gave it more balanced development.

Realistically Mono (.net) is the only viable solution. .Net is trying to be the framework to rule them all, and it's winning. Who knows where things will be in 5 years let alone 10 years, things change but for the time being Mono really is the best solution for SL. It doesn't tie developers to a single obtuse language.

But don't take everything I say at face value, I'm not a fan of Java but then I'm not a fan of VB either. I am a big fan of C# though, I know it is imperfect but it is improving; it has good balance.

Thanks a lot, Strife!

I looked up a list of available .NET languages and was overwhelmed! Goodness! LISP/Fortran/LOGO! Stuff I thought were already dead!

... but I even saw, that there are some PHP.NET implementations around. Which means, I actually could use PHP to write SL-Scripts? Really???

I still wonder, though, how the SL-specific commands would be used? I mean, there's nothing similar to llListen or llWhisper in PHP (and I hardly believe that such commands are in other languages). How would I use these functions in a .NET-language?

... and - I'd even give C# a shot... it's actually only about the notation of the code... VB just hurts my eyes when I see it...

I haven't a clue how PHP.NET would work for SL. SL scripts are more class libraries then programs. The LSL functions (I believe) are in their own namespace and class. LL would distribute a dummy library that would be enough to satisfy your compiler. So if you were writing a C# program it would be something like this:

using LSL;

public class Script
{
    public void state_entry()
    {
        llSay(0, "Hello Avatar!");
    }
    public void touch_start(int count)
    {
        llSay(0, "Touched.");
    }
}

Thanks for listening to us =^_^=

Thanks Hewee and Strife for the explanations...!

I see the day coming when scripting in SL is exclusively for programmers and not for ordinary people like myself. I feel sad sad

I don't think that's true at all. If folks new to programming learned LSL and the LSL library, they can learn C#. That means not only can folks who know C# from outside SL come in and be productive, but people brand new to programming who are motivated inside SL to learn will also be learning something they can take directly to projects outside SL. And if you learned LSL, C# is just another programming language. The first one is always the hardest; the rest come like a breeze.

It's a conversation for another thread, but I think LSL and SL even prepare you for object oriented programming, because while LSL isn't itself an object oriented language, a constructed SL object is like a class, and the instances you rez in-world are like object instances.

In other words...news flash: you ARE a programmer, whether you'll admit it or not.

I can breath easy now? Thanks...
Will SL provide a developing suite for C# ? I am NOT going to buy one from MS

That won't be a problem! The implementation they are using, Mono, is free, you don't need to buy any commercial tools from anyone of you don't want them.

I got the impression that they are still looking at C# as something to offer as an integrated feature much like LSL is now, since that was offered up in the survey separately from the CLI proposal. Other proposed features with dependencies were identified that way in the survey.

Wow...sounds great.
OpenSim already has C# scripting and there are pretty nice things to do with. Like drawing on a prims surface that can make a dynamic text or any other pattern you want.
Looking forward to see it implemented. =)

Just to calm people, LL plans to support LSL for years to come.

LSL while being billed as a scripting language is really a programming language (a really badly designed programming language). If you learn to code in LSL you are a programmer, don't sell yourself short.

Here's my uninformed question: What's the difference between a scripting language and a programming language?

I'm not familiar with LSL yet, but finally getting to the point where I think it's time to start.

I have scripted for other games (MUSH, Neverwinter Nights). LSL looks a lot like what I did in those games. Same concepts and syntax, different function names.

I have done computer programming in classes. In BASIC, in the 80s. Nothing else since then.

Once, a friend of mine who is a professional computer programmer told me that if I could script in MUSH, I could do computer programming. He said the MUSH scripting was essentially the same as programming in C.

So I'm confused by the difference between a scripting language and programming language, but it would be interesting to know the difference.

OK i have a feeling I'll be corrected by the "real" programmers, but here goes.

Basically a scripting language does not have to be compiled into an executable file before you run it (it compiles and runs at the same time). In other words it stays plain text. For example the javascript on a webpage stays as plain text .... your browser reads it and compiles/runs it when it's needed.

Now when you compile and run a script it's slower than say C or C++ program because it has to compile the script every time it's run. Some scripting languages like Python save a cached version of the compiled file to speed things up. (LSL does this as well... the script loaded in the server is a cached compiled version)

In a sense I think LSL would technically qualify as a scripting language in that it is specific to the SL application. See http://en.wikipedia.org/wiki/Scripting_language . But in a sense we also have whole applications and systems inside of SL, and LSL has to be general enough to handle a wide variety of uses, so that forms the basis for the argument that it is not "just a scripting language."

But the real point is that a general enough scripting language IS a programming language, and if you've learned to use it, you ARE a programmer. You understand in some sense how the flow of control through the source code goes, and how to put together logic into a program that does something useful. Everything after that is icing, so to speak.