These are chat archives for jdubray/sam

2nd
Mar 2016
Maas-Maarten Zeeman
@mmzeeman
Mar 02 2016 09:24
@formido As an erlang programmer I really like SAM, but things still look very bleak compared to how Erlang manages state. Javascript's concurrency model is just badly broken IMHO, but I still have to deal with that every day.
Jean-Jacques Dubray
@jdubray
Mar 02 2016 09:34
it's hard to compare the two, no?
Maas-Maarten Zeeman
@mmzeeman
Mar 02 2016 09:34
Now with erlang you put state in small processes.
Processes receive messages with a selective receive and manage their own state. No state is shared.
Maas-Maarten Zeeman
@mmzeeman
Mar 02 2016 09:40
This works very nicely. It feels like a huge step backwards when I have to program in js with async things with shared data-structures and callbacks all over the place. That is why sam probably works so nice in js.
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:09
@jdubray in one blog post you say "I understand that there is a confusion in Software Engineering as to what state is (most software engineers would define state as the snapshot of a type instance), but that definition would be independent of the transitions into and out of that state. "
could you give an example which demonstrates this, where the snapshot is not enough but the transitions are also required?
" Yes, indeed, the ultimate result of the action will be to increment a counter, but does that define a state? It's a bit like saying the state of an electron is solely defined by the energy it took to reach that state. Not quite. " this analogy seems slightly off, i'd say the state is defined by the energy it has in that state (type snapshot, values it has at the moment of being in the state)
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:17
There is actually no exception, every object (digital or physical) has transitions, thinking that you can arbitrarily change the property values of a system is like thinking you can start a car, when the battery is flat (assuming you can't push it).
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:19
those are preconditions which define if a next action is possible
but if the clock says it's 11am now, does it matter which transitions happened before?
the state is entirely captured with the hr=11 variable
if the engine is started, i can press the pedal. doesn't matter how it got there (key, jumper cables, ...)
guess in some scenarios it is important, but i fail to see why it's in general important
"States are specific entities (uniquely identified by a label, not properties): states are not variable assignments, though they can be reduced to it." -> is it correct to say states can be defined with some particular variable assignments, but not all variable assignments are states? aren't you just picking out some states which are more meaningful/important from the business point of view, among all possible states? here's an analogy: you're editing a file which is version controlled, and at some point you commit. Dr Lamport calls all individual edits different states (few lines removed, some new inserted.. some words capitalised), where you argue it's only the commit - all those edits taken together?
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:23
be careful, nap is for automatic action.
state machines have no memory whatsoever
so what happened before is irrelevant to the current state
brusand
@brusand
Mar 02 2016 10:23
to my point of view , state is a functional interpretation of a variable value
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:23
that's what I believe makes them so valuable
yes, I would agree with that, that's how SAM is built
but, that function is information
the model alone is not enough
the way I see it is that a particular state is defined by a range of values
state.started = (rpm>0) && (rpm<RPM_MAX)
As I mentioned, Dr. Lamport does not consider "control state" to be a TLA+ semantic, that being said, he systematically uses the variable "pc" (program counter) to refer to the control state value
At the same time he says you cannot ignore the semantics of state machines. This is not incompatible
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:28
but isnt' that another case of reducing state to types?
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:28
in any way
That's my point when I talk about STAR (State, Type, Action, Relationship)
star
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:31
where did you first write about star? I've gone thru last 6yrs of your blog posts and hink it was one from 2015?
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:31
I started in 2013, in a slightly different context
I was doing patent analyses until I realized that the language of patent claims is structured along the lines of STAR (systems and methods)
Then I realized that I could create an abstract definition of problem statements from STAR:
a problem is either:
  • a missing transition between a low value state and a high value state
  • an unwanted transition between a high value state to a low value state
From there you can rewrite entirely the way we think about system requirements / user stories
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:35
think i saw some of that in the agile post
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:35
you realize that the way we specify requirements is completely backwards, because requirements are expressed from the solution point of view (action), when in reality they should be expressed from the problem point of view (missing transition)
yes
So IMHO, STAR has profound implications in the way we thinking about systems and we engage in system construction
Imagine, STAR is a conceptual framework that stretches from problem definition, to solution specification to programming / implementation
this is unheard of
That's why I try to insist that we should be careful in reifying (control) "state" as a property of a type
I believe State has a much more profound signification
Humans are physical beings, they think what they see: actions and things, this is why pretty much every conceptual framework is biased toward A+T. Yet innovation happens only in S+R ...
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:41
We cannot "see" the relationship between the earth and the glass of water. I cannot see if you are thirsty.
We always discover new possible outcomes and new relationships.
Milan Simonovic
@mbsimonovic
Mar 02 2016 10:44
hm, sounds like that implies that state is a human invented "concept", a label we use to put on some aspect of physical reality so we can talk/reason about it? (the commit in the previous analogy)
Jean-Jacques Dubray
@jdubray
Mar 02 2016 10:45
well, not quite, it's just invisible to the eye, so I am not sure it qualifies as "invented"
states are very real
It's a bit like in Physics you have Force, Light, Mass and Energy. These four concepts are irreducible, yet intimately connected. You can't say that Force and Energy were invented because we can't see them.
Maas-Maarten Zeeman
@mmzeeman
Mar 02 2016 10:49
I highly recommend this book for people who design and implement interactive systems: https://mitpress.mit.edu/books/press. State machines all over the place.
Milan Simonovic
@mbsimonovic
Mar 02 2016 11:27
are you trying to say that states should be abstracted away from variables as far as possible, for example, for a glass of water the states should be 'empty, partially filled, full', and not the volume in milli-liters, 12ml in a 20ml cup (a clock is either ticking or stopped, not 10:15am, 10:16am...)? a computation built on top of the state machine defined like this would be more robust - resilient to some kind of changes (cup size for example)
Jean-Jacques Dubray
@jdubray
Mar 02 2016 11:37
Take the example of "ticking" (or counting) how do you define/reify "ticking" as property values? yet in the state ticking, you have an automatic action which is increment (or decrement).
that would tend to show that state is something separate from type and closely related to actions

a computation built on top of the state machine defined like this would be more robust - resilient to some kind of changes (cup size for example)

yes, again, it tends to show that state is independent of type

when you look at the die hard problem you see how state machines compute: http://www.ebpml.org/blog15/2015/01/tla-the-die-hard-problem/
and you see also how the same state machine works with a different type instance
Milan Simonovic
@mbsimonovic
Mar 02 2016 11:51
read the post, got the cup/jug of water example from there
Michael Terry
@formido
Mar 02 2016 19:25
@mmzeeman Oh sure, javascript's, and by extension node's, callback spaghetti is so unappealing after erlang
I'm intrigued by the idea of using nap() like a process mailbox
and even if you don't got as formal as gen_fsm, gen_server's are basically state machine's with a bit less ceremony
so there are some nice parallels in SAM, to me
Milan Simonovic
@mbsimonovic
Mar 02 2016 21:07
@jdubray regarding the rocket launcher example, you defined 5 states: [ready, counting, launched, aborted, end], so how would you name the value of the counter at any point in time? same question but for a computer, say the states are [powered off, running, sleeping, rebooting...], how would you call the contents of it's memory and all CPU registers at any point in time? That's also some kind of a state right?
variable values could be called states and conceptual states [ready, counting, ...] would be control states then?
Milan Simonovic
@mbsimonovic
Mar 02 2016 21:13
when we say a car engine is started, that's just a label, the physical reality is described by some mundane properties (amount of fuel and air injected, rpm, ...)
Milan Simonovic
@mbsimonovic
Mar 02 2016 21:44
@mmzeeman you sure there's a book called "State machines all over the place"? mitpress_search/State machines
Gunar C. Gessner
@gunar
Mar 02 2016 22:08
Michael Terry
@formido
Mar 02 2016 22:09
"State machines all over the place" was a comment, I think, and in particular a comment about the content of the book he linked to: "Press on"
Milan Simonovic
@mbsimonovic
Mar 02 2016 22:18
👍
Jean-Jacques Dubray
@jdubray
Mar 02 2016 23:04
@mbsimonovic yes, I appreciate that in English people people call state what I call a model (SAM) or a type (STAR).
Being both French and a modeler, the state (as in state machine) refers to something different than a list of property values.
So I prefer using state for anything that relates to state machines, and model (of the system) or type for the list of property values.
Sorry I know it's confusing but it is even more confusing to call something state when it is not aligned with state machines.
Jean-Jacques Dubray
@jdubray
Mar 02 2016 23:10
States are defined by ranges, I.e a formula/function. They are not just a label.
In the rocket example I use a label for launch for instance, but in reality the rocket goes through many "states" before it becomes launched, and then the "state" is defined by still a range of values (velocity, fuel level, direction, ...)