it surprises me how often engineers confuse states with actions

i think this is the fundamental reification behind procedural statemess
and this mistake infects a lot of great projects with entropising debate

this error is the type of complexity growing belief that changes a simple state transition

o -------> o

to clever decompositions into state sequences

o -------> o -------> o -------> o -------> o -------> o

these clever motherfuckers see their steps and think
commit! commit!
bravely commiting each step a state transition
to databases
persistent files
and external protocols
marching along confidently

but the event handlers at each stage are not really considered
because it is still conceptually the handling of one event
so the alternative paths
(which have now multiplied with every added state)
are mentally excluded

In article news.veawb.coop>,
galathaea veawb.coop> wrote:

[...]

How about an example for the short bus?

in many ways
it's a law of efficient programming

as your state machine handles events
event handlers are tied to current state

that is from the definition

so minimising states helps minimise
handlers needing implementation

but it has many other interesting results

look at get requests
(accessor events)

one consistent problem i have seen
from young new hires
is this desire to put local scope data
in the member state of it's object

as a law
this can all be formalised in computational semantics

in fact
it has

the classical correspondence morphisms
between denotational and operational semantics
necessarily obey this law

that is the heart of the correspondence between behavior and state

also
when reasoning about agents
it is common to use a language of behaviors
but when reasoning in epistemic or belief logics
the common language is often one of states of affairs

agency logics that take advantage of the is_omorphism
can therefore be fully reflective reasoning systems

this type of reflection is needed
for instance
in belief revision logics
and learning theory