Pushing Hot Buttons - Object State Machines === Threads with goto's
- From: John Carter <john.carter@xxxxxxxxxx>
- Date: Wed, 31 Jan 2007 16:58:52 +1300
On Tue, 30 Jan 2007 18:30:03 +0000, H. S. Lahman wrote:
<Hot Button>
A pet peeve of mine is the resistence one gets from IT people to using
object state machines routinely. The fact is that with interoperability,
networking, multi-tasking, distributed processing, mutli-user systems,
etc., etc. IT is no longer one's grandfather's IT. It is much more like
R-T/E. However, to avoid thinking about asynchronous processing, the
industry is making major investments in layered model infrastructures that
serialize asynchronous processing so CRUD/USER developers can think
serially. The cost of that is outrageous overhead. Then people wonder
why they need to upgrade their desktop to the equivalent of a 1984
mainframe just to run a spread*** that ran fine on a TRS-80 in 1984.
</Hot Button>
At risk of appearing trollish, I'm going to push that Hot Button.
Ah well, no. I am trolling, (just in pure friendly fun), but I will say in
my defence that the content of what I'm about to say is mathematically
absolute correct, sometimes even useful and may give people pause to think.
Mathematically speaking every program with a state machine is equivalent
to and may be replaced by another containing an extra thread and no
state machine. (Conversely every program containing a thread may be
replaced by one contain one less thread an a state machine)
The state transitions then appear either as sequences of statements and
"goto"s.
<GentlyInformativeTrollOn>
The desire for state machines is thus a sublimation of the desire to
roll one's own schedulers and to subvert Djikstra's awkward ban of
Harmful Spaghetti Goto code.
</GentlyInformativeTrollOn>
Well, to stop being trollish there are advantages and disadvantages to
both sides. In the embedded domain extra threads mean extra
fat chunks of Ram lost to stacks and chunks of CPU time lost to context
switches. In all domains state machines without event queues can more
easily represent precise intermeshing cog like scheduling.
But my Troll Nature's basic point is valid, unless care and thought is
taken, a state machine is just a reversion to pre-Djikstra goto spaghetti
code with a homebrew RTOS and all the harm that implies.
--
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx
New Zealand
.
- Follow-Ups:
- Re: Pushing Hot Buttons - Object State Machines === Threads with goto's
- From: H. S. Lahman
- Re: Pushing Hot Buttons - Object State Machines === Threads with goto's
- References:
- Client/Service relationships & Flow of Requirements.
- From: John Carter
- Re: Client/Service relationships & Flow of Requirements.
- From: H. S. Lahman
- Re: Client/Service relationships & Flow of Requirements.
- From: John Carter
- Re: Client/Service relationships & Flow of Requirements.
- From: H. S. Lahman
- Client/Service relationships & Flow of Requirements.
- Prev by Date: Re: Client/Service relationships & Flow of Requirements.
- Next by Date: Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Previous by thread: Re: Client/Service relationships & Flow of Requirements.
- Next by thread: Re: Pushing Hot Buttons - Object State Machines === Threads with goto's
- Index(es):