Jump to content

I'm bored, lets debate something, STATES!


Ichi Rexen
 Share

You are about to reply to a thread that has been inactive for 1038 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

2 hours ago, Ichi Rexen said:

 One of the first languages I spent time learning IRL was Python and I spent a good amount of time programming procedurally only. You have me wondering now if thats why I have a preference to single state over multiple states. I didn't start doing any real OOP until later on when I started covering Java and its hybrid Jython

mostly like yes

my own path was a managed code environment. Office VBA writing custom functions for my own use at work, which then started to get used by my then co-workers. From there my organisiation then asked me to look at some of the .NET and Java client server apps we were using. Managed code object-oriented environments. Then i got asked have to a look at a legacy unmanaged app written with Delphi 5.  When I dived  into the Delphi VCL library I found that the classes I had been using up until then were wrappers for procedural code, where the deeper you went the closer to the metal code you got.  For example: TMemo > TEdit > TWinControl > TControl > TComponent > TPersistent. At the TPersistent level it is pure low level procedural Pascal.  And then when I opened up some of the custom components built for the app then I found they had been written in C++ drilling down to pure C and in some optimised parts of the components purely procedural Intel x86 assembly

so having gone thru this I ended up for a time in a professional dev shop which was a pretty hardcore blistering learning experience for me. Serious people, hard deadlines and lets get it done and shipped.  From this I was headhunted to another organisation, for who I still work, but now more in a consultative role  

so my coding life experience brings me too LSL from the opposite direction from you pretty much.  State event-driven managed code > object-oriented code > procedural code > LSL

as Rolig and other long time experienced programmers with broad experience have said. Is no one true way. There is no one true design model. There is no one true code workflow methodology

if there is a truth in the commercial world of programming it is: First get our code to work without error - however well or badly it might perform in resource consumption and runtime efficiency. Then Second, optimise the codes after the app works without error.  Then Third, look at how code can be written so that is portable

however, a hard truth is that clients don't pay us to write portable code that we are going to use again for another of our clients' benefit. They are paying for their app, not paying for the work we do for other clients

but yes, when we do get to be like Rolig and others with years of tried and proven experience, then we can write for One, Two and Three all at the same time

when we don't tho have that hard-earned experience and try to jump to Two and Three before we have mastered One, then our codes are never going to work without error. No matter how little resources we use or how fast it runs, or how portable the code is. Slow and inefficient code that runs error-free wins every time over code that runs fast and lean and dies before it gets to the finish line. So One, then One-Two, then One-Two-Three

 

  • Like 3
Link to comment
Share on other sites

6 hours ago, ellestones said:

 

usually in a discussion about states and events then the general approach, general meaning fallback, tends to follow our life coding experience as programmers

typically those raised on procedural languages tend to write LSL code procedurally within a single state. The equivalency being a C program:

 main() { initialise(); program_loop; exit();)

those who are raised on event-driven object-oriented languages tend toward using states, along the design principles:

state initialise();
state main();
state exit();

am not sure what people's experience of tools like C# and Delphi Pascal are.

 

I agree, so this puts me in the “get off my lawn” camp! My Pascal goes back to Turbo Pascal. (Great hacks to use memory loading tricks!) I’m pretty sure we also used Borland C before Microsoft, and also Microsoft C++ before it was “Visual”. 

Link to comment
Share on other sites

States are the way to go if you need stuff to be clickable in some instance, but not clickable in others. That hovering hand over the object can interfere with other scripted objects--specifically ones that take control over your mouse button. E.g.: you can't fire a gun in 3rd person if the object in the background has a touch_start event in its state.

  • Like 4
Link to comment
Share on other sites

6 hours ago, ellestones said:

 

[...] intuitive meaning intuitive to a person conversant with object-oriented event-driven programming

basically in these languages we don't initialise as we go. We initialise first, try/execute the code, handle the exceptions, then finally tidy up. [...]

I very much agree that the way an LSL programmer uses states reveals a lot about their background. I also agree that states (and state_entry and state_exit) are the closest thing LSL has to an exception processing model of flow control. I'd just note that this model is broader (and maybe older?) than OOP, with for example LISP's throw/catch condition handling available historically independent of different object system variants.

10 hours ago, Fionalein said:

[...] The controls in flight mode were completely different than in ground mode...

I use states in a state machine much more often but usually I have a flag variable called "state" and "if" / "else" if to check what the thing should do depending on the state variable. Only if the "if"ses check stuff too often I use constructs like state to program my stuff - and of course if other circumstances demand the use of the state construct.

This is important, and a tidy example of something I was trying to clarify in my own mind. When I first started with LSL, somebody in some scripting group said that a state is effectively syntactic sugar for a global variable. I puzzled over this for a while before I understood what's been stated elsewhere in this thread: usually (aside from handy side-effects) a state change can be emulated by simply making some code conditional on a global variable.

Flipped the other way, though, this is also a way of discovering that a state might be useful: if a nest of if / else code is an extra level deep because of testing a global variable, that global may be a latent, closeted state.

LSL does nothing to optimize if / else conditionals. It doesn't even have a "case" (née "switch"*) construct (and bizarrely evaluates all clauses of a complex condition, no matter what). We also know a sequence of "if" / "elses" will evaluate in order, so "fast" stuff should go first, etc. Some of the ugliest, hardest to comprehend LSL code arises from complex, nested conditionals, and readability can benefit if those get divided into smaller chunks as states can allow.

But not only readability. Performance, too. The modest penalty for jumping to a new state (whatever it is) may be much more than offset if a bunch of conditionals don't have to keep testing the value of some global variable. This can be a big deal especially for timing-sensitive stuff such as responding to flight/ground controls; sure, they could test a global variable each time a control event happens, but that's a whole lot of events and a whole lot of tests that can be replaced by a single state change.

__________________
* Can this possibly be the "logic switches" referred to above? Doesn't seem to fit, but... oh, screw it. Never mind.

  • Like 2
Link to comment
Share on other sites

22 minutes ago, Love Zhaoying said:

I agree, so this puts me in the “get off my lawn” camp! My Pascal goes back to Turbo Pascal. (Great hacks to use memory loading tricks!) I’m pretty sure we also used Borland C before Microsoft, and also Microsoft C++ before it was “Visual”. 

wooo! Object Pascal. Thats pretty grandparently :)

i thought Delphi 5 was pretty elderly when I was first given it. So Object Pascal definitely really elderly, in a kind and caring way :)

i haven't looked at in ages now but am pretty sure that the Lazarus Pascal dev environment is still built with an opensource Object Pascal compiler. The compiler code itself written in Pascal. So it compiles itself. Which is pretty cool

 

Link to comment
Share on other sites

5 minutes ago, Qie Niangao said:

I also agree that states (and state_entry and state_exit) are the closest thing LSL has to an exception processing model of flow control. I'd just note that this model is broader (and maybe older?) than OOP, with for example LISP's throw/catch condition handling available historically independent of different object system variants

thanks for the info Qie :)

my knowledge of languages like LISP as you mention, and FORTRAN like Rolig mentions earlier, is that while I have heard of them and have some idea of how they work, is pretty much exactly zero from a hands-on pov

Link to comment
Share on other sites

12 minutes ago, ellestones said:

wooo! Object Pascal. Thats pretty grandparently :)

i thought Delphi 5 was pretty elderly when I was first given it. So Object Pascal definitely really elderly, in a kind and caring way :)

i haven't looked at in ages now but am pretty sure that the Lazarus Pascal dev environment is still built with an opensource Object Pascal compiler. The compiler code itself written in Pascal. So it compiles itself. Which is pretty cool

 

Turbo Pascal was 10-12 years before Object Pascal! Self compiling is cool.

  • Thanks 1
Link to comment
Share on other sites

My notes are pretty scrappy and for reasons I'll explain I can't repeat these tests, but back when I had an Island, (Pigswillfly), I found the region debug console gave so so much more information about scripts running that I was able to look at my own scripts and try making them more efficient. The notecard I was able to find in my inventory suggested that the increase in used memory when having several states in a script was far greater than putting stuff out into functions and having extra variables to control behaviour in those functions according to what the required behaviour was, and there was no change in script time to achieve the desired results whether or not the script had states or extra functions..

At the time I thought I'd rule the world forever (Duke), and so I didn't save half as much of my working notes as I should have. If anybody here has a full island with access to the debug console, I'd be interested to see what they record the memory usage of a script as when it has one, two, three, four states.

After trying to talk a friend through the region debug consoles I don't think Homesteads offer the same information as full islands.

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

Just a quick thanks to everyone who's contributed usefully to this thread and to @Ichi Rexen for starting it.  My coding experience ended at PL/1 in college (the semester that I decided human languages were easier to master than computer languages :) ).  I (try to) write scripts now just to play around and see what's possible.  I admit that I still find LSL somewhat confusing, probably precisely because I learned to program with only 64kb of RAM and always look for a more efficient way to write the code.

That said, I tend to look at LSL states as modular constructs, similar to BASIC subroutines.  Sometimes it's convenient for clarity to isolate a set of instructions.  You guys use states in ways that never occurred to me.  Thanks for the food for thought.

Edited by SeanMcDonald
Correcting typo
  • Like 2
Link to comment
Share on other sites

2 hours ago, SeanMcDonald said:

I admit that I still find LSL somewhat confusing, probably precisely because I learned to program with only 64kb of RAM and always look for a more efficient way to write the code.

Think of LSL like Arduino-C++, it may be able to do all the fancy OOP stuff but like on microcontrollers you have to stay effective.

  • Like 1
Link to comment
Share on other sites

On ‎12‎/‎18‎/‎2018 at 6:06 PM, Fionalein said:

back to topic:

I was using states when I added a flight mode to Tapple Gao's carriage script for horse avatars. The controls in flight mode were completely different than in ground mode...

I use states in a state machine much more often but usually I have a flag variable called "state" and "if" / "else" if to check what the thing should do depending on the state variable. Only if the "if"ses check stuff too often I use constructs like state to program my stuff - and of course if other circumstances demand the use of the state construct.

Wanted to add a +1 to this. I make a lot of vehicles and unmanned drones of various types, and I've found using different states for different propulsion modes or control modes is the way to go.

  • Like 2
Link to comment
Share on other sites

4 hours ago, Gadget Portal said:

Wanted to add a +1 to this. I make a lot of vehicles and unmanned drones of various types, and I've found using different states for different propulsion modes or control modes is the way to go.

Simple fact is that those who put down others for using additinal states as if it is a some sort of sacrilege are not being helpfull at all. Yes try and get it into the main but when one is learning or the script complex then there is absolutely nothing wrong with jumping to a secondry state. Also some incorrectly refer to integer switches as bool's, they are not. LSL has many library functions with time penalties which completely throw the script flow out of sync on expected behaviour. Learners just want their scripts to run and most have no interest in doing complex coding ever. LL are part of the problem for learners, they have no idea how to explain things in plain English or whatever language used. So the learner is allready confused by trying to understand the LSLwiki.

My scripts run without any issues. Apart from a few pointless repeats one of which Rolig Loon pointed out the other day they do what they are intended to do and that is the whole point of scripts. One script has a memory location search and delete which was put in a second state as a safety measure. It is only used now and again so it does not even need to be in the main state. The main will use the deletion state only when needed and it will not function unless explicitly called to do so. I had enough tail chasing using a single state that i soon realized it was a pointless waste of my time.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1038 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...