Tuesday, December 02, 2008
USERLOGIN PASSWORD Remember?
You are here » Learning Center ยป Forums

Openlife Forums

 Openlife Grid Forums
Minimize
 
  Openlife Forums  Scripting  LSL Discussion  'SMART CODE' -- Replacement to LsL -from previous forum.
Disabled Previous
 
Next Next
New Post 2/12/2008 12:18 AM
Online now... Sakai Openlife
610 posts
openlifegrid.com
Openlife Senior




'SMART CODE' -- Replacement to LsL -from previous forum. 
Modified By Sakai Openlife  on 2/12/2008 12:18:28 AM)
SharpEdge
User



Location:

Joined on:
09-Feb-2008 01:57:47
Posted:
6 posts
SharpEdge
# Posted on: 09-Feb-2008 03:29:05.   
I posted this as a reply to another thread, but from the immediate response, figured it might be worth repeating here in this more directly applicable thread.

One thing I would like to see... and that I would very much like to have a hand in, is implementing an entirely new, smarter scripting language.

There is so much in LsL that is goofy, cumbersome, and just plain bad design that could be greatly improved. While I can see that compatibility with current LsL code would be desirable for easy porting of existing concepts... in addition it would be WONDERFUL to see an entirely new language emerge. : )

OPEN SIM USER-CODING CONCEPTS

First, stop calling it "scripting". It's not scripting, it coding. Who ever came up with the "scripting" nomenclature? Scripting is writing text or using calligraphy. Programming is called "coding". Let's go back to industry standards.

Suggested language name: SmartCode (SC) for short. Why? Because that's the concept behind it... code that is simple, smart and concise.

To get the general overall idea, let's look at a few example concept improvements.
================================
LsL remark symbols: //
Improved: ' (this is an industry standard)
Advantage: One less byte of code per remark. One less character to type per remark.
================================
Get rid of REQUIRED ;
Why? Because they're a pain and take up space. Consider these alternatives:

LsL method:
StatementOne;
StatementTwo;
StatementThree; 'etc etc etc

Viable alternative:
Use ; only when necessary to separate statements on the same line:
StatementOne;StatementTwo;StatementThree
or...
StatementOne
StatementTwo
StatementThree

The system should be smart enough to recognize an endline as the end of the statement without the coder being forced to add an unnecessary ;
================================
Get rid of unnecessary () and {}
Brackets are great in some instances. But they can also get in the way of efficient coding.

LsL method:
If(SomethingIsTheCase)
{DoThis;AndThis;}
else
{DoThat;}

SmartCode method:
IF SomethingIsTheCase
DoThis;AndThis
else
DoThat} 'or ENDIF. Either one works, but } is short. Brackets do have their place. Just don't force the coder to use them when not needed.

What are the advantages of this concept?
1. It saves coding space
2. It relieves the coder of being forced to remember to add this ; and that { and make sure every { has a } etc etc ad nauseum.
3. It simply provides for an easier and friendly coding environment.


================================
LsL method of setting color on a prim:
llSetColor(<r,g,b>,ALL_SIDES); ' don't you just hate those totally unnecessary <> "vector" marks, and the unnecessarily long ALL_SIDES?

Improved:
Color r,g,b,ALL
Much sleeker and easier to understand! Equally important, the improved code saves 13 characters of space... a significant savings!
================================
LsL:
llSetObjectParameters([blahblahblahblah])

Improved:
Divide object parameters into easier-to-understand and easier-to-use statements:

PrimSize x,y,z
PrimForm [cube/sphere/etc]
PrimHollow x
etc etc. So much more easy to use.
================================
LsL:
Particleblahblah [blahblahblah]

Improved:
Again, divide into separate, easily altered statements:
ParticleStartSize x
ParticleStartColor r,g,b
ParticleTexture "name"
etc
================================
What about those ludicrous eular math / rotation concepts?

Vastly improved:
RotateObj x,y,z,speed 'rotates in relation to base prim
RotatePrim x,y,z,speed 'rotates specific prim
RotateObjAv x,y,z,speed 'rotate object in relation to avatar facing
RotatePrimAv x,y,z,speed 'rotate specific prim in relation to avatar facing
RotateObjSim x,y,z,speed 'rotates in relation to sim directions
etc.
================================
As a good example, consider the SmartCode method of scripting a door opening and closing:

If DoorClosed DoorOpen 'yes, the language is smart enough to figure out you want to rotate the prim 90 degrees.

Or, if you want to do it the more direct way:
If doorflag=closed SetObjRot 90,0,0;doorflag=open} 'far simpler than the LsL method

And imagine:
If DoorClosed and OwnerClicked DoorOpen 'wow, how simple and smart!

If anyone has ever tried to script a door using LsL eular math, the improvement is obvious.
================================
There are many, many such instances. What I see is a combination of C++ concepts and BASIC (face it, can't beat BASIC for simplicity). I love the event-driven concept of LsL and of course, C++ is as direct coding as one gets. But that doesn't mean a language has to have complex syntax or be difficult to understand. The best way to code a language is the simplest way, and should involve 2 questions:

1. What am I trying to achieve with this statement?
2. What is the absolute simplest and easiest-to-understand syntax to achieve that goal?

Obviously Cory didn't ask those questions when writing LsL, and LL never fixed the problem. Would be great to go back to ground zero and completely redo that mess.

Sakai Openlife
Openlifegrid.com Founder

Exciting things are happenning!
http://openlifegrid.com
 
New Post 5/15/2008 8:38 AM
User is offline Nic Loeher
3 posts
Openlife Newbie


Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

One interesting view. It can make the coding easyer to understand and easyer to type.

 
New Post 5/18/2008 11:41 PM
Online now... Pyotr Wolf
66 posts
xyrophile.com
Openlife Apprentice


Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

okay, i really feel bad becaue this post is kind of snarky, but there are good reasons for a lot of the things discussed here.

on calling it "scripting":

it's called scripting because it's an interpreted language, not a language that compiles to machine code.  technically, it compiles to intermediary bytecode which is JIT compiled by a virtual machine, but essentially this explains the nonclemature.   the term "coding" to refer to programming is actually quite new, even newer than referring to programming using scripting languages as "scripting"

on comment syntax:

uhh... double slash would be the industry standard.  you know, like in C and Java.  using a single apostrophe for comments isn't the standard, it's just a feature of microsoft dialects of BASIC.

 

but as i read through the rest of this i get a sinking feeling when i come to the next part.

on special characters:

 

there's a very very good reason for all the brackets and punctuation marks and so forth:  they allow whitespace to mean nothing.

say what?

well, let's look at the example of the semicolon.

this block of imaginary code:

 

doCommand1(parameter, otherParameter);

doCommand2;

doCommand3;

 

does EXACTLY the same thing as this block of code:

doCommand1(parameter, otherParameter);doCommand2;doCommand3;

 

so does this block:

 

doCommand1(

parameter,

otherParameter

);

 

doCommand2;

doCommand3;

 

this in itself solves your problem of nicely formatted lists of parameters.  looking at the example given of llSetColor, it could just as easily be written as such:

 

llSetColor(

<r,g,b>,

ALL_SIDES);

or any other arrangement desired.

why does this work?  because the compiler ignores spaces, line breaks, tabs, all forms of whitespace and just looks for the special symbols to find where each statement ends.

as for brackets, braces and the lowly parenthesis, it really doesn't matter how many bytes you save as none of them actually make it into the final script running on the server.  they're there for human readability and flow control.

and for the record, in most languages that use them, braces are only necessary if you have more than a single conditionally executed statement.  i havn't tested it in lsl, but in java for instance you can do the following:

if(variable == value)

{

       doSomething();

}

 

but if you only have a single command to execute, you can just do

if(variable == value)

    doSomething();

 

or even

if(variable==value)doSomething();

in accordance to the whitespace rules.  and yes,  else still is supported.

 

as for the vector marks, tell me, without them can you tell me which of these triplets is a vector (which is a single unit with three subcomponents) and which is three seperate values?

a,b,c

d,e,f

no you can't, and neither can a compiler.  hence the marks.  you could specify in every command that used vectors the precise order of parameters to resolve that ambeguity, but that actually means making the language MORE rule bound and restrictive.

as for ALL_SIDES, you do realize that what you're referencing is a constant with it's own value, right?\

 

As for rotation commands, the euler commands are simply there so you don't have to learn to use quaternions, the mathematical concept that actually underpins the engine.

 

 

i'm sorry, i don't know how to say this, but "smart code" is really stupid.  and yes, you can beat basic for simplicity AND ease of use.  example:  LOGO.  example: G (the entirely visual language in LabVIEW)  hell, brain____ only has 8 commands and the entire compiler fits in 256 bytes.  that's about the simplest language imaginable.  the problem?  the simpler a language is, the harder it is to actually use to do something useful with it (hence the name brain____)

what i'm seeing here is somebody who's grown up with qbasic and visual basic and has gotten used to them.  and don't get me wrong, they're great languages, especially when learning the fundamentals of programming, but they're not necessarily the greatest languages architecturally.  overall, LSL is remarkably well designed from both a technical and ease of use perspective.  that's not to say that they're perfect, but anyone who's even done first year comp sci can tell you that most of sharpedges suggestions would be huge steps backwards from what we have now.

 

 

 
New Post 5/22/2008 1:56 PM
User is offline Elsja Vacano
58 posts
Openlife Apprentice




Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

Pyotr,

I agree with you, I never answer before, because the post is old and I dislike to say nothing constructive.

 

However, even if LSL is called script, I prefer say that is a compiled language, because it use like compiled language than a scripted language.

The most difference I see here is in a scripted language the comments are a part of the code. In a compiled code, it is the first thing removed.

The the smart code win 1 byte by comment, LSL remove the whole command.

So smart code 0 - 1 LSL 

 

Thanks you, I asked myself who is so stupid to use the single quote  to comment something.

 

I confirm

if(condition) code;  // works in LSL you do not need to the brakets (sorry I can not type in this editor.)

 

This anti-bracket specialist have just forgot one of the  most powerfull feature of the brakets.

 

A section delimit by brakets contains several lines of code and variables declaration. But can contains too a or several sections delimit by bracket.

so (remember i replace the bracket by [ ] )

[ integer e;

  [ integer d;

   code; blabla; code;

  ] // d stops to exists but e is still there

[ string a;

  code; blabla; code;

] // a stops to exist and because it is a string a lot of memory is release.

 code to use e;

]
So by using bracket you not only delimit section of code but able to best manage the memory when the script runs.

Unfortunately, the llGetFreeMemory returns the memory never used rather the real free memory so I cannot prove it. But in theory that must work like that.

 

 
New Post 11/5/2008 9:49 PM
User is offline Bubblesort
17 posts
Openlife Newbie


Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

/me groans

Really?  I know... I have to get used to it.  My comm media professor is making me learn lingo and lua, which is the same syntax as what you describe.  I'm used to C++ and Java syntax, though, so I"m more comfortable with LSL syntax.  I'll get used to it, I guess.  That is the direction that coding in virtual worlds is going in, unfortunately.  I don't like it, but dinosaurs like me have to adapt... I'll try not to whine too much more about it.

 

~Bubblesort

 
New Post 11/6/2008 8:43 AM
Online now... Alicia Sautereau
42 posts
Openlife Newbie


Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

it looks cleaner and maybe give less errors in the end cause of forgetting a { } here or there, just something to get used to i guess

 
New Post 11/6/2008 8:58 AM
Online now... Pyotr Wolf
66 posts
xyrophile.com
Openlife Apprentice


Re: 'SMART CODE' -- Replacement to LsL -from previous forum. 

this isn't actually happening;  sakai just brought the post over from the old forum many many moons ago (we switched to this forum about 6 months back)

 
Disabled Previous
 
Next Next
  Openlife Forums  Scripting  LSL Discussion  'SMART CODE' -- Replacement to LsL -from previous forum.
Privacy Statement | Terms Of UseAll Rights Reserved 2007,2008 3DX - Openlifegrid.com