The thinking about states in the FSM is similar to that in VFP. It is
object-oriented style. The advantage of the FSM is the small size of the
engine to drive it. One doesn't need a full blown OOP like VFP to write an
app. Most of the logic is in arrays holding the state information. Note that
moving from one state to the next also includes the ability to execute an
output function just like in OOP so you need to code the output functions.
Another problem with thinking in VFP is that commercial frameworks are based
on forms so now everything looks like a form. Not all apps require forms
such as the examples I mentioned in my last note.
Nick Geti
----- Original Message -----
From: "Stephen Russell" <[email protected]>
To: "ProFox Email List" <[email protected]>
Sent: Thursday, December 19, 2013 11:46 AM
Subject: Re: Finite State Machine
On Thu, Dec 19, 2013 at 10:32 AM, Dave Crozier <[email protected]>
wrote:
Stephen,
Yes, I believe this model is used in large tax systems as it is to
process
large "queueing" systems. We used it because it is flexible and we used
to
call it "Dynamic Jump-pad" programming used when memory is at a premium
and the coding you start off with in a process isn't necessarily the
coding
you end up with because the code in te State responses actually can
modify
an existing set of response code.
At the time this really opened my eyes on two fronts.
a. The strength and versatility of assembler coding
b. The ability of a "program" to effectively "learn" by modifying itself.
This was necessary because we only had 8K of core in those days and so to
operate efficiently we didn't want to overlay code from disk back into
memory so we dynamically altered code whilst it was in memory.
The project was to write an operating system that supported Point of Sale
Tills as external nodes, each of which was firing transactions back to a
mainframe at any time so the mainframe had to be able to queue the
events/transactions effectively. Using conventional if...else topdown
technology would never have worked and would have become too large
anyway.
We ended up streaming 4 FSM program models together in parallel in order
to process the transactions which effectively did away with the
conventional "polling technique" that most people would have used to
create
a solution. Funnily enough, OOP was only a glimmer in the sky at that
stage
but to all intents and purposes we were using all the OOP techniques in
creating a solution to the problem.
It must have worked as it was only decommissioned 5 years ago after 25
years of operation on the same hardware!!!
-----------------
Awesome.
I bounce back and forth between easy code and workflow code. We have an
asset approval process that s butt ugly in rules that use to be all hard
coded. Now have modules that determine state and only get the rules that
pertain in this situation. It take a bunch of sign-off here to buy
something. # of people required is determined by asset type and cost.
--
Stephen Russell
.
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/14C4AA84D6F94EC69A1D47BB43E4F77A@dual
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
