These are chat archives for jdubray/sam

5th
Aug 2017
Jean-Jacques Dubray
@jdubray
Aug 05 2017 03:12
very interesting arguments on "pc" (program counter) https://youtu.be/SXt3-iZpQQc?t=5686 (the video should start at 1:35min or so)
I think he is talking about Erik Meijer...
Slađan Ristić
@sladiri
Aug 05 2017 11:40
@jdubray Thanks, you mean when he talks about someone who thinks that the PC is not abstract enought, and "wrong"? :) Maybe
In my "SAM container library", I have yet to use a queue for actions (so I have not implemented the feature). Of course there are situations, where it may be required. I do not like this because the triggering of the action looks random to me. If you call an action asynchronously, you do not know the state-representation at the time the action will be processed (in the future).
For me the value of SAM is that the model is blocking while it is processing a step (+ NAP). That is the PC to me, and you throw it away otherwise, i.e. you have the usual concurrency semantics. But again, sometimes you cannot avoid concurrency. This is all old stuff, but for me it is nice to be able to think about it like that. :)
Slađan Ristić
@sladiri
Aug 05 2017 11:49
One thing I did implement (but have not used yet), is what JJ described as compound actions. So in NAP, if you want, you can specify a set of actions, but those will be executed in parallel, and their proposals merged into a single one.
Jean-Jacques Dubray
@jdubray
Aug 05 2017 13:18
@sladiri yes, I think a lot of the modern programming languages have tried to abstract the notion of "where" the program currently is. I am not suggesting to return to punch cards, but we might have got way ahead of ourselves when we started to create all these abstractions and apply them to computation.
Jean-Jacques Dubray
@jdubray
Aug 05 2017 13:37
@sladiri "I do not like this because the triggering of the action looks random to me" I am with you. I don't have a final answer, but at least what's comforting to me is that the synchronization mechanism is rather trivial.
if needed.

those will be executed in parallel, and their proposals merged into a single one

yes, that's the way to do it.

Slađan Ristić
@sladiri
Aug 05 2017 13:49

I don't have a final answer, but at least what's comforting to me is that the synchronization mechanism is rather trivial.

True, I have accepted that this is just the nature of concurrency, and that you have apply it with care. Similar to what eventual consistent databases give you. And there you can define application synchronisation points too, via stronger consistency.

So I can see where the abstract functional mindset comes from, where you want to hide the PC by default, to let the compiler give you performance gains. I find that for a UI the default should be the "sequential" approach, since humans interact with it. In UX I saw that such "sequential" UIs help guide the user, so they do not have to keep the application semantics in their heads all the time. This is what I found interesting about Domain Driven design.

Jean-Jacques Dubray
@jdubray
Aug 05 2017 14:42
@sladiri I think the rationale is that it's just too hard to think in terms of "steps" for everything. Just like Reactive programming (say MobX). Yes, it works within some limited context, but even MobX had to go to a State Tree, the reactive part itself could not handle application state mutation.

@sladiri just to be clear:

But again, sometimes you cannot avoid concurrency.

the idea behind using the bakery algorithm is actually to avoid using it when it will be difficult to reason about, i.e. in the model. The model MUST-BE synchronized. So you have only two choices:

  • you limit yourself to a pure function (Redux)
  • you use a synchronization mechanism (such as the bakery algorithm) to allow concurrency to happen everywhere else, except in the model

I like option 2 better!

Jean-Jacques Dubray
@jdubray
Aug 05 2017 14:55
Option 2 gives you the ablity to make synchronized asynchronous (API) calls.
Jean-Jacques Dubray
@jdubray
Aug 05 2017 16:10
I guess the fundamental teaching from Dr. Lamport's work, every kind of computation is a state machine where from a State you take a step and you reach a new State (S1 -> Step -> S2), but you have to be extremely precise as to what is a Step. We can use variants as long as we understand the limitation of the type of step we choose.
Jean-Jacques Dubray
@jdubray
Aug 05 2017 18:13
The kinds of State Machines he is talking about are not a state machines in the sense of a Petri Net. Petri Nets use a specific kind of step.
Slađan Ristić
@sladiri
Aug 05 2017 19:31

I just stated the obivous in my comment, that concurrent systems are just more complicated than non-concurrent ones. :) So if you can avoid distribution, you should. Maybe I am not seeing the bigger picture yet, but I see SAM as a good pattern to design a UI, and that you should avoid concurrency for the UI for a good UX anyway. If the model or actions use concurrency "behind the scenes", that is fine, because it is invisible.

I do not know Petri nets, other from a comment from Carl Hewitt, where he explains that they are not physical, that there have to occur things simultaneously in different locations.

Slađan Ristić
@sladiri
Aug 05 2017 20:39
And by "SAM is good for the UI", I meant the sequential, non-concurrent way should be a good fit. If I understand correctly, you can use the bakery algorithm in the background or server side, where there is no UI.