These are chat archives for jdubray/sam

18th
Feb 2016
Stardrive ENGG
@HighOnDrive
Feb 18 2016 03:45
@mmzeeman Thanks for the Buffer Automata link, echos some of my thinking and process. I like the idea of higher level modes for tools and buffers for any values used by a given tool. Toward the end of the article what they were calling modes reminds me of Rx Observables with the buffers being Rx Operators. Rx is the perfect API for the use case the article presents.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 03:58

@jdubray Cycle.js essentially uses a Intent > Action > Modifier > State > Render top to bottom flow as it's way to traverse through the reactive loop. The way I understand NAP is just that it is similar to Render, which is ultimately a automated reactive output function.

I am interested in how SAM works in the context of Cycle.js and I think that Cycle.js is an excellent place for SAM to prove it's place in how the reactive loop is segmented and executed. Maybe you could go through the excellent Cycle.js course at Egghead.io to bridge the gap and get some solid application of SAM from it. Here is the link to the free lessons:

https://egghead.io/series/cycle-js-fundamentals

Jean-Jacques Dubray
@jdubray
Feb 18 2016 04:00
@foxdonut has published a great sample using Cycle.js, really amazed at how consize the code it, worth investigating http://codepen.io/foxdonut/pen/XXPwRe
@HighOnDrive I watched most of the tutorial, as I mentioned, I like cycle.js and I feel there is a good alignment between our respective goals. From what I can tell, it looks like cycle.js is a reasonable way to implement SAM.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 04:06
Yeah, I'm aware of it. I think what would be more interesting is your own perspective on how SAM and the default Cycle.js flow dovetail. At this point I already know from the Cycle.js demo of the simple earlier SAM launch demo that the Cycle.js community was underwhelned by it. I think a better approach is if you understand Cycle.js yourself and then speak to us in meaningful terms.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 04:13

When you look at the example (inc/dec) we have been discussing:

function main(sources) {
  const decrement$ = sources.DOM
    .select('.decrement').events('click').map(ev => -1);

  const increment$ = sources.DOM
    .select('.increment').events('click').map(ev => +1);

  const action$ = Observable.merge(decrement$, increment$);
  const count$ = action$.startWith(0).scan((x,y) => x+y);

  const vtree$ = count$.map(count =>
    div([
      button('.decrement', 'Decrement'),
      button('.increment', 'Increment'),
      p('Counter: ' + count)
    ])
  );
  return { DOM: vtree$ };
}

One can see that, Cycle.js has

  • actions (in the SAM sense, rather than intents like Redux)
  • actions are properly decoupled from Model mutations
  • View is a function of the model

The only thing missing is the State object, including the nap() function. I believe it would be best if André adds it at the framework level:

run(main, state, drivers);
Stardrive ENGG
@HighOnDrive
Feb 18 2016 04:24

Thanks for the expose.

Also, the following part is what Cycle.js defines as the intent aspect:

  const decrement$ = sources.DOM
    .select('.decrement').events('click').map(ev => -1);

  const increment$ = sources.DOM
    .select('.increment').events('click').map(ev => +1);

I believe I hear you about the missing state object. Due to the excitement over the dynamic power of calculation that Rx has I think that seeing the need for a state object has been hard to come by in Cycle.js.

To Cyclists all state is just calculated on the fly, presto, similar to the buffer automata article. That's all wonderful and Rx is a great way to manage state explosion but there is still a need for actual state. State as in the single atom or something like RethinkDB or even Falcor.

The state object could be added to the framework level but it is easier to add it as a Cycle driver.

Stardrive ENGG
@HighOnDrive
Feb 18 2016 04:31
It is only as Cycle.js enters the stage where it is concerned with building larger real world apps that the state object is beginning to make sense to Cyclists :+1:
Stardrive ENGG
@HighOnDrive
Feb 18 2016 04:36
Things being as they are where do you see the NAP function fitting into Cycle.js? Would it just be a possible response once state has been set by a modifier? In that way it is like a post processing step or like a final stage step?
Jean-Jacques Dubray
@jdubray
Feb 18 2016 05:24
Don't underestimate nap(), it's really difficult to deal with this kind of logic when you factor it improperly
it's the final step in the State function. In Fred's code:
return Rx.Observable.of(initialState)
    .merge(started$)
    .merge(aborted$)
    .merge(counter$)
    .scan((state, update) => {
      const nextState = merge(state, update);
      if (state.status === STARTED && update.counterChange) {
        nextState.counter += update.counterChange;
      }
      if (nextState.counter === 0) {
        nextState.status = LAUNCHED;
      }
      return nextState;
    });
it would triggered as an observable of nextState (sorry I am not too familiar with Rx, so I may be something stupid)
Fred has kind of hard coded the model changes in the State (not great) rather than invoking the corresponding actions.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 05:39
Looks understandable, I agree invoking actions would be best. It's time for some sleep, it has been a busy productive day. Thanks for the insights :smile:
Alex
@whitecolor
Feb 18 2016 09:42
@jdubray state can be represented as a driver no need to introduce another framework entity for it
Jean-Jacques Dubray
@jdubray
Feb 18 2016 11:12
State is logic not effect, state representation is the effect.
Alex
@whitecolor
Feb 18 2016 13:20
@jdubray It depens on what you understand under "state", it may represent something external, but if you look at state changes as at logic, it should be handled inside the main, inital state supplied via driver function
Stardrive ENGG
@HighOnDrive
Feb 18 2016 14:16
The world is talking about MVI and the FRP paradigm, if SAM is the ally we also need to know about it: http://softwareengineeringdaily.com/2016/02/15/reactive-programming-with-matthew-podwysocki/
Michael Solovyov
@msolovyov
Feb 18 2016 15:17
What is making that cycle js example consise is ramda, rx and cycle.dom. It would have been better to see a pure cycle js example to see what the advantages are. Still a worthwhile example because ramda and rx look amazing.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 16:33
How can you "respond to events" when you don't know exactly what state you are in?
Jean-Jacques Dubray
@jdubray
Feb 18 2016 16:46
The problem with MVX paradigms (where X=C,I,...) is that the View is not decoupled enough from the Model. The view is merely the state representation. What is important is to consider the relationship between state, action and model.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 17:17
This message was deleted
This message was deleted
Stardrive ENGG
@HighOnDrive
Feb 18 2016 17:44

Thanks for reminding me about that difference between MVX and SAM, very important. Because I'm a musician I'm reminded of the relationships between scale degrees, where each has a musical function (in what it's momentum or charge is and relationship to the other degrees is).

After much engineering I have finally arrived at a place where my own app architecture is completely state driven. I can see that this might not be where most projects end up due to lack of time and thoroughness or perhaps care.

None the less here is some info on the musical scale and it's degree functions. I'd say state would be the tonic degree/function and define the key signature that the rest of the degrees participate in. Maybe model is the dominant and Cycle's intent is the leading tone?

I'm not proposing a absolute correspondence between scale degrees and reactive loop segmentation and flow, still I am very interested in knowing the complete sequence of segments that make up the reactive flow.

Acronyms of three letters are nice but how do the degrees/segements that SAM highlights and the MVI ones that Cycle highlights string out together the way that scale degree functions do? Maybe there are five or more actual degrees/segments involved, there is also some overlap between them. This is the ultimate question so I'm sending out this message hoping to discover the elusive long lost chord :smile:

Here is that scale info from: http://musictheoryblog.blogspot.ca/2007/01/scale-degrees.html

The names of the Scale Degrees are:

Tonic
Supertonic
Mediant
Subdominant
Dominant
Submediant
Leading Tone

The Scale Degrees have these names for a reason. The names relate to their function and to their position to each other on the scale, for example the Tonic is the primary tone, the Subdominant is below the Dominant, and the Leading Tone "leads" to the Tonic.

Alex
@whitecolor
Feb 18 2016 17:55
Everyting is a stream, state is too, its just a flow of values
Stardrive ENGG
@HighOnDrive
Feb 18 2016 17:56
I thought everything is a vibration, lol
Yes, we are talking streams, I'm interested in charting out the landmarks, stations and degrees/segments along the reactive loop (the reactive version of the super information highway).
Stardrive ENGG
@HighOnDrive
Feb 18 2016 18:02
We are like the early explorers, giving names to the major locations in a new country. Once the names and boundaries are in place the country can navigate, build and prosper.
Alex
@whitecolor
Feb 18 2016 18:03
cycle don't force you to use any concepts like MVI or something like that, in general case you don't need this, in some areas like build UI MVI or something can help to deside how you should split/organize your streams into separate functions.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 18:06
True, which I actually appreciate about Cycle. So, in Cycle MVI is then arbitrary to begin with and the big idea is just dataflow, as in everything is a stream.
In contrast to Cycle then, SAM is saying there is a discreet segmentation to the flow. I'm also discovered this and recognized it as playing an important role.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 18:11
What is needed is an application and interpretation of SAM and however many segmentation degrees it takes within the modern Rx and stream based paradigm. That is the only way for SAM to be relevant, otherwise it will just be streamed out of existence.
There is a proverb about a person without self control being like a city without walls. Which seems to indicate that a stream can easily become a swamp and lead to a whole new type of spaghetti code or even a revolutionary little framework that is still ill equipped to scale and build larger apps with.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 18:37
Sorry to disappoint but "observables are just callbacks" , IOW, what I call "wiring", there are no semantics whatsoever in streams
Stardrive ENGG
@HighOnDrive
Feb 18 2016 18:44
"there are no semantics whatsoever in streams", welcome to hells kitchen, lol
Michael Solovyov
@msolovyov
Feb 18 2016 18:49
Is there a way in js to enforce the restrictions and data flow of sam so that three are no accidents like setting the model in the action etc
Jean-Jacques Dubray
@jdubray
Feb 18 2016 18:51
That's relatively easy to do, you would just create a closure on the model:
function present(data, state) {
       var model = {} ;
       model.present = function(data,state) { ... } ; 
       return model.present ;
}
There are pros / cons to the different wiring strategies
You also have to take into account client/server topologies. Actions can run just about anywhere, even if the model runs on the client.
Michael Solovyov
@msolovyov
Feb 18 2016 18:57
True
Alex
@whitecolor
Feb 18 2016 19:09
@HighOnDrive I agree that cycle din't prove its concept yet at all
Stardrive ENGG
@HighOnDrive
Feb 18 2016 19:57
@whitecolor Joke: If you throw a bunch of streams at the wall, how long will they stick?
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:00
@msolovyov incidentally (and semantically) a closure nothing more than instantiating a class which has a single method... the "wiring" might look a bit different, but semantically this is strictly equivalent. That's why I prefer looking at semantics first and wiring later. Our industry tend to conflate the two and often end up marveling at a piece of wire.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:00
Bit of a Pandora's Box, wild horses not yet harnessed. We have Observables, Observers and Operators and a free for all methodology.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:02
I like the objective of cycle.js which is to separate the logic from the effects (that's semantics), but "observables" have nothing to do with that.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:04
I'm not knocking that freedom, it just has to be applied in a more systematic way. The reactive loop is powerful and certainly there is room to plan it out, for multiple good reasons.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:05
Our industry tend to like Monadic/Cogent paradigms (FP, OO, Actors, Streams... everything is XXX)
Model-Driven-Engineering tend to focus on solving problems with a Polyadic/Anemic foundation.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:06
Interesting
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:06
IMHO, the solution is in the fourth quadrant which no one looks like: polyadic / cogent.
In essence, building a solution is always about creating semantics that make the construction of the solution easier, otherwise we would all be coding in assembly language, there would never been a need for any further abstractions.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:09
Only one I recognize there is Ant. I find data and configuration is important along with well defined states, states at the tool/feature level.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:10
The problem is that programming languages are not polyadic/cogent and we tend to leak their semantics in the solution, not to mention the wiring.
About 3 years ago, I realized that there is a conceptual foundation that's better suited for creating semantics (STAR):
star
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:12
State drives everything, even code :+1:
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:13
well, not so fast
I believe you cannot come up with a simpler conceptual foundation. Happy to be wrong, but as you constrain your semantic foundation further you are forced to reify (for instance State does not exist in OO) other elements into the one you selected and that's when the problems start appearing
because that reification process is only in the head of the developer, no one can see it through the code
The best example is SQL and "relationships", there is (~)nothing in SQL that maps to a relationship. That's quite an achievement if you ask me! Relationships are reified as a property of a type.
Interestingly, TLA+ is the only formalism I found in computer science that maps to STAR relatively well.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:20
What if you had states defined as data and when given states are activated they completely repurpose the reactive loop? So the reactive loop would be configurable via a unique take on injection. The injectables would be abstracted out to function modules.
Makes for a very flexible, extensible, maintainable codebase. Components and drivers are then just adapters to pin things to and not a place to entangle your logic into.
So in such a solution the SAM semantics would be the lights along the IO runway.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:30
"The best example is SQL", yes you might see the data based states as queries, among other things :sparkles:
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:37
Generally, any kind of reification will lead to inefficiencies, unstable code, hard to debug and maintain.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:39
Obviously I'm not waiting for the perfect language or framework, just working with what there is and keeping things clean and on track to what I want to accomplish :smile:
Actualization is easier with the right patterns for sure.
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:44
All I am saying is that a lot of problems show up when you do not align the conceptual foundation of your solution to the problem at hand
Considerations include:
1) monadic/polyadic, anemic/cogent
2) STAR
3) ... (not sure)
You will end up doing a lot of things which have little value if your conceptual foundation is inadequate
I am not saying that in all cases you need a STAR based, polyadic/cogent conceptual foundation
that being said, I prefer talking about SAM, most people would get bored with this kind of discussion. I just want to show that SAM just didn't land on my desk or popped up in my head. I put a lot of thinking into "why we write the code we write"
Jean-Jacques Dubray
@jdubray
Feb 18 2016 20:50
On a personal note, I also prefer focusing on the lowest barrier of entry to SAM, using raw javascript, HTML5 and CSS3 (and a responsive framework like bootstrap). After that people are free to use anything else, SAM is just a pattern.
Stardrive ENGG
@HighOnDrive
Feb 18 2016 20:57
Cool, I just see a synchronous pattern in SAM in relation to how I segment the reactive flow. Cycle has this too and as stream based development comes into it's own the best pattern will be discovered.
Right now it is more or less wide open and simple in it's own right. The mantra is "everything is a stream" and with Observables and Operators I can do anything :fire:
Going to get going on the day here, cheers :smile: