These are chat archives for jdubray/sam

Jan 2018
Radosavljevic Slobodan
Jan 30 2018 07:35
It would be great if we could see the entire code for the datepicker example you gave, especially because it uses acceptors, reactors terminology...
Artyom Shalkhakov
Jan 30 2018 12:02
@jannesiera definitely interesting; but programs are effectful, proofs are are not. programs are non-terminating, proofs are terminating (strongly normalizing)... etc. lots of differences between the two in practice.
Jean-Jacques Dubray
Jan 30 2018 17:44
@radosavljevic the remainder of the code is SAM boilerplate project:
Actions, Acceptors, Reactors... are mounted in the SAM instance and executed as part of a normal SAM flow. Really the only distinction here is that the local state of the (datepicker) component is folded in the application state. I just don't like components-as-a-class architecture. I think it's very limiting. OOP should be burried deep under the antartica icecap and only to be used again when it melts (hopefully never).
Jean-Jacques Dubray
Jan 30 2018 17:49
Now, I am not saying my code is elegant because I have to do a lot of wiring that a compiler could do for me if it was part of the language. All I am saying is that we have to be careful and conscious about our programming models. They have huge implications that we do not always (fore)see. We should never take a class structure or even a function as a proper container of code (something we can pass around and reuse in different contexts).
You can disagree with SAM or see no value in it, it's ok, but it would be great enough for me if SAM could help people focus on their programming model.