Scripting: Is it an art or just mathmatical logic?

[steph Arnott]

I started scripting in 2010 and in all that time i get, "that should be inline not a function" , "no, you can call it as a function", "should be all in one script", "you can be modular" etc, etc. What is the best way to write a script becouse it doing my head in. The wiki's showes state's and functions, some say more than one state is bad others say it ok. Seems to be yes this ok by some and no thats rubbish by others.

[LovingAndRejected]

It's not an either or, since mathematical logic is an art in itself... Programming definitely is an art, hence  Donald E. Knuth titled his classic books "The Art of Programming"

 

Truth is, there are wildly different ideas about what a good program should look like, or what programming paradigm is best. To me the essence is that everyone tries to attain a certain sense of beauty. A program is good if and only if it is beautiful. If it looks and feels like spaghetti, or the labyrinth of the minotaur, it most probably is faulty, too ^^

[Sassy Romano]

---

steph Arnott wrote:

I started scripting in 2010 and in all that time i get, "that should be inline not a function" , "no, you can call it as a function", "should be all in one script", "you can be modular" etc, etc. What is the best way to write a script becouse it doing my head in. The wiki's showes state's and functions, some say more than one state is bad others say it ok. Seems to be yes this ok by some and no thats rubbish by others.

---

My feeling is that some of these are a style and application thing.  For example when to inline and when to function.  A function always starts on a new 512byte boundary thus for every function you define, that's another minimum of 512 bytes gone even if it's just a function to add two numbers.  Then it becomes a tradeoff as to whether you call that function more times than the equivalent inline code and it's associated memory consumption.

One script/multiple scripts?  What if you're likely to use one of those scripts as a common script across products?  It doesn't make sense from a maintenance perspective to try to combine a common set of functions into one script.

Personally, I rarely use states, when I do, I tend to make more mistakes with initialising things per state change.

My feelings is that being mindful of limitations, scripting considerately with respect for resources available, those rank higher than worrying about style as long as there's a good reason for the methodology of a chosen route and not just because "it doesn't matter how it's done".

 

[arton Rotaru]

I see scripting like writing a novel. You can write beautiful stories, with meaningful sentence in the English language, or you can write boring stories, with awful sentence.

Same with code. You can write beautiful programs in a scripting language, with clever functions, math, and logic. Or you can write awful code that barely is doing what you want.

So it's more a form of art to me, rather than just mathematical logic.

 

[Rolig Loon]

There are always many ways to write any script, Steph.  Some are easier for humans to read, some take less time to run or less server memory, some take fewer lines of code, and some are just more "beautiful" than others.  When we discuss which methods are "best", we're usually discussing efficient use of time or memory, since LSL has to work within a fairly tight resource budget.  Sometimes, though, a more efficient script is harder for humans to read and follow -- especially humans who didn't write the script themselves.  In those cases, readability may trump efficiency.  And in many cases, simple personal preference does.

I have been writing programs in one language or another since 1963.  My style has evolved over the years as I have learned from professionals and have discovered my own tricks. It is as quirky as anyone else's -- probably quirkier because chemists don't feel bound by computer scientists' rules for writing programs the "right" way.  

Personally, I work for efficiency when I can.  I avoid breaking a script into states and user-defined functions where possible, and I try to do all processes in a linkset from a single script.  I inline functions, often eliminating multiple line processes as I do it.  To make sure my scripts are more readable, I use lots of white space and I pepper the scripts with comments. I use variable names that say what they do.  I document almost every variable so that I don't have to wonder what I meant when I come back a year later.  I break my own rules sometimes, but I do it sparingly and only when I have a darned good reason.

I am attracted to scripting as a logical exercise.  I love puzzles.  For me, there is an art to creating the puzzle --- the script.  When I have done it the best I can, it is beautiful. 

[Dora Gustafson]

---

steph Arnott wrote:

I started scripting in 2010 and in all that time i get, "that should be inline not a function" , "no, you can call it as a function", "should be all in one script", "you can be modular" etc, etc. What is the best way to write a script becouse it doing my head in. The wiki's showes state's and functions, some say more than one state is bad others say it ok. Seems to be yes this ok by some and no thats rubbish by others.

---

A good program is a program that gets the job done

Simple as that

Quoted from a Hewlett Packard Journal dated back when HP was on the cutting edge of calculators and small computers

I often think of this when I start to loose focus because of minor things like memory use and execution speed

:smileysurprised::smileyvery-happy:

KISS (Keep It Simple Stupid)

[PeterCanessa Oh]

I think I have said before that my priorities are i) make it work, ii) make it readable for maintainability, iii) make it as efficient as it has to be.

Efficiency is definitely an 'also ran' as far as I'm concerned - as long as the thing works and is easy to maintain.  I see myself as a writer first and, for me, programming is the art of writing well - clearly, sensibly and possibly interestingly.  This is, however, experience bred of large production (RL) systems where maintainability is much more of an issue than it's likely to be with LSL scripts.  My largest SL system was only 1,000 lines or so, compared to a 'real' system which may be hundreds of times that size.

Yours is an interesting question for another reason as well though.  As a philosopher and as a programmer I find mathematicians to have a very negative, if persistent, influence on computing.  First a lot of people are put off computers and programming because they think "computers do maths" or "you have to be good at maths" to program them.  Second most programming languages are 'maths heavy' in their supplied functions and semantics; variable assignment of "[Let] X = 5", for instance, compared to ABC's "PUT 5 IN QUANTITY".  Lol, I also hate operator precedence!  WHY should the result of "3 + 4 * 5" be 23?  Thirdly mathematicians write books like "Artificial Intelligence: a modern approach" which tells you all about the mathematics of a system and nothing about the data structures - which is the main thing any programmer will be interested in.  Fourthly mathematical equations are a very poor way to 'sketch' a program; apart from not making the sequence of operations clear they tend to use single-letter variable names AND all that Greek!  The philosophical objection is only that 'logic' is ours, not mathematicians'!  They get the numbers *grin*.

Some of the banking systems I've written handled trillions of US$ per day, but hardly did any maths.  Yes, keeping track of a lot of things and adding and subtracting big numbers but hardly rocket science ^^

I've never written a scientific system where I would be talking to mathematicians or those who used advanced maths on a regular basis.  Nor have I often needed it for any system that I have written,  For me, therefore, the logic has not come from maths but from a detailed understanding of what the program is meant to do.  That means talking to people about the things ('objects' if possible) they deal with, then writing that understanding clearly, in English (in my case) so they can follow it.  That gets gradually refined, through pseudo-code, to something the computer can understand and execute and people can maintain.  Clear and understandable is usually efficient enough.  Only as a final step, where it is necessary, do I optimise the code for the computer's sake.

-----------

Specifically, of the three things you mention:

• If the same code is used in more than one place then I put it in a function so there's only one place it needs changing
• Everything should be in as few scripts as possible because the communication between them is usually tortuous at best
• (The place to be modular is off-line, use your editor to assemble the modules for any specific script)
• I tend not to use states unless the functionality is VERY different.  A typical script of mine would have four states though - initialisation, configuration, operation and 'oops'.
• I break these rules whenever it seems right to do so - such as inlining 'function' code

 

[LepreKhaun]

Though designing programs may be an art, scripting is a craft- you are attempting to create a functional, practical object. One should approach scripting the same as a carpenter would when making a chair, not as Bob Ross painting a pretty picture.

 

And to craft a functional, practical chair the carpenter will use only what is required for the task. But including hinges in the design of it might be considered a mistake unless one actually desires a folding chair since the hinges make it more difficult to craft a chair that will stand properly.

 

Unnecessary complexity (unneeded hinges) should be avoided simply because it tends to interfere with correct operation (having a chair that will hold together and stand upright).

[steph Arnott]

Thank you all, i appreciate the time and thoughts put into the replies. All were well thought out and expressed eloquently.

[Sassy Romano]

---

steph Arnott wrote:

Thank you all, i appreciate the time and thoughts put into the replies. All were well thought out and expressed eloquently.

---

You expected less?  Can we debate how many peta-bits in a millibyte now?  *grins, ducks and runs*

:matte-motes-wink-tongue:

[steph Arnott]

LOL, ok.

[Ela Talaj]

The only reason LSL is called a scripting language is because it is not portable to platforms other than 3-D simulators. When the LSL compiler was originally developed SL was the only 3D game in town so LSL code was not portable to anything; now it is portable to some other grids but still not to general purpose platforms.

As far as SL and other grids are concerned LSL is a fully developed object-oriented programming language. But the language is how you say things, not what you want to say. A programming language is useless without knowing how to program. Computer Programming 101 would be a prerequisite for "scripting" in SL and those who don't have it only pollute servers with their inept "scripts".

So to answer your question, programming (including LSL "scripting") is not art and not mathematical logic, just professional engineering.

[revochen Mayne]

---

Dora Gustafson wrote:

KISS (Keep It Simple Stupid)

---

I changed my KISS-philosophy to keep it smart & simple :matte-motes-wink-tongue:

[revochen Mayne]

---

Ela Talaj wrote:

As far as SL and other grids are concerned LSL is a fully developed object-oriented programming language.

---

LSL would stay a procedural programming (scripting) language as the characteristics of obejct-oriented programming are classes, inheritance, encapsulation and polymorphism. Might missed one or two thoug (recursion i believe).

[Dora Gustafson]

---

Ela Talaj wrote:

A programming language is useless without knowing how to program.

Computer Programming 101

would be a prerequisite for "scripting" in SL and those who don't have it only pollute servers with their inept "scripts".

---

I never even heard about that so I must assume I am polluting the Second Life's servers

:smileysurprised::smileyvery-happy:

[PeterCanessa Oh]

Just for fun you might like to look at code obfuscation some time (or not!) ^^

Here is a mildly obfuscated version of a script I posted here some months ago:

 

list _;integer __;default{	touch_end(integer HowMany){		if((llDetectedKey(0) == llGetOwner()) && (__ > 0)){			integer ___;			integer ____;			integer _____ = (integer) (llFrand((float) __) + 1);			string ______;			while(_____ > ___){				___ += llList2Integer(_, ____);				____ += 2;			}			______ = llKey2Name(llList2Key(_, --____));			if("" == ______){				______ = "not here";			}			llSay(0, "The winner is " + ______);		}	}}

 

[Sassy Romano]

A quick search and replace on variable names would address that

[PeterCanessa Oh]

I did say "mildly" obfuscated.  Apart from the fun it does demonstrate why good variable names are important though.  While you could replace those - what would you replace them with?  LOTS of work to make it maintainable again.

[steph Arnott]

That makes more sense when read than when the variables etc are added, Oh my did i really say that!

[Sassy Romano]

replace things like __ with ||SetLinkPrimitiveParamsFast and replace ___ with ||GetRegionDetails  and so on, that would be appropriately silly

[Madelaine McMasters]

---

PeterCanessa Oh wrote:

Just for fun you might like to look at code obfuscation some time (or not!) ^^

Here is a mildly obfuscated version of a script I posted here some months ago:

 

list _;integer __;default{	touch_end(integer HowMany){		if((llDetectedKey(0) == llGetOwner()) && (__ > 0)){			integer ___;			integer ____;			integer _____ = (integer) (llFrand((float) __) + 1);			string ______;			while(_____ > ___){				___ += llList2Integer(_, ____);				____ += 2;			}			______ = llKey2Name(llList2Key(_, --____));			if("" == ______){				______ = "not here";			}			llSay(0, "The winner is " + ______);		}	}}

 

---

Okay, I'll bite...

__ is uninitialized. I think that means it'll default to zero.

llGetOwner()) && (__ > 0) therefore evaluates to zero, causing the if() to fail, unless the owner's UUID is zero. I suppose that could be Philip Rosedale, but he's left the building.

How'd I do?

[PeterCanessa Oh]

Ah, no, sorry you're on the wrong track.  Apart from anything else for the script to work it needs __ to be initialised and _ populated in other events.  This is just the final step of what the OP concerned was asking for.

This is not meant to be an exercise, I was just thinking steph might like to see some obfuscated code.  Perhaps I should have just posted the link to http://www.ioccc.org/

[Rolig Loon]

My very favorite obfuscated code of all time is still Void Singer's multipage dialog routine:

list uDlgBtnLst( integer vIdxPag ){
list vLstRtn;
if ((gLstMnu != []) > 12){ //-- we have more than one possible page
integer vIntTtl = -~((~([] != gLstMnu)) / 10);                                 //-- Total possible pages
integer vIdxBgn = (vIdxPag = (vIntTtl + vIdxPag) % vIntTtl) * 10;              //-- first menu index
string  vStrPag = llGetSubString( "                     ", 21 - vIdxPag, 21 ); //-- encode page number as spaces
//-- get ten (or less for the last page) entries from the list and insert back/fwd buttons

        vLstRtn = llListInsertList( llList2List( gLstMnu, vIdxBgn, vIdxBgn + 9 ), (list)(" «" + vStrPag), 0xFFFFFFFF ) +
(list)(" »" + vStrPag);
}else{ //-- we only have 1 page

        vLstRtn = gLstMnu; //-- just use the list as is
}
return //-- fix the order for [L2R,T2B] and send it out
llList2List( vLstRtn, -3, -1 ) + llList2List( vLstRtn, -6, -4 ) +
llList2List( vLstRtn, -9, -7 ) + llList2List( vLstRtn, -12, -10 );
}

Aside from her personal style of writing variable names, which is mildly obfuscating by itself, this single bit of code uses an impressive display of bit shifting and substitution hacks.  My favorite part is in the definition of vStrPag, which determines the active page by counting how many spaces are between the quotes in the empty string.  I don't use many of Void's tricks myself (although I do use this particular routine), but I learned a lot about LSL coding by taking her scripts apart to understand how they tick.  I do miss Void.

[Madelaine McMasters]

I got a "D" in my compiler design class because, rather than write a Fortran compiler in Fortran 88 (apparently the only language the professor knew), I wrote an assembler in MATLAB (I needed one for the processor I'd designed in an FPGA). Like some other interpreters, MATLAB can execute variables. So it's possible to co-opt the interpreter's lexical analysis, which I did. Nobody else in the class got anything working, beyond perhaps locating operators and operands. I could have used YACC (Yet Another Compiler Compiler) to do the job as well. Why do unnecessary work? I took my "D" to the engineering school dean and exchanged it for a "B" and a promise to behave, which I kept by leaving school to work full time.

Having been bit by the bug of code that can execute variables, I took the next step to writing code that could write variables that were then executed. I thought I'd invented something new, only to discover that self-modifying code had been around forever. I did eventually author digital signal processing routines that ran in slow Flash memory to generate algorithms that ran in fast RAM.

if you want to obfuscate code, there's no better way than to not write it until you run it.

[LepreKhaun]

---

revochen Mayne wrote:

---

Ela Talaj wrote:

As far as SL and other grids are concerned LSL is a fully developed object-oriented programming language.

---

LSL would stay a procedural programming (scripting) language as the characteristics of obejct-oriented programming are classes, inheritance, encapsulation and polymorphism. Might missed one or two thoug (recursion i believe).

---

I'll second that. I've never seen a definition of "object-oriented" that even remotely resembled LSL. Perhaps Ela is thinking of something else when they use that term???