These are chat archives for jdubray/sam

Jun 2016
Fred Daoud
Jun 06 2016 00:07
good points @devinivy
Jean-Jacques Dubray
Jun 06 2016 00:28

The overall problem is even ordering

I meant "event" ordering

i see its value in other environments

again, I am always talking in the context of "Front-End", I don't dispute the fact that functional programming and immutability have value, but I can safely say (and based on the kinds of issues React, Cycle, ... struggle with) that they are critically missing "State".

I find it fascinating to see that's the first thing Fred took away.
Fred Daoud
Jun 06 2016 00:34
@jdubray maybe I have been infected ;)
Jean-Jacques Dubray
Jun 06 2016 00:44
well, this is clearly how the industry is thinking about it.

Some days you just want to cry:

We'll never get this right

Jean-Jacques Dubray
Jun 06 2016 00:50
State machines can be described and manipulated with ordinary, everyday mathematics—
that is, with sets, functions, and simple logic.
State machines therefore provide a uniform way to describe computation with simple mathematics.
Fred Daoud
Jun 06 2016 00:59
What is the difference between SAM and STAR?
Jean-Jacques Dubray
Jun 06 2016 01:03
STAR is a conceptual framework (State, Type, Action, Relationship). Every bit of knowledge can projected/decomposed into a combination of States, Types, Actions and Relationships.
I started to use STAR to model business strategies (BOLT)
Then the natural progression was to see how STAR would apply to programming models
In December 2014, I learned about TLA+ and that was the missing piece. TLA+ was nearly perfectly aligned with STAR.
So I set out to create a programming model from it, SCM: STAR Component Model
Jean-Jacques Dubray
Jun 06 2016 01:08
And I created SAM at about the same time (June 2015), already connecting it to Flux/React.js
I discovered "STAR" by trying to understand the language of claims in patents.
That language is generally hard to parse for the untrained reader. It's made of english words, but clearly there are more semantics/structure, than plain english. Which makes sense, otherwise how can you decide if some product infringes a patent
It turns out that the structure of the claims language is very simple (Systems and Methods) -> STAR
Systems = Types/Things + Relationships
Methods = States + Actions
Once you understand that, you can write/read patents like a pro. I have no checked, but I would bet that any kind of legal language has more or less a similar structure.
Jean-Jacques Dubray
Jun 06 2016 01:15
Imagine if you could write Users Stories in a way that:
  • clearly delineate Problem from Solution
  • structure them as a graph (not a hierarchy)
devin ivy
Jun 06 2016 04:50
that would be great. what kind of person can write such user stories? anybody?
Jean-Jacques Dubray
Jun 06 2016 06:23
Jean-Jacques Dubray
Jun 06 2016 06:33
In essence you cannot build a system with a conceptual foundation smaller than STAR, and yet we repeatedly try to do that in Software Engineering all the time, it's systemic. Again, even SQL reifies Entity Relationships as attributes of an Entity, that means that now a structural element of the system is buried in code and developers are free to be "creative" in implementing relationships. It's true of OOP as well. Relationships are reified as properties. Concepts like aggregates or multiplicity are critically missing in the programming model and developers need to constantly think about it.
Do you think that's really efficient?
Stardrive Engineering
Jun 06 2016 07:32
@jdubray Agree with "State Machines are the solution to Front-End architectures, not Functional programming."
Or I would say lead with the right foot, state-machine first then the functional-programming. Just checking in, things are still proceeding here at STARdrive Engineering :smile:
Jean-Jacques Dubray
Jun 06 2016 11:27

lead with the right foot, state-machine first then the functional-programming

yes absolutely, it's not about saying FP or FRP has not value, that would be nonsense.