These are chat archives for jdubray/sam

12th
Nov 2017
ford
@foxaal
Nov 12 2017 00:12
Thanks for the link to beaker. I need to get out more :) OK, so on SAM, the model is never "dirty" -- that would be forcing a "state" onto the model -- rather, in SAM, state is function of the model as the model exists, end of conversation. state.rep() is triggered by the model's acceptance of a mutation. Yes?
Jean-Jacques Dubray
@jdubray
Nov 12 2017 00:36
yes correct, the state (representation) is responsible for making the model available to the rest of the world. The important concept is the concept of "step". The model property values advance in steps (which you could count if needed). If needed you can keep track of which step number an action instance relates to. That is the goal of the SAM-SAFE microcontainer. However you don't always need to keep track of the step number.
Holger Winkelmann
@hwinkel
Nov 12 2017 09:29
@jdubray Just read one of your article and quickly reminds me, as having a good old Erlang shop, about the UBF-a -b -c Contract definition. These days they have defined allowed actions based on given state.
look at ubf-b
most of this things are forgotten this days in quick and dirty synchron, intent less, REST Requests
Paolo Furini
@pfurini
Nov 12 2017 10:17
If not forced to use other tech stacks for a living, I'd be an elixir programmer.. and regarding lessons learned and then forgotten, it is one of the dark spots of how "memes" work 😉
Holger Winkelmann
@hwinkel
Nov 12 2017 10:19
;-)
I don't care about a special tech stack, i's just interesting that different people have similar ideas about fomalizing a Problem. And the last years was a trend to avoid any state in systems, or define them as somebody else problem. It's so easy. But in reality you can't avoid state, you can limit state, you can manage state, you can define some principles how to work with state. But you can't avoid it and there is no magic library takes care of all state changes for you. just my 2ct.
Jean-Jacques Dubray
@jdubray
Nov 12 2017 16:01
@hwinkel yes, I believe the industry has gone overboard on denying proper state management was the keystone of software engineering. How else could it be?
Jean-Jacques Dubray
@jdubray
Nov 12 2017 16:17
@hwinkel Finite State Machines can definitely used to describe the behavior of a (distributed) system to an observer (hence it works well for a contract), but IMHO the exectution semantics of a FSM are no easy to deal with. They may even be plain wrong. TLA+ cannot be described in terms of FSM. One of the key implications of proper state management is the ability to express temporal logic, and as such we need to distinguish from the structure of a type from the temporal evolution of the property values. I don't know any programming language which has temporal logic constructs. I'd be happy if someone could show me one.
Paolo Furini
@pfurini
Nov 12 2017 23:39
some real-world usage of golang (very useful indeed): https://github.com/containous/traefik