These are chat archives for jdubray/sam

Jun 2017
Johan Alkstål
Jun 04 2017 18:56
@jdubray In one of your videos, you say that the SAM pattern is an alternative to FRP. Is it really an alternative, or perhaps a complement? I don't see the two things cancelling each other out
Jean-Jacques Dubray
Jun 04 2017 19:45
@johanalkstal I believe at this point it is an alternative. Functional Programming, and hence Reactive Functional Programming as defined by say Cycle.js and Elm is departing significantly from SAM and it's foundation TLA+.
As Dr. Lamport states, "Much of computer science is about state machines."
Computer science should be about concepts, not [programming] languages. But how does one teach concepts without
getting distracted by the language in which those concepts are expressed? My answer is to use the same language as every other branch of science
and engineering—namely, mathematics
What's interesting is that Dr. Lamport is not isolating a particular concept of mathematics (say mathematical functions) and describes computing from it, au contraire, he is using mathematics as a whole to describe computing.
Using Functional Programming (as a new foundation to computer science and software engineering), is a bit like Einstein building the general theory of relativity with just one concept out of Energy, Mass, Light and Force). Dr. Lamport didn't cherry pick this or that.
Jean-Jacques Dubray
Jun 04 2017 19:53
The question you ought to ask, is FP the foundation? the answer is no. FP is an interesting conceptual view of Computing, say like OOP once was, but trying to reify computing behind FP is as silly as it would be to try to reify it behind OOP. OOP and FP are a small subset of the foundation of computing which I believe is best described by TLA+. So at this point I would say that SAM offers an alternative, though they don't seem that far, I agree, but this is really a question of perspective, because FP offers no flexibility in its principles.
Johan Alkstål
Jun 04 2017 21:14

SAM is just a pattern though. V = S( vm(M.present(A(data))), nap(Model) ).
A logical expression but a very functional one. And it's also a reactive pattern. Your words from :)

Which is why I asked if it's not a pattern that complements FRP very well? Not exclusively.
Logically I feel it sits well with a functional approach of pure functions. I also feel it fits well with streams.
Mind you, I say this as someone who is not very comfortable working with streams or very knowledgeable in FRP.

As a pattern, it has to be implemented by something. A pattern is nothing on its own.
So that's why the claim that the SAM pattern is an alternative to an implementation detail (OOP, FP or whatever programming you adhere to) seems odd. Apples and oranges? :)
Johan Alkstål
Jun 04 2017 21:23
I'm not discussing if there is One True Way to do programming (there isn't).
OOP, FP or whatever are tools in your toolbox. Some tools are better suited for different tasks though.
Building a house requires the use of multiple tools.
Jean-Jacques Dubray
Jun 04 2017 22:38

there isn't

I am not talking about "programming", I am talking about the foundation of computer science, there is one. Programming cannot completely ignore it. As I said before, we have been programming for decades based on three approximations:

  • assignments are equivalent to mutation
  • actions can manipulate the application state
  • there is no need to define what a "programming step" with precision
    Billions of lines of code have been written based on these three approximations. It works, obviously... But it works less these days due to the distributed nature of systems.

You need to make mutation explicit
Actions can no longer manipulate the state
We need to define what a programming step is

As I said before, somehow FP and RFP are addressing in their own way these approximations, but IMHO, they are not consciously addressing them, they negate mutation (that's a way to segregate assignments from mutation), they don't have the concept of actions (rather events), so FP/RFP "actions" can't manipulate the state, by design and the programming step is a function. But... that approach is not optimal, again IMHO. It works in simple cases, but will become very brittle at scale (scale of the system).

All I have been advocating is to have an open, objective and honest discussion about these concepts, but it looks like that's not what the FP community wants to hear.
Just to be clear, the level I am talking about it not "tools", SAM is not a "tool", SAM tries to offer a factoring that is foundational. You can't build a house with the wrong foundation/structure. SAM is a structure, you can use any tool you want and still follow the SAM pattern.
Johan Alkstål
Jun 04 2017 22:55
I've not read computer science, my knowledge is limited in that area. Nor do I adhere to a programming community so I can't speak for anyone else. I was merely stating an observation I had. I'm always interested in how we can do things better, for us as developers and for those who end up using what we produce. Which lead me to stumble upon SAM, and why I'm still thinking about it. I appreciate an honest and open minded discussion. =)