|
Stan Binder
Registered User
Join date: 24 Feb 2007
Posts: 24
|
01-27-2008 05:30
From: Strife Onizuka I believe the big reason they chose Mono over JS, Java, Lua, and Python was that it gave them choices. CIL has many languages that compile into it; it doesn't lock them into a single language. Efficiency, versatility and licensing cost were far more important then it being open source, anyway how many main stream linux scripting engines aren't open source? I think that performance, portability and open source were important for LL. Open source just because there are plans to open the source of the sl server. This would be very difficult if there are licensing issues. This is now the case for the physics engine, but they integrated Havok 4 in a way that allows them to replace it by other physics engines. |
|
Stephen Zenith
Registered User
Join date: 15 May 2006
Posts: 1,029
|
01-28-2008 08:28
From: Lee Ponzu Something that converts <insert language here> to LSL, which then gets compiled. One recalls that C++ was originally a pre-processor that spit out C.
It had the rather brilliant name CFront. </trivia> |
|
Stan Binder
Registered User
Join date: 24 Feb 2007
Posts: 24
|
02-02-2008 06:06
Miguel de Icaza is the leader of the Mono Project. I was very surprised when I read that in his blog. From: someone The work that we are doing on Mono's runtime to support Silverlight (the sandbox system and the hardening of the runtime) is going to enable the use of other programming languages to script components on Second Life. It can't be bad if the Lindens have contact to leading persons such as Miguel de Icaza. He knows that the Lindens would like to see other programming languages in Second Life next to LSL! I never expected that... |
|
Simil Miles
Creator
Join date: 1 Mar 2007
Posts: 300
|
03-17-2008 00:57
_____________________
UnConWTech @ Flo (144, 84, 224) http://unconwtech.free.fr
SL books http://astore.amazon.com/secondlife-sl-20/
Need a beta tester for quality assurance ?
Need a translator for English, French, Spanish ?
|
|
Lear Cale
wordy bugger
Join date: 22 Aug 2007
Posts: 3,569
|
03-17-2008 08:06
From: Lee Ponzu From a practical view point, this means that the sim server will not have to work as hard to run all the scripts in a sim, so it will have more time to do other stuff, so sim server related lag will be decreased. Lindens seem to contradict one another on this. One Linden tells us on a sim that's busy with physics, scripts take a maximum slice of CPU time. However, on the Mono blog, another Linden tells us that Mono will reduce lag. Other than reducing script lag only (e.g., objects taking a long time to react to clicks), Mono would only reduce sim lag if it meant less memory usage for scripts, decreasing the amount of virtual memory page faults. Unfortunately, we can't figure out the truth from what they say. From: someone It might also mean that programmers won't have to care as much about runtime efficiency, so instead of hand tuning a script, they will go ahead and write something else that is needed. Welcome to reality, since about 1950. Ever since then, hardward folks have been bailing out us software types by delivering faster and faster machines, and we've responded by writing less and less efficient code (but which has lots more features). I've been coding professionally for 30 years now and the trend is unmistakable. Coders optimize as much as they need to and not much more -- and that's the *good* coders. Today's software is layer upon layer of different code written by different teams for various purposes, and at each layer boundary, there's lots of room for inefficiency (it's often quite challenging to avoid it). "Fortunately", LSL doesn't give us much opportunity to layer software, so we won't see too much of this particular issue in our SL objects. |
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
03-17-2008 12:18
From: Lear Cale Welcome to reality, since about 1950. Ever since then, hardward folks have been bailing out us software types by delivering faster and faster machines, and we've responded by writing less and less efficient code (but which has lots more features). QFT. not long ago i happened to pull out a an old 486 computer I have and fire up Windows 3.1 on it. It was startling how much faster a more responsive it was at 66mhz, compared to Windows XP on a 2.6 ghz machine. Oh, so much bloat!  |
|
Very Keynes
LSL is a Virus
Join date: 6 May 2006
Posts: 484
|
03-17-2008 12:33
One of the things that I do like about scripting for SL is that the limitations remind me of the old days of developing for embedded systems, with between 2 to 16k available for both RAM and ROM. What I don't like is being forced to overcome those limitations whilst restricted to using a bloated compiler like LSL. I would love to see you get the Assembler working, even if it is just a curiosity with MONO and Server Side compile just around the corner. It may even show Babbage that there is a ground swell of interest for low level programming in the community (apart from the griefers that is).
EDIT:
Just realised that I posed this in the wrong thread, but as both are taking a similar track I will leave it here. For clarity my last remark was aimed at Day Oh and his Optimisation tool.
|