These are chat archives for jdubray/sam

Jan 2017
Jean-Jacques Dubray
Jan 12 2017 16:00
@edmulraney Sorry, but I don't see how it's relevant, CSP is a wiring mechanism, say like CRQS
  • Processes are spawned with go, and channels are created with chan. Processes are completely unaware of each other but talk through channels.
  • Use take and put to operate on channels within a process. take gets a value and blocks if one isn't available. put puts a value on a channel and blocks if a process isn't available to take it.
Jean-Jacques Dubray
Jan 12 2017 16:17
You have to distinguish between programming model, wiring and architecture, there is just no other way around. All these protocols are designed to work with any programming model you'd wish to use, e.g. SAM, pure functions, actors, whatever.
In the present case, SAM would sit inside a process and "take" events and "put" state representations.
I spent a large, very large chunck of my career building async programming model (BPEL) and protocols (ebBP).
All I can tell you is that the JavaScript community is on a deadly course because they are trying to think (sync?) everything asynchronous. They are not trying to specify programming models, wiring mechanisms and architectures.
This will end very badly.
Jean-Jacques Dubray
Jan 12 2017 16:24
You simply cannot randomly write code, especially dealing with concurrency, consistency and distribution, and believe that there is a magical recipe that works in any case.
Jean-Jacques Dubray
Jan 12 2017 16:31
After 36 years of programming, I believe that SAM/TLA+ is the right programming model, but you still have to choose your wires and your architecture. I would even argue that it is because something like TLA+ was missing that we have seen vortices form (such as OOP, FP, RFP,...).
Think of things like OOP/CORBA. We started with a programming model in the 90s, inspired by Turing Award winner, Barbara Liskov's work on Abstract Data Types. At the time there were no distributed systems, then we said the wiring mechanism is the programming model (Distributed Objects). That was an absolute failure, so the research community went on and built an incredible amount of smart wiring mechanism (no pun intended).
Now it's the other way around, people are saying look at all these beautiful shiny wires, we don't need no programming model. It will end just like OOP/CORBA, it will be a full disaster. There is simply no other way around. You can't manipulate "state" as you please, you can't wire distributed systems with any kind of wire. All these choices need to be done with purpose.
devin ivy
Jan 12 2017 16:40
@jdubray what do you think of erlang?
Jean-Jacques Dubray
Jan 12 2017 16:54
I don't think very much, actor models don't put an emphasis on application state, they focus on concurrency, I am certain there is a class of problems where that programming model works better. My opinion is that all these choices should be deliberate. You can't just come in and say SAM/TLA+ will work every where. Dr. Lamport simply stated that he sees TLA+ as a common way to reason about State Machine (and application state mutation). After that there are a number of optimizations that you can implement on top of it.
Vincent Jo
Jan 12 2017 17:51
hey JJ, is there an article or something I can read about the distinguishing features of programming model vs. wiring vs. architecture? I do not understand the distinctions fully and I would like to
Jean-Jacques Dubray
Jan 12 2017 17:55
Not that I can think of
Here you can see that CSP is about interprocess communication, things like channels, streams are all about signaling information from one process to the other.
You could also structure your code that way if you absolutely wanted to, you could create module and within your (otherwise synchronous code) you could use take/put to communicate between the modules.
In the case of OOP/CORBA it was exactly the opposite that happened, people infered an interprocess communication model from OOP semantics, they called it "distributed objects". Everyone in the industry fell for it, until people realized it was not working. On paper it looked beautiful! imagine, unified semantics for wiring and programming model.
That's what Cycle.js is doing, they say everything is a stream, look ma, no programming model!
Fred Daoud
Jan 12 2017 18:17
@jdubray so would the correct approach for Cycle.js then be to describe a programming model, and then have streams as one way -- and not the only way -- to wire up and implement the programming model?
Jean-Jacques Dubray
Jan 12 2017 18:38
Yes, absolutely! Cycle.js is a bit like Erlang, they focus on one aspect managing event propagation (inbound and outbound) but they have nothing in between. MobX started there and Michel started to add actions and model because he realized his programming model was too basic (computables + inbout/outbound reactive binding).