These are chat archives for jdubray/sam

29th
Mar 2017
Jean-Jacques Dubray
@jdubray
Mar 29 2017 00:25

@devinivy about function trees...
So I don't like that aspect:

Both Rxjs and Promises are about execution control, but neither of them have declarative conditional execution paths, you have to write an IF or SWITCH statement. With function tree you are able to diverge the execution down paths just as declaratively as functions. This helps readability.

A "Step" is action/model/state, inevitably function trees will be a spaghetti of actions/mode/state code, you just can't drive software engineering from an action perspective, that is the problem, not the solution

But, I like that one:

Rxjs and Promises are also based on value transformation. That means only the value returned from the previous function is available in the next. This works when you indeed want to transform values, but events in your application are rarely about value transformation, they are about running side effects and going through one of multiple execution paths. And that is where function-tree differs. It embraces the fact that most of what we do in application development is running side effects.

The It embraces the fact that most of what we do in application development is running side effects. is wishful thinking at that point... Function Trees need SAM ...

Jean-Jacques Dubray
@jdubray
Mar 29 2017 13:50
I always thought this was coming: https://kite.com/
Zach Dahl
@schtauffen
Mar 29 2017 14:17
I like to joke that a developers job is 90% googling. kite seems like it would be extremely useful
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:31
+1
it is not a joke, I always claimed to be a google oriented programmer (I guess it shows :-))
Fred Daoud
@foxdonut
Mar 29 2017 14:33
Can't remember the source, but I liked the developer who, when asked in an interview to write so-and-so algorithm (say, quicksort) on a whiteboard (ugh!), drew a box with a search button next to it, then wrote "quicksort algorithm" in the box :D
Zach Dahl
@schtauffen
Mar 29 2017 14:35
I like to call this particular skill "knowledge acquisition"
and that is awesome @foxdonut . I would also consider myself a google oriented programmer @jdubray :)
Fred Daoud
@foxdonut
Mar 29 2017 14:38
It would be more of a skill-testing question to ask the developer to Google how to do so-and-so with LaTeX without ending up on any weird fetish sites ;)
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:41
@foxdonut about "Fractal" Architecture, I have mixed feelings about it. Clearly the component model I sketched for SAM is aligned with that general thinking
But, I believe it is critical to separate the "theme" (components) from the app logic components.
The glue between them being intents that wire events to actions and the state function that translates the model into view component properties.
I don't think it's a good idea to shoehorn view components and app logic components together.
Fred Daoud
@foxdonut
Mar 29 2017 14:44
@jdubray thanks for having a look! Well, I agree with you, but isn't that what is referred to as separating the glue code from the components?
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:45
IMHO, it's kind of a tautology to say that programming is fractal.
devin ivy
@devinivy
Mar 29 2017 14:45
fractal architecture has nice properties, but i'm not convinced it's strictly necessary for today's app-building.
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:45
I don't know many programming models which are not fractal, but then the wrong way to look at it is to say, everything must be fractal.
Especially when you arbitrarily define the boundaries of a component.
devin ivy
@devinivy
Mar 29 2017 14:46
programming models? sure. but i mean the standard redux app is inherently non-fractal.
"single store"
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:47
yes, that's kind of what I mean, you can't arbitrarily say that given an architecture, I can chop pieces of code and put it inside a component boundary, therefore it is fractal.
Composition is a good pattern to know, but as we all know, composition can also create some poisonous dependencies that are hard to refactor. More people feel we have to find a balance between duplicating code and composition.
Fred Daoud
@foxdonut
Mar 29 2017 14:49
@devinivy I find the single root model principle highly valuable, but that doesn't mean you can't have fractal components.
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:49
@foxdonut I guess it's an art to separate the "fractalicious" part of your code from the "glue". :-)
Fred Daoud
@foxdonut
Mar 29 2017 14:50
The glue code wires the components together, passes sub-parts of the model to them, and combines their model updates back into the single root model.
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:50
Sure, but that's still and art, it seems.
Fred Daoud
@foxdonut
Mar 29 2017 14:50
@jdubray yes. I am working on something along those lines, it's turning out quite well.
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:50
:thumbsup:
Fred Daoud
@foxdonut
Mar 29 2017 14:51
I will share once I have all my ducks in a row :)
Still adhering to core principles of SAM, by the way.
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:51
I guess the most important aspect is the "separation of concerns", a component model should not go around it.
It's ok to deviate from SAM too! I have never been looking for followers. So far, I feel really good each time I use SAM, but I am also open to challenges and better approaches.
It's probably a bit idealistic to think that way, but Shanzhai seems to be a good thing, almost elevated to a philosophy these days.
devin ivy
@devinivy
Mar 29 2017 14:55
@jdubray is that where you'd start advocating for inversion of control? :P
Fred Daoud
@foxdonut
Mar 29 2017 14:55
My only "deviation" is perhaps nap() -- although it can still be there, in some situations it's not really needed. Otherwise, I find the other principles highly valuable -- single source of truth, views as functions of the model, clear separation of model mutation.
devin ivy
@devinivy
Mar 29 2017 14:55
:thumbsup:
Jean-Jacques Dubray
@jdubray
Mar 29 2017 14:57
@devinivy Sure, but it's still "reuse", DI is just wiring (which helps when you want to fork some dependencies) but it does not provide any guidelines on reuse.
@foxdonut I didn't read your first sentence, looks like it came encrypted or something like that :-)
Fred Daoud
@foxdonut
Mar 29 2017 15:02
@jdubray pardon? which sentence?
Jean-Jacques Dubray
@jdubray
Mar 29 2017 15:10
Sorry got to nap,
talk to you later
devin ivy
@devinivy
Mar 29 2017 15:13
later!