uranther
SAM is a new reactive/functional pattern that simplifies Front-End architectures by clearly separating the business logic from the view and, in particular, strictly decoupling back-end APIs from the Front-End. SAM is technology independent and as such can be used to build Web Apps or Native Apps. It is also protocol independent and can be implemented over HTTP, WebSockets…
Creator: @jdubray
Gitter chat: https://gitter.im/jdubray/sam
SAM is a pattern that aims at replacing the MVC pattern. If you are already familiar with MVC, you should be able to make an easy transition to SAM.
There are two main differences between MVC and SAM. First, SAM is reactive, while MVC is generally implemented in an interactive way. Some attempts have been made at implementing it in a reactive way, however, SAM is not just a reactive implementation of MVC. Second, SAM introduces the concept of State as a mechanism to further decouple the View from the Model and treats the view merely as a “State Representation”.
Articles
Examples
- sam-tic-tac-toe
- SAM Lambda — SAM Lambda is a boiler plate project that implements the SAM pattern in AWS Lambda using DynamoDB to manage application/session state
Temporal logic of actions (TLA)
Articles
-
Temporal logic of actions (TLA) is a logic developed by Leslie Lamport, which combines temporal logic with a logic of actions. It is used to describe behaviours of concurrent systems.
-
… is a formal specification language developed by Leslie Lamport. It is used to design, model, document, and verify concurrent systems. TLA+ has been described as exhaustively-testable pseudocode and blueprints for software systems.
TLA+ is based on the idea that the best way to describe things formally is with simple mathematics, and that a specification language should contain as little as possible beyond what is needed to write simple mathematics precisely. TLA+ is especially well suited for writing high-level specifications of concurrent and distributed systems.
INDIRECT
Presentations
Academic Papers
See The Writings of Leslie Lamport for a full list of publications from this researcher.
“Programming languages provide no well-defined notion of a program step”
“State machines provide a framework for much of computer science. They
can be described and manipulated with ordinary, everyday mathematics”
- Model Checking TLA+ Specifications (1999)
- Temporal logic of actions (1994)
- Specifying Concurrent Program Modules (1983)
- ‘Sometime’ is Sometimes ‘Not Never’ (1980)
- A New Approach to Proving the Correctness of Multiprocess Programs (1979)
- The Implementation of Reliable Distributed Multiprocess Systems (1978)
- Proving the Correctness of Multiprocess Programs (1977)
Books
- Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers
- TLA+2: A Preliminary Guide
- Specifying Concurrent Systems with TLA+
Related architectures
Trending in Wikis
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming











Showing Posts 11 to 20- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jdubray
Here is the link to the AWS Lambda sample:
gregvaughn
@jdubray I just read your infoq article and I must admit I’m a bit puzzled. I’m trying to find a summary of what makes SAM distinct. My poor old brain is getting bogged down in the details (I wrote my first web app in '93). This sounds more flippant than I intend, but my best summary at the moment is that “server API design is so much easier if front-end developers use a Monad-based approach.” Is that even remotely accurate? Perhaps I misread all those details of the distinction between actions, model updates, and side-effects? If I’m even remotely accurate, then I question the practicality of the approach.
jdubray
1993? my first commercial product was in 1980… on an Apple ][
To answer your question I would have to pretend I understand what a monad is, which I won’t.
Really all I am trying to say in the article is:
From M → V
V = f(M) works great (thank you React)
from V → M
use TLA+ semantics: propose (action), accept (model) and learn (state)
From what I can tell all the other alternatives do not make that distinction (Elm, Redux, Cycle, MobX, Vue and now VueX)… and they start fighting problems that you generally do not encounter with SAM.
One argument I always hear about the pure Reactive Functional approach and separating effects from the logic is about testability. That’s until you really understand the math behind “testing”, http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf (the irony here, is that TLA+ makes your system far more testable, but what do I know)
I also see a lot of people thinking that being “reactive” means something other than V = f(M), you have to somehow use RxJS, Observables, Streams and what not. That’s until you need to start dealing with subscriptions and glitches.
SAM (and TLA+) focuses on getting mutation right (propose, accept, learn). Dr. Lamport got a turing award for TLA+ (Temporal Logic of Action), so it can’t be that bad, right? Some quotes from him:
“Programming languages provide no well-defined notion of a program step” (SAM does)
“Computation is a major topic of computer science, and almost every object that computes is naturally viewed as a state machine. Yet computer scientists are so focused on the languages used to describe computation that they are largely unaware that those languages are all describing state machines.” (TLA+ gives SAM enough structure, without the burden of traditional State Machine semantics)
If you have not read this article on Computation and State Machines, it’s may be too difficult to understand where SAM is coming from (http://research.microsoft.com/en-us/um/people/lamport/pubs/state-machine.pdf).
gregvaughn
Thanks! I’m currently working through Lamport’s vector clock paper and I’m adding the state machine one to my reading queue now. I do have concern, for practicality’s sake, that there is not a more concise description though.
jdubray
Please also note that SAM is “my” interpresentation of TLA+ as a programming model. I exchanged several emails with Dr. Lamport last year, as I was laying SAM’s foundation, but by no means he has validated SAM, or SAM would be the only way to translate TLA+ semantics into a programming model.
I can certainly share more specific references inside Dr. Lamport’s book to explain how I created SAM from TLA+.
The key to understand (which most people find unusual) is that TLA+ describes state machines, but not with the semantics we are all accustomed to. I try to explain it here: SAM - State | Action | Model
Then of course the next step is to decide how TLA+ semantics apply to Front-End architectures. The traditional semantics of State Machines (Petri nets) are not a good fit, but TLA+ is very different. That’s why I believe it is applicable.
uranther
*bump*
I just added a bunch of info to the top post, mostly about TLA+.
jdubray
I just would like to add a couple of quotes from Lamport on TLA+
“State machines provide a framework for much of computer science. They
can be described and manipulated with ordinary, everyday mathematics”
and
“Programming languages provide no well-defined notion of a program step”
The semantics of Mathematics and hence TLA+ are quite different from the ones of the familiar Petri Nets, and a lot closer to the way we write code. I believe he has found the most fundamental way to describe state machines.
IMHO, the temporal aspects of TLA+ bring a lot of benefits when compared to observables which seem to be the way the industry is heading. Observables seem to make dealing with temporal aspects harder, in particular when you need to reason about different types of events allowed in a given step.
StefanHoutzager
After reading a bit more from mr. Dubray I must say that I do not like a couple of his ideas and the way he tries to persuade (and hides behind jargon) in a couple of email groups.
He tries to sell the idea of isomorphic javascript. Must ring a bell for elixir devs ;-). I placed some comments below his article: Why I No Longer Use MVC Frameworks - InfoQ.
jdubray
I have published a series of blog posts on Back-End architecture (Services, APIs and Microservices - SAMs) and how the SAM pattern aligns with them). As Stefan’s points out, I believe this is not just a key selling point of the pattern but a must have for a grown up programming model. If all you do is produce a programming model that works well in the browser and think of the back-end as just a bunch of HTTP calls, you would have achieved nothing. You will notice on the right end-end the great simplification isomorphism brings to the table when you can align back-end and front-end.
BTW, I go by “JJ”, no need to use any kind of formality.
StefanHoutzager
I did not point out at all what you are pointing out yourself. Please do not try to reduce me to a stooge. I don’t buy the isomorphic paradigm and I don’t want to spend too much time formulating arguments. So I’ll just copy a link:
https://www.jayway.com/2016/05/23/6-reasons-isomorphic-web-apps-not-silver-bullet-youre-looking/
For me the first reason named in the article is enough. I do not want to be obliged to use node.js and js on the backend.
Edit: this is worth a read also I found Client Challenge