Finites State Machine (OT?)

[David Bowler]

[snip]

You have expressed something that I've noticed for a while now. If a
company is in the software business, the programmers are the
superstars, and they tend to be not only talented, but work in a
reward/scorn system that encourages good work. But if the superstars
of an organization are physicists or insurance execs or MDs, the
programmers are (often) just more staff, so aren't as talented or as
rewarded for excellence. EEs are subject to some of the same forces,
but seem to hold up a little better.

Software is now the heart of any technology or information-critical
company, which leaves almost no enterprise out. Management ignores its
programmers at great peril.

One of my customers, a big-science outfit, is "spinning out of
control" because their technical programming staff is so sloppy and
isolated. Another customer, a *big* aerospace conglomerate, has
Corporate Fellows who are programmers. The difference in results is
startling.


So: how do we explain the crap that Microsoft cranks out?

John

I agree. Having been a software engineer all my working life (from mid/early
'80's to present) I have been in a variety of environments, ranging from
'programmer scum' to 'wow, you're amazing' type scenarios.
I'm now working at a place that is focused solely on development - the
programmer is king, and all subsidiary staff are just that, subsidiary.
Mind you, ironically, if it weren't for the excellent management and
marketing staff we have I wouldn't be in this position....

We have a very structured design and modelling phase before each project
which is, I feel, a must.

The point I'm trying to make (albeit rather circular) is that in order for
developers to produce top-notch ( I think the current buzz-word is triple A)
products, we still need a well defined and implemented overall structure to
the company.
Let's face it, a bunch of excellent programmers is not enough to create
effective market penetration.
We'd all end up trying to out-code each other and lose sight of the end
goal, which is, of course, the consumer's satisfaction.

Just my two cents (two pence here in blighty) worth!

Dave Bowler

 

[David Bowler]

Oh, forgot about the Microsoft thing...

Microsoft crank out all their crap because they can.

Their market penetration (that phrase again, sorry) is so complete that most
people expect to use MS products if they buy a PC. By 'most people' I mean
the average consumer who buys a computer for non-development purposes, as
well as hardware aquisition guys at companies that have been 'brought up' on
MS products.

I sit here typing this text on an MS XP machine, not out of choice, but
because it's the only widely utilised OS.

I don't think we (programmers) have much choice in the matter anymore.

[sniff] !!

So: how do we explain the crap that Microsoft cranks out?

John


I agree. Having been a software engineer all my working life (from
mid/early
'80's to present) I have been in a variety of environments, ranging from
'programmer scum' to 'wow, you're amazing' type scenarios.
I'm now working at a place that is focused solely on development - the
programmer is king, and all subsidiary staff are just that, subsidiary.
Mind you, ironically, if it weren't for the excellent management and
marketing staff we have I wouldn't be in this position....

We have a very structured design and modelling phase before each project
which is, I feel, a must.

The point I'm trying to make (albeit rather circular) is that in order for
developers to produce top-notch ( I think the current buzz-word is triple
A)
products, we still need a well defined and implemented overall structure
to
the company.
Let's face it, a bunch of excellent programmers is not enough to create
effective market penetration.
We'd all end up trying to out-code each other and lose sight of the end
goal, which is, of course, the consumer's satisfaction.

Just my two cents (two pence here in blighty) worth!

Dave Bowler

 

[Jeffrey C. Dege]

On Wed, 19 May 2004 07:45:10 -0700, John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:

On 19 May 2004 09:16:22 +0200, Ketil Malde <ketil@ii.uib.no> wrote:

The best control structure is a jump. That's all the CPU does.

The best control structure is recursion, preferably structured as
folds and maps.

Oh, that brings up another rule: if, at any point in your code, you
can't pretty-closely estimate your stack usage, find another line of
work.

If I'm working in an environment where stack is limited, yes. If I'm
writing for a modern VM OS, I don't care.

(OTOH - if I need code that has to run interminably, and be absolutely
bulletproof, I may avoid all stack and all dynamic memory).

--
"Necessity is the mother of invention" is a silly proverb. "Necessity
is the mother of futile dodges" is much nearer the truth.
- Alfred North Whitehead

 

[Jeffrey C. Dege]

On Wed, 19 May 2004 22:17:04 +0100, David Bowler <david_bowler@ntlworld.com> wrote:

The point I'm trying to make (albeit rather circular) is that in order for
developers to produce top-notch ( I think the current buzz-word is triple A)
products, we still need a well defined and implemented overall structure to
the company.
Let's face it, a bunch of excellent programmers is not enough to create
effective market penetration.
We'd all end up trying to out-code each other and lose sight of the end
goal, which is, of course, the consumer's satisfaction.

When I was doing my SE masters, one professor asked the class what they
thought was the most important single software development metric.

My suggestion?

Gross income/programmer hour

--
You'd think that after all this time
I would have dreamed up a really clever .sig!

 

[Rich Grise]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message

So: how do we explain the crap that Microsoft cranks out?

Easy. They haven't got past the garage geek hacker stage.

Or they follow the Larking Programming Model. =:-O

Cheers!
Rich

 

[John Larkin]

On Thu, 20 May 2004 02:47:34 GMT, "Rich Grise" <null@example.net>
wrote:

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message

So: how do we explain the crap that Microsoft cranks out?

Easy. They haven't got past the garage geek hacker stage.

Or they follow the Larking Programming Model. =:-O

Cheers!
Rich

Hardly. They program in proper structured OO C++. And they have
released products with *thousands* of bugs.

Microsoft has convinced most of the world that "all software has
bugs."

John

 

[Lord Garth]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:4d8oa0tlona4hgg0bllhra9pol00anol7r@4ax.com...

On Thu, 20 May 2004 02:47:34 GMT, "Rich Grise" <null@example.net
wrote:

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message

So: how do we explain the crap that Microsoft cranks out?

Easy. They haven't got past the garage geek hacker stage.

Or they follow the Larking Programming Model. =:-O

Cheers!
Rich


Hardly. They program in proper structured OO C++. And they have
released products with *thousands* of bugs.

Microsoft has convinced most of the world that "all software has
bugs."

John

It not a 'bug'!!! It's an undocumented surplus software function! ;-)

 

[John Larkin]

On Thu, 20 May 2004 03:27:16 GMT, "Lord Garth" <LGarth@Tantalus.net>
wrote:

Microsoft has convinced most of the world that "all software has
bugs."

John


It not a 'bug'!!! It's an undocumented surplus software function! ;-)

That's not a memory protection fault, we're just giving it a rest.

John

 

[Terry King]

In article <71Rqc.609$FJ2.453@newsfe6-gui.server.ntli.net>,
david_bowler@ntlworld.com says...

I'm now working at a place that is focused solely on development - the
programmer is king, and all subsidiary staff are just that, subsidiary.

David, this sounds like one of the programming models proposed long ago
by Fred Brooks in his book The Mythical Man Month. He called it the
'Surgical Team' approach: There are lots of support people and special
experts available, but "Only ONE GUY cuts...".

--
Regards, Terry King ...In The Woods In Vermont
terry@terryking.us
Capturing Live Music in Sound and Images
http://www.terryking.us

 

[John Larkin]

On 20 May 2004 01:08:17 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:

On Wed, 19 May 2004 22:17:04 +0100, David Bowler <david_bowler@ntlworld.com> wrote:

The point I'm trying to make (albeit rather circular) is that in order for
developers to produce top-notch ( I think the current buzz-word is triple A)
products, we still need a well defined and implemented overall structure to
the company.
Let's face it, a bunch of excellent programmers is not enough to create
effective market penetration.
We'd all end up trying to out-code each other and lose sight of the end
goal, which is, of course, the consumer's satisfaction.

When I was doing my SE masters, one professor asked the class what they
thought was the most important single software development metric.

My suggestion?

Gross income/programmer hour

I have a friend who (almost) got a PhD in CS from UCLA (whew, lots of
acronyms!) He said that the only time assembly language was mentioned
was in a course on the history of computing. He attended UCLA in the
midst of the Pascal craze. I guess Pascal will join assembly in the
history class.

John

 

[Jeffrey C. Dege]

On Thu, 20 May 2004 09:53:15 -0700, John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:

I have a friend who (almost) got a PhD in CS from UCLA (whew, lots of
acronyms!) He said that the only time assembly language was mentioned
was in a course on the history of computing. He attended UCLA in the
midst of the Pascal craze. I guess Pascal will join assembly in the
history class.

I didn't have any classes in assembly - but I had two classes that used
assembly - one on the MC68000 and the other on the CDC-6600 (talk about
computer archeology - word-addressed, 1's complement, no stack).

And I had one class where we wrote an assembler for a hypothetical
computer for which we had designed the instruction set and built an
emulator.

--
FORTRAN, "the infantile disorder", by now nearly 20 years old, is hopelessly
inadequate for whatever computer application you have in mind today: it is
too clumsy, too risky, and too expensive to use.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

 

[John Larkin]

On 20 May 2004 18:23:57 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:


FORTRAN, "the infantile disorder", by now nearly 20 years old, is
hopelessly inadequate for whatever computer application you have in
mind today: it is too clumsy, too risky, and too expensive to use.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5



Googling "Edsger W. Dijkstra" turns up an interesting set of stuff. He
seems to have been a character. He was in vogue 20 or 30 years ago,
but K&R pretty well demolished his school of thought. There's no need
to prove software correct if everyone agrees that it can't be.

http://laurel.actlab.utexas.edu/~cynbe/muq/muf3_17.html

is one hit. This deserves some more snooping, time permitting. I
wonder what he thought of C?


Meanwhile, I'm testing my (assembly language, realtime,
state-machine-littered) code that controls this NMR gradient
amplifier. It includes two software true-RMS voltmeters! I've got to
release it on Monday, and I don't want any bugs. The natural
inclination, when testing one's own code, is to avoid looking at the
things that you subconsciously know aren't really solid. That trend
must be resisted.

John

 

[Richard Lamb]

"Jeffrey C. Dege" wrote:

On Wed, 19 May 2004 07:45:10 -0700, John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:
On 19 May 2004 09:16:22 +0200, Ketil Malde <ketil@ii.uib.no> wrote:

The best control structure is a jump. That's all the CPU does.

The best control structure is recursion, preferably structured as
folds and maps.

Oh, that brings up another rule: if, at any point in your code, you
can't pretty-closely estimate your stack usage, find another line of
work.

If I'm working in an environment where stack is limited, yes. If I'm
writing for a modern VM OS, I don't care.

(OTOH - if I need code that has to run interminably, and be absolutely
bulletproof, I may avoid all stack and all dynamic memory).

Sounds like you been there - learnt that.

--
"Necessity is the mother of invention" is a silly proverb. "Necessity
is the mother of futile dodges" is much nearer the truth.
- Alfred North Whitehead

 

[Tom Gardner]

"Richard Henry" <rphenry@home.com> wrote in
news:yqRoc.29065$fE.19074@fed1read02:

"Del Cecchi" <cecchinospam@us.ibm.com> wrote in message
news:2gi5u4F359r3U1@uni-berlin.de...

"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
Sorry if this is off topic but I have another question to help with
the revision for my exam (it's tomorrow).

Why would a finite state machine be an appropriate method of
implementing
the control logic of a drinks vending machine?


Another trick question. These days it isn't an appropriate way. The
appropriate way is with an embedded microprocessor. Finite state
machines only made sense when microprocessors were too expensive.

I always implemented finite state machines in software on
microprocessors.

I've owned one made using hydraulic logic: my automatic gearbox.
And I know of others that are based on gas at 2000-4000 psi,
on unmanned offshore oil rigs.

There are *many* technologies that are used for implementing
FSMs

--
Tom Gardner
Mobile Payments,
LogicaCMG Wireless Networks
_____________________________
LogicaCMG
2420 The Quadrant
Aztec West
Bristol BS32 4LD
United Kingdom

T: +44 (0) 117 901 7896 (direct)

 

[Peter Dickerson]

"Terry Given" <the_domes@xtra.co.nz> wrote in message
news:FSZoc.5006$XI4.180423@news.xtra.co.nz...

"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
Sorry if this is off topic but I have another question to help with the
revision for my exam (it's tomorrow).

Why would a finite state machine be an appropriate method of
implementing
the control logic of a drinks vending machine?



The answer to your question is simple - because it can be made to work.

IME, programmers who dont understand state machines are talentless fools,
who tend to write lousy code. Alas, they can usually draw pretty GUIs so
people keep hiring them *sigh*

Terry

Surely most GUIs are FSMs, where the state transitions are usually called
messages.

Peter

 

[Jeffrey C. Dege]

On Fri, 21 May 2004 10:01:45 +0100, Peter Dickerson <first{dot}surname@ukonline.co.uk> wrote:

"Terry Given" <the_domes@xtra.co.nz> wrote in message
news:FSZoc.5006$XI4.180423@news.xtra.co.nz...

IME, programmers who dont understand state machines are talentless fools,
who tend to write lousy code. Alas, they can usually draw pretty GUIs so
people keep hiring them *sigh*

Surely most GUIs are FSMs, where the state transitions are usually called
messages.

They are, yes.

That doesn't mean that they're always structured in a way that makes the
states, transitions, and actions clear.

--
[Liberty] is a modest and even humble creed, based on a low opinion of
men's wisdom and capacities and aware that, withing the range for which
we can plan, even the best society will not satisfy all our desires.
It is as remote from perfectionism as it is from the hurry and impatience
of the passionate reformer, whose indignation about particular evils
so often blinds him to the harm and injustice that the realization of
his plans is likely to produce. Ambition, impatience, and hurry are
often admirable in individuals; but they are pernicious if they guide
the power of coercion and if improvement depends on those who, when
authority is conferred on them, assume that in their authority lies
superior wisdom and thus the right to impose their beliefs on others.
I hope our generation may have learned that it has been perfectionism of
one kind or another that has often destroyed whatever degree of decency
societies have achieved. With more limited objectives, more patience,
and more humility, we may in fact advance further and faster than we have
done while under the guidance of "a proud and most presumptive confidence
in the transcendent wisdom of this age, and in its discernment."
- F.A. Hayek, "The Constitution of Liberty"

 

[Jeffrey C. Dege]

On Sat, 22 May 2004 01:27:31 -0700, Terry Given <the_domes@xtra.co.nz> wrote:

A new Zealander built one of the first analogue computers in the UK for
modelling financial markets - it was hydraulic. cute.

OTOH, if it was an analog computer, it wasn't an FSM.

I used to have a front-loading washing machine/dryer. These are all FSMs,
but with N m-pole rotary switches, it has m^n states, ie many, of which only
a very few are decoded. it was left in storage for 3 years while i was in
the states, when I came back the switches had all gone dodgy. alas the door
interlock was state-driven rather than, say, water level sensor driven. In
addition to opening the door and getting inundated with hot water, the
stupid thing also turned the dryer on whilst full of water - i found that
from the power bill! cheaper to replace than repair......and the moral of
the story is, always use all states, even if only to point to the zeroth
state (lots of people get bit by this in electronics with turn-on states of
FFs etc causing the FSM to start in the wrong state....)

If you're doing this in software, a timer-driven event that jumps you
back to the start state, if nothing happens within the timeout period,
is also a good idea.

--
There exists a law, not written down anywhere, but inborn in our hearts;
a law which comes to us not by training or custom or reading but by
derivation and absorption and adoption from nature itself; a law which
has come to us not from theory but from practice, not by instruction but
by natural intuition. I refer to the law which lays it down that, if our
lives are endangered by plots or violence or armed robbers or enemies, any
and every method of protecting ourselves is morally right. When weapons
reduce them to silence, the laws no longer expect one to wait their
pronouncements. For people who decide to wait for these will have to wait
for justice, too - and meanwhile they must suffer injustice first. Indeed,
even the wisdom of a law itself, by sort of tacit implication, permits
self-defense, because it is not actually forbidden to kill; what it
does, instead, is to forbid the bearing of a weapon with the intention
to kill. When, therefore, inquiry passes on the mere question of the
weapon and starts to consider the motive, a man who is used arms in
self-defense is not regard is having carried with a homicidal aim.

--Marcus Tulius Cicero, 106-53 BC

 

[Terry King]

Surely most GUIs are FSMs, where the state transitions are usually called
messages.

Well. Most all modern OS use "messages" as communications between
separate often-independent 'parts of code'.

State transitions within one Finite State Machine MAY be initiated by a
message that is received. Or other internal actions, or time, or
interrupts, etc.

I used to have a couple of diagrams on my wall that showed the HDLC
protocol. One was a state diagram, and the other was a "picket fence"
diagram. Both expressed the same logic.

Most communications protocols are modelled as FSMs that send messages to
each other. Complex systems often have many FSM's that communicate.

Another level of complexity is FSMs that are REENTRANT and can have
multiple concurrent instantiations active. There is a variation of State
Diagram called a Petri Network that can express such machines.

If you don't like the rigor of Finite State Machines, try Chaos.

Speaking of which, I once was responsible for the development of the
architecture of communications between semiconductor tools and factory
control systems at IBM . After years of, uh, um, "Stuff that didn't Work
Quite a Bit", (There, wasn't that polite??), I tried to lead, cajole,
enforce tool designers from many companies to document the portion of
their tool that communicated with the factory as one or more State
Diagrams. It was pretty scarey how many manufacturer's software guys were
clueless about such a dumb IBM idea. But it did confirm our suspicion
that several tools had software that was some kind of 'infinite state
machine', which guaranteed that no-one could know WHAT state it was in,
fairly often, and it would have to be rebooted as the only recovery
solution.

In a long, contentious School Board meeting about "The Teacher Evaluation
Process", I finally grumbled and got up and started drawing a diagram on
a whiteboard. It only had about 8 circles on it, and some arrows. I
walked them through it. We made a change. "Wow", said the Chairman,
"That's the first time I understood that".

A FSM, of course.

--
Regards, Terry King ...In The Woods In Vermont
terry@terryking.us
Capturing Live Music in Sound and Images
http://www.terryking.us

 

[John Larkin]

On Fri, 21 May 2004 02:36:05 GMT, Richard Lamb <n6228l@earthlink.net>
wrote:

"Jeffrey C. Dege" wrote:

(OTOH - if I need code that has to run interminably, and be absolutely
bulletproof, I may avoid all stack and all dynamic memory).



Sounds like you been there - learnt that.

On a good CPU, with lots of registers, you can generally write a
fairly complex embedded program without using stack for anything but
interrupt context saves and subroutine return addresses. I've written
actually-useful programs that use no stack at all. I wrote one PDP-11
program - a boot loader - that used no stack and no memory, just
registers.

John

"Necessity is the mother of invention" is a silly proverb. "Necessity
is the mother of futile dodges" is much nearer the truth.
- Alfred North Whitehead

"Laziness is the mother of invention."

 

[Toon Moene]

Jeffrey C. Dege wrote:

In his sig:

When, therefore, inquiry passes on the mere question of the
weapon and starts to consider the motive, a man who is used arms in
self-defense is not regard is having carried with a homicidal aim.
^^^^^^^^^^^^^

allegly from Marcus Tulius Cicero.

Could you please produce the original Latin - this doesn't parse (as an
English sentence).

Thanks,

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)