Scripting: Is it an art or just mathmatical logic?

[steph Arnott]

Sorry i a bit confused here, what this mean " Fortran compiler in Fortran 88"?

[Madelaine McMasters]

Fortran (FORmula TRANslator) is (I believe) a nasty computer programming language originally designed for scientific number crunching. I took a course (Compiler Design) intended to teach me how to write a program ( a compiler) that could take a human readable program and convert it into the machine instructions (or something close) that a computer could directly understand.

This requires "lexical analysis"... tearing a sentence apart to find the nouns and verbs (the variables and operators) to get at the underlying meaning. There may be no worse computer language for doing this than Fortran, even the latest and greatest version at the time, Fortran 88 (which became a standard in 1988).

Because I am fundamentally lazy, generally oppositional, and wary of authority, I refused to use that wretched language to write anything, much less something that wasn't at all like scientific number crunching. My decision was correct. Nobody else in the class got anything to work at all. But they got better grades because they failed "by the book".

So, while there might be a right way, and a wrong way to write a program, I don't think you'll ever get any two people to agree on which is which. While they are disagreeing, why not do what you want?

;-)

[Rolig Loon]

Fortran was one of the early languages written for use on mainframe computers.  There was undoubtedly a Fortran I, but the version I learned in 1963 was Fortran II, which we ran on the old IBM 7094.  That was quickly replaced by Fortran IV (did they skip over Fortran III?  I don't remember), which ran nicely on the IBM 360 and then the 370.  Later in the series, Fortran evolved into other versions, including Fortran 88, before it became too much of an old warhorse and was eclipsed by more modern languages.

Fortran ( for Formula Translation) was designed for scientific usage, where COBOL and some of the other popular languages of the day were written for business applications.  I used to have a couple of fat volumes of scientific subroutines in Fortran, which we used for numerical analysis.  It was a wonderfully easy language to work in, and remarkably transportable.  I ran it on a number of IBM, DEC, and Cray machines and then on desktops until the late 1980s.

[Madelaine McMasters]

---

Rolig Loon wrote:

It was a wonderfully easy language to work in, and remarkably transportable.

---

---

Madelaine McMasters wrote:

Fortran (FORmula TRANslator) is (I believe) a nasty computer programming language originally designed for scientific number crunching. 

---

I think we've found our battleground, Rolig!

;-)

[Yingzi Xue]

In reply to the OP.  From what it sounds like, you've been scripting since 2010, but don't have any prior programming or scripting experience.  Am I right?  If this is true, then I can understand why you lack a sense of direction as to how you should script.

To specifically address your questions:
 

• As has been explained in another thread, there are times when you shouldn't make a user-defined function for a few lines of code.   Only you can determine whether it's better or not.   Easy way to tell if you're doing it right... check free memory with your function and without it.   Go the route that uses the least memory.   As for modular, some of the top businesses use modular scripts in their products.   Does that make it right?   Not necessarily.   It all boils down to efficiency.   The opinions you're getting on this forum are from experienced programmers and scripters who strive for efficiency; something that comes with time and experience.   Thus, it is encouraged that you choose the most efficiency practices with your own scripts.   I can think of a lot worse things to do than making an extra user-defined function that uses slightly more memory or a modular script-set that has more overhead on a server but are very small individually.   One factor to consider is how many of your scripted objects a person might rez in a region.   Common sense stuff that you should think of.   Don't sweat the details too much, there's a lot worse you could be doing.   Just know that the community encourages efficiency in your scripts, because it only takes one inefficient script to cause performance issues.   Many products probably wouldn't meet the grade of the most experienced persons here on the forums, but standards are something to strive for, for the sake of the grid.   That's all they are trying to instill in you, good sound efficient scripting practices.

As for a deeper understanding... Where should you begin?

 

• Fundamentals of programming are the same for any language.   Learn programming fundamentals like efficiency, readability, naming conventions, documentation, proper use of operators and flow control, when to use local and global variables... and the list goes on.
• Back in the day they taught you to create a flow chart of your program before you started programming.   I always considered flow charts tedious, but the concept isn't; writing down your concept, along with notes and ideas, goes a long way and may help you conceptualize better.
• Read/study other programming languages.   Find the common themes (again, back to fundamentals) in all programming languages.   If you have more than just one language under your belt, a clearer picture starts to form in your mind and things come easier.

I've been programming since the early 1980's as a hobby.  I can tell you that there's no substitute for hunkering down and reading, learning, experiencing.  There are countless scripts in the forum archive as well as the wiki library which should give you some good sound scripting techniques.  What you need is a foundation (fundamentals) to build upon.  Once you have that in place, everything else follows.

It can literally take many long years to get to the point where you can conceptualize your project, from start to finish, in your head.  It was easy for me to learn LSL because I had all of that programming experience under my belt.   For someone just starting out, who is new to programming, it can be a big hurdle to overcome.   As far as I know, there really aren't any LSL scripting classes that teach you basic programming fundamentals.
Learn as much as you can from a variety of programming languages.   You don't need to master any of them, but learning what all programming languages have in common will lay that foundation you need brick by brick and empower you.   If you don't want to go that route, there is plenty of information in the wiki on the LSL language, as well as countless examples you can peruse to garner a better understanding.

I'll leave you with a couple sayings... "Garbage in, garbage out."   It's an old programming saying, meaning if you input junk you get junk back.   Likewise, there's another saying... you get out of life what you put into it.   In the case of scripting and programming this is especially true, meaning you should be hungry for knowledge on the subject and actively work toward improvement and betterment, otherwise you won't get anywhere with it if you sit and wait for it to come to you.   Unfortunately, scripting and programming requires some work to be proficient at.   If you keep at it, there is a point on down the road where things click and you're over the hump.

Best of luck to you.

[Madelaine McMasters]

I agree, Yingzi.

While LSL might not be the starter language for learning to program, I can't imagine a more alluring environment to program in than Second Life. If you want to animate a thing in RL, you're looking at a significant and expensive undertaking in robotics. Here, you can find a quiet corner of SL with build/script permissions and start writing, with no worries of bruising, burning or cutting yourself, or damaging your sofa. And you can share your successes with others at the click of a button. But, as with building a robot, you must be aware of more than just a programming language to make things go.

Steph, part of the difficulty you, I and many others have with scripting here is that we're dealing with more than just a language. LSL is an interface to a complex underlying computer simulation, operated on shared hardware with both servers and viewers hopefully cooperating to make it all happen. We eventually have to understand numerous mechanisms at work under the hood to make them do what we want without degrading the experience for others. And understanding that requires leaning not only how to program, but how the servers and viewers work together, and how resources like time, memory and bandwidth are used throughout the system.

So you're dealing not only with the art vs. logic of programming, but the art vs. logic of resource allocation in a complex system.

If SL is your introduction to computers, it's a doozy. But ain't it fun?

 

[Yingzi Xue]

Some bad practices and ways to test your scripts for efficiency:

 

• Performance - If a script causes a performance hit, you know you're doing something wrong.  Built-in viewer features and scripted performance monitoring gadgets give you a quick and easy way of monitoring performance dips caused by scripts.
• Memory - How much memory is your script using?  What impact is there if the object is rezzed 10 times or 100 times?  Land info provides a script usage window so you can easily see memory impact of your scripts.  llGetFreeMemory to gauge impact; it's great for checking memory usage within the script at various places.
• Working vs Idle - A script should be designed to be as idle as possible.  Most scripts can sit by and wait for something to happen.  Some use timers for various tasks.  Keeping actual working time to a minimum and idle time to a maximum frees up processing power for other tasks.
• Repeating Code - If you have repeating code, it may be more efficient to make a user-defined function.  Check memory usage of each and weigh the differences.
• Flow Control - Bad flow control practices like unnecessary use of a timer or allowing a timer to accrue more event queue hits than it can process; easy fix, stop the timer at the beginning of the timer event, start it at the end.  Excessive looping (for/while/do) and using states for changes in functionality when global integers within the same state would be more efficient (i.e. boolean TRUE/FALSE or bit fields).
• Listens - Leaving channel listens open when they're no longer needed; quick fix is to use a timer to timeout and remove the listen.  Listening to local chat (channel 0) all the time (causes lag).  Chat spamming is also a bad practice, even if it's on a negative channel (causes lag).  Any type of unnecessary messaging whether it be chat or link message is a bad thing.
• Global vs Local - Using global variables when local ones will do nicely.  Determine what values can be temporary and what values need to be available globally.
• Keep text in your scripts under control.  A lot of strings and text in quotes eats up script memory.  Keep text to the point.

These are just a few ways to script more efficiently.  If you look through the forum archives, you'll find a lot of information about what causes performance hits in scripts.

 

I never did answer the question.. Is scripting an art or just  mathematical logic?

To me, scripting is a creative outlet.  A blank canvas to express yourself; much like a writer and his word processor or pen and paper, or a painter and his canvas.  It's a perfectionists pastime, because you're always pushing yourself to do something better than you did before.  As for mathematical logic... of course math is involved, so is logic, but each can be mutually exclusive, depending on what your script does.  I'll be the first to admit, I got B's in my high school algebra class, but math isn't my strong suit.  Even so, I've been able to accomplish whatever I've set out to do because I can always find the answer somewhere if I don't know it myself.  I'm not one of those programmers that tries to squeeze bytes out of a line of code by ordering it differently or using loopholes.  It simply doesn't interest me.  My point, you don't have to be a math whiz to program.  You can find math formulas all over the place that will fit what you're trying to accomplish.  Getting to logic... it's a main component of flow control of your script.  Thankfully, most people are familiar with logical deduction, so it should come easy.  Scripting is what you want it to be and each person has their own unique perspective on it.  I think the best part about scripting is when you get in that zen mode where time flies and you are lost in it.

[steph Arnott]

Lots of post from wonderful people, so answering individual posts is to much.  So I try my best.

I liked the obtufise thing, I did go to the web site tho did not understand the code but I got the point.

No I never wrote a program before SL, I did not even know what one was. I only start writing code in SL because I asked a guy how I could move a box with LSL and was told girls should stick to makeup and cooking. So I thought OK I prove that theory incorrect, immature maybe but comments like that make me mad. LOL I have read the wiki's from start to end. They good but to be honest if one has no knowledge of code not very helpful, because without a basic understanding it may as well be in Mandarin.

I know this is a lack of self confidence on my part and lack of full understanding how code works. Everyone that posted on this explain things, It when others give conflicting answers to a script that I can not understand which is good or bad. 

BTW; I asked this question not just for me but all that are either starting or at a more advanced stage as regards to a framework to work from. English is not my mothers language so if places are confusing I appoligize. Think it OK, but I find the language all back to front, LOL.

[PeterCanessa Oh]

Oooh, you aren't the only one that gets mad at comments like that Steph.  We also appreciate that you're asking "how do I start to understand all this" from a general perspective and hope that other people will get something from it too.  You, unlike many other people, have the self-confidence to know you can understand this, given time and practice and the willingness to ask questions when you don't.  "The only stupid question is the one you don't ask" - too many people are too scared/shy to look stupid by asking so they stay stupid (uneducated really) in silence ^^.  We were all in the same position when we started and we all had to work hard(ish) to understand this gibberish before we 'got it'; some never really do.  As you've found already though there are usually several ways to achieve the same result and no total agreement about which is best.  YOU are writing YOUR scripts; choose the alternative that YOU are most comfortable with, but try to understand the alternative(s) too.

Most of us would admit that if we look at programs we wrote several years ago we often want to scream at ourselves "why did you do it that way!" - not only does everyone have their own style but each person's preferences change over time as they appreciate other people's views more, or just meet different circumstances that benefit from a different approach.

The point of the obfuscated code is that no-one can understand it!  The contest started as a sort of joke, pointing out where people had made programs that were unmaintainable - if they had any errors or lack of efficiency then tough, no-one could read and understand them in order to fix them.  Obfuscated code is the "what to avoid" of my "clear writing style".  These are the sorts of games programmers play.  There are many - hundreds or thousands of - different programming languages too, some invented just to be 'odd'.  Such 'esoteric languages (http://esolangs.org/wiki/Main_Page) are another programmer's game but migh simply be confusing to look at - some are designed to be!  I do like reMorse, however, in which all the commands are like Morse codes; that is everything consists of dots, dashes and spaces, no real words at all ^^

----------------------------

Now to get mad (history of computers):

"Girls should stick to makeup and cooking" - the first recognised 'programmable computer' is probably Charles Babbage's Analytical Engine (1837).  The first known program, written by the WOMAN Ada Lovelace, would have worked except that the MAN's machine didn't (it was just too hard to build).

Next big advances were probably 100 years later, during the second World War, when MEN designed and built the first electro-mechanical computers such as Colossus at Bletchley Park.  All their hard work and ingenuity went into that - it was almost exclusively WOMEN that programmed the things! (Using switches, cables and dials).

The WOMAN Grace Hopper invented programming languages.  Such a bald statement probably isn't totally true, since such things aren't done in isolation.  Nevertheless Grace Hopper is THE programmers' icon (unlike, say, Alan Turing whom the press always mention).  'In 1952 she had an operational compiler. "Nobody believed that," she said. "I had a running compiler and nobody would touch it. They told me computers could only do arithmetic."' (the wit and wisdom of Grace Hopper).  She died in 1992 and was an inspirational speaker, fascinating 'guiding light' and, generally, pretty amazing.

The short version is this: men invented ovens and told women to do the cooking.  Women made better ovens that were so good even men could use them.

------------------------------

Programming languages:

Low-level: Low-level 'languages' are all about directly programming the machine itself.  They are a lot of work for people but easy for the computer.  i) machine code - lots and lots of 0's and 1's, switches on and off, plugs in or out, etc.  - you can't do it without making mistakes but that's all there was when the machines were first built.  No-one programs in machine code if they can help it although it's the only thing the computer itself recognises.  ii) assembler - commands and variables have names which directly correspond to the physical machine's (CPUs) construction and memory addresses.  Names tend to be a bit cryptic (DJNZ R0 LP = "Decrement and Jump if Not Zero" from my early (8052) days) but you can write anything in assembler.  The only people that do, usually, are those that are writing drivers for new hardware or somesuch where there isn't an available high-level alternative.  Assembler is probably the most powerful way to program a computer reliably, since there's nothing else "in the way".  The big drawback (apart from the effort!) is that the programs will usually only work on one type of machine because others will have been built differently.

High-level: High-level languages try to let people write in "something like" natural language.  They are easier for people but require an interpreter or compiler program to translate the 'source code' into machine code before the computer can execute it. i) compiled - when you compile (just 'save' in LSL) your program the compiler-program reads through it all and works out which machine-code instructions will do the same thing - "while(--Counter)" may well become "DJNZ E0 LP" in assembler and whatever actual switch-settings that equates to in machine-code.  It usually requires several to many assembler/machine-code instructions to match each high-level command.  Aside from reporting errors in your source code the compiler creates a new (machine-code) file that the computer can execute directly*.  Unless you make changes to your script the source code file is not needed again.  ii) interpreted - an interpreter does much the same job as a compiler but it does it every time you run your script, therefore the source code IS needed every time.  Compiled programs are generally faster than interpreted ones (because the translation work has already been done) but are somewhat less flexible (because their machine-code will be specific to a type of machine).  The arguments are a bit arcane but interpreters have come into fashion and faded again several times.

Optimisation: What to do if you want your program, written in a high-level language, run more efficiently.  i) know your compiler/interpreter - the biggest influence on how well a program runs may well be how good the generated machine-code version of it is.  "for(i=0; i<1000; i++){// Do nothing}" is a loop that does nothing 1,000 times.  A simple interpreter will dutifully read this line, translate it, keep incrementing the counter and will doing nothing - 1,000 times.  A stupid compiler will produce the same machine-code but only has to do the translation once.  Cleverer implementations will work out that doing nothing 1,000 times is the same as doing nothing once and, in fact, no machine-code is needed at all.  In other, more common, cases "Num = Num + 1", "Num += 1" and "Num++" may result in different machine-code even though they do the same thing.  Unfortunately the compilers for LSL are on LL's servers and we don't know which things they are good at and which they aren't, nor can we do anything about it, ii) inline function code - self-contained functions make it easier to read and maintain a program but there is a computer cost.  Every time a function is 'called' the computer has to make a note of where it was, create copies of the parameters being passed to the function, do the work, tidy up and then go back to where it was.  That all takes time and memory, so writing-out the code 'in line' with the other instructions, instead of in its own function, can improve performance at the cost of maintainability.  iii) generally, make sure your program is only doing what it needs to.  This might seem obvious but when you're patching-together different scripts and adding and editing over and over again it's fairly easy to find, for instance, that your script stops to re-read the configuration notecard every now and again.  Getting rid of such logic errors is the reason for insisting on readability and maintainability - if you can't work out what it does you won't know if it's doing it sensibly.

[*@ professionals: I realise that this explanation of compilers is not strictly true of JIT, .Net, Mono, etc. but it's confusing enough as it is - and only of specialist interest since we can't do anything about it].

 

[Madelaine McMasters]

Steph, given that you are learning a third language by reading instructions written in a second, I'm impressed. Thank you for joining the rest of us girls to show (once again, as Peter reminds us) that we can do more than cook and sew. After you've tackled programming, I suggest you try arc welding. It's fun, it's practical, and it's all sparkly!

;-)

[Rolig Loon]

I agree, but recommend that you at least start with a wire welder.  Stick welding takes more practice to get right and it's scarier at first.

[steph Arnott]

LOL, I was raised up on a farm, my father teach me all that at 10 as well as gas cutting and stripping an engine down. 

[Madelaine McMasters]

---

steph Arnott wrote:

LOL, I was raised up on a farm, my father teach me all that at 10 as well as gas cutting and stripping an engine down. 

---

Woo hoo, Steph!

When I'm frustrated, I go out to the barn, fire up the tractor, drive into the woods, push stuff around with the front end loader, then return to the barn and weld back on whatever broke off while I wasn't paying attention.

I saved the crankshaft from the first car I ever bought, which lasted 17 years. I tore it apart with the help of the neighbor kid, so he could see all the bits. I needed his muscle, he needed my experience. I plan to make it into a table lamp... after I make the table.

;-)

[PeterCanessa Oh]

Elizabeth II, Queen of Britain, etc. etc. was a truck driver/mechanic during WWII. Girls should stick to programming though, otherwise they might start requiring me to go out and get messy too ^^.

 

[Sassy Romano]

---

steph Arnott wrote:

Lots of post from wonderful people, so answering individual posts is to much.  So I try my best.

I liked the obtufise thing, I did go to the web site tho did not understand the code but I got the point.

No I never wrote a program before SL, I did not even know what one was. I only start writing code in SL because I asked a guy how I could move a box with LSL and was told girls should stick to makeup and cooking..

---

Enjoy the journey Steph.  When I look back at my early LSL I cringe but at least I did something.  There are still way better programmers than me, it's not my goal or profession , just as there are better texture artists, better 3d modellers.  Then again, I have skills that stand far above some of those when it comes to my field.  Do I care?  No, should we care?  No.

Do what makes you happy and have fun with it. :matte-motes-sunglasses-1:

[Valareos]

Oddly enough, it is logic, but not mathematical, its more structural.  And IMO, best way to approach programming is a modular approach. Work on a code that does one thing at a time, make sure that works (even if you throw in dummy info in it), save it, and give it a name.  In your "master" document, just refer to the code by name. what you will end up with is what looks to be just a flow chart of names.

 

If you got repeating names, look at those and see if there is enough to save room by putting it as a function instead of seperate. And dont be afraid on your working copy to have it split, then combine into inline later if you so desire.  And remember, if your script is going to be one that no one is looking at, then you make it as compact as possible. If it is somethign requiring people to edit, or understand what your doing, you need to make it more readable.

Following is a quick example of this (its php, but concept is basically the same)

Define DatabaseGlobal Variablesif($event == "CSelect")	Select Characters	List Charactersif($event == "CCheck")	Select Character/Name	Confirm Character/Name	Send CharID and Unspent	if($event == "AddC")	Select Character/Name	Check if Name Exists	IF Yes, Add Character	If No, send errorif($event == "DelC")	Select Character ID	Delete Character	Delete Character Skillsif($event == "AddXP"	Select Character ID	Add XP	Update Character XP

 This was just a sample of what ended up being 20 more cases for the php backend to talk to an SL script.  having it in this easy language makes it easier to see where functions work better. I can see just from this, that a function for finding a character ID is a good thing to have, because that coding will be called to several times.  This modular format asllo means you can find bugs easier, because you have less code to have to worry about. Again, its mroe about structure than it is math