These are chat archives for jdubray/sam

10th
Jan 2018
Jean-Jacques Dubray
@jdubray
Jan 10 2018 01:31
@foxdonut thank you
@Vertex21 :+1:
Radosavljevic Slobodan
@radosavljevic
Jan 10 2018 09:20

@jdubray

Actually, there seems to be more than meet the eye, this presentation is a bit slow but quite informative to understand what Monads do compared to imperative code:
https://www.youtube.com/watch?v=LEug6jAj5BA

What you had in mind? Something specific to the presentation or monads in general?

Jean-Jacques Dubray
@jdubray
Jan 10 2018 09:46
Monads seem to offer a solution to remove a lot of if-fy statements, but I need to investigate more. That's first I time I see Monads in Practise. My concern so far is that it seems that you need lots of specific monads so the gain might be nil.
Radosavljevic Slobodan
@radosavljevic
Jan 10 2018 09:55
Thanks, great to hear that you're investigating it.
Łukasz Lityński
@hex13
Jan 10 2018 13:26
@jdubray I thinks libraries like Immer (or my library Transmutable about which I talked when we discussed immutability behind scenes) could actual help bring SAM ideas to live. Transmutable (library similar to Immer) was inspired partially by SAM idea that action should only propose mutations. (Action -> Mutation -> State Representation) -- It's exactly what Transmutable does. It gives you a proxy, you record mutations on proxy, then mutations are recorded in some way - and the rest of program(it could be e.g. "model" from SAM) could decide if it should apply these mutations. Default behaviour and default purpose of Transmutable is to just create immutable copy of previous state + recorded mutations but it can't be easily tweaked
(I answer here for what you wrote on Twitter, because I was banned on Twitter)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:32

@hex13 I appreciate your point of view, but this is not how mutation works from a computation perspective. It's pretty clear:

  • actions make proposals (primed variables)
  • the next-state relation computes the next state based on the proposal
  • the control states can be derived once the mutation is complete

There is no reason whatsoever to annotate (sorry I didn't look at transmutable). So unless someone shows me how their approach relates to temporal logic, I think this is just hand waving (sorry)

There is absolutely no reason to take copies of the previous state, don't you see how simple(r), efficient and elegant it is to keep track of the proposal (primed variables) rather than the previous state. Please, let's wake up and stop this immutable insanity.
Łukasz Lityński
@hex13
Jan 10 2018 13:35
what do you mean by keep track of proposal?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:38
You have to looked at the concept of primed variables in TLA+ . It is one of the three fundamental operators of temporal logic. All you have to do is first compute the values of the variables in the next state, then during the mutation everything is clear.
Basically what you are telling us (with immutability) is that you can be as sloppy as you want an immutability will save you, at quite a heavy price.
Łukasz Lityński
@hex13
Jan 10 2018 13:40
I tried to read paper about TLA+ but it was to hard to understand
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:40
There are alternatives to immutability, please be open.
One of the worst side effect of immutability is that it leaves no room, absolutely no room for API calls
@hex13 please just focus on one concept primed variables, nothing else.
Łukasz Lityński
@hex13
Jan 10 2018 13:41
I'm not sure why you don't like immutability so much. Immutability can be technical detail. I lately even think about models which are mutable inside, but immutable outside (because representation of state in the outside can be easily derived from the model state)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:42
an look at how primed variables change the way you can mutate state.
Łukasz Lityński
@hex13
Jan 10 2018 13:43
immutable data can help during determining if something has changed in tree, and it could helps in determining if observers should be notified
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:45
So be it, I am just trying to point out that there is another way that is infinitely simpler, is API call friendly, doesn't have any memory/performance cost.
You are free to ignore it.
Łukasz Lityński
@hex13
Jan 10 2018 13:47
actually API calls can be abstracted by using concepts from reactive programming. Many of API calls people in React/Redux community do are just not needed
e.g. fetching data from server. People do crazy stuff
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:49
Yes, that's the problem with Software Engineering, we can always get it done and we never look at how we got it done, how much it costs, will maintenance cost,...
Łukasz Lityński
@hex13
Jan 10 2018 13:49
e.g. they write often something like this in thunk (using Redux thun)
  1. dispatch({type: 'IS_FETCHING');
  1. calling ajax function
  1. dispatch({type: 'IS_FETCHED'})
  1. dispatch({type: 'DATA_LOADED', data: data});
(should be 1. 2. 3. 4. not 1. 1. 1. 1.)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:50
Please... I get it.
Łukasz Lityński
@hex13
Jan 10 2018 13:50
this is madness because this whole could be made automatically with proper abstraction
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:51
yes, no such a thing with SAM, zero, nil, nada, you can even get a generic cancellation mechanism
Łukasz Lityński
@hex13
Jan 10 2018 13:53
I think more declarative approach could allow to just assign to state property an observable, something like this
state.data = SOME_API_CALL('a.json').map(d => {return someCalculations(d)});
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:54
I doubt it, you can't write temporal logic declaratively
Łukasz Lityński
@hex13
Jan 10 2018 13:54
and some kind of middleware could just transform this observable behind scenes into state
(my point now is more like "70-90% API calls in frontend community could be abstracted via reactive programming and using observables)
(percent numbers are just my pure guess, of course)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:55
Again, you have to define what is a programming step is, and position mutation (next-state relation) in that step. You cannot change the definition of the step across your code, that is the problem, not the solution.
Łukasz Lityński
@hex13
Jan 10 2018 13:55
I just think so many times that "API call" is not "API call" but rather just fetching data from server
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:56

my point now is more like "70-90% API calls in frontend community could be abstracted via reactive programming and using observables

that is a fallacy (I am not trying to be harsh), there is simply no evidence for such proposition

Łukasz Lityński
@hex13
Jan 10 2018 13:56
I know.
they were rhetorical percents, not real ones
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:56
You have queries and commands, so it's not just fetching
I know people often start (and stop) at fetching
Łukasz Lityński
@hex13
Jan 10 2018 13:57
but often people just fetch some resources
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:57
but you can't do much without commands
Łukasz Lityński
@hex13
Jan 10 2018 13:57
or write to resources
Backbone had abstraction for this
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:57
OMG, not another REST discussion.
Łukasz Lityński
@hex13
Jan 10 2018 13:57
:)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:57
yes, and backbone is dead
Łukasz Lityński
@hex13
Jan 10 2018 13:59
because it had many flaws
Jean-Jacques Dubray
@jdubray
Jan 10 2018 13:59
We have been using everything, except temporal logic, for decades, and for decades we have been circling around, always hitting the same problems.
Łukasz Lityński
@hex13
Jan 10 2018 14:01
maybe somebody should make a library which applies temporal logic in practice and make cool colorful demo on some programming conference
if such thing happened
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:01
Whether you are using an ancillary state machine or a more declarative approach, what you are trying to do is come up with your own way to write temporal logic. It's a bit like you were using a programming language where there is no concept of function and you are trying to come up with your own opinion as to what a function is.
Łukasz Lityński
@hex13
Jan 10 2018 14:01
everybody would be used temporal logic
frankly for me temporal logic is hard to understand (and these math symbols), but maybe I will look deeper into it.
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:02
It's already available in Java and Javascript and was translated to C# by @robsiera
https://www.ebpml.org/blog15/2015/04/star-based-component-model-with-tla-semantics/
Łukasz Lityński
@hex13
Jan 10 2018 14:03
right now I'm still trying to understand other programming concepts like monads for example
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:03
I agree, it would really help if Dr. Lamport would take on that task. I am just "JJ", I am no mathematician.
You would not imagine how many times I got rejected from speaking to a conference. I tried that too. So far I was only accepted to NodePDX in 2016 and to a webinar with Tracy Lee.
Fred Daoud
@foxdonut
Jan 10 2018 14:05
@jdubray why rejected? because of the topic? because of who you are (or are not)? or other reason?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:06
I am not sure, they never give a reason.
Łukasz Lityński
@hex13
Jan 10 2018 14:14
it would really help if you (or somebody else) could build a solid programming library (and promote it)
I don't want to be harsh but builders of successful open source projects have usually better opinion in community than people who rants constantly about something and discuss things on theoretical grunt, even if they're right
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:17
yes, I hear your point, I accept it. I did build a number of things, but they are obviously not good enough.
and I accept it too.
Fred Daoud
@foxdonut
Jan 10 2018 14:18
@hex13 I think you'll find that @jdubray has posted many examples, as well as supporting libraries. A lot of the point of SAM though (and one of its strengths) is that the "library" part is not strict; it's a pattern that you can wire up in different ways.
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:19
:+1:
Fred Daoud
@foxdonut
Jan 10 2018 14:21
The problem IMHO is that many developers out there just want something done for them and blindly use a library without understanding the underlying concepts. Yes, practical examples are needed to complement the theory, but the theory has to come first.
Further, the problem with some of the libraries themselves is that the practical came first, without a solid understanding of what concepts they were even trying to achieve, so these libraries eventually fall apart, held up only by a long series of patchy add-ons.
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:23
It's also a major overlook of our industry and language designers. I am not quite sure we could ignore temporal logic that has been around since the 70s.
Fred Daoud
@foxdonut
Jan 10 2018 14:23
@jdubray what is your recommendation on a good source to properly learn about temporal logic?
devin ivy
@devinivy
Jan 10 2018 14:23
i don't think the theory always necessarily has to come first (temporally ;)) sometimes good ideas come out of practical problem solving. but in general i absolutely agree! most of the time those good ideas need refining against some foresight/theory.
Łukasz Lityński
@hex13
Jan 10 2018 14:24
sometimes support of big company is needed to push an idea through (like Facebook did it with Flux. I mean I don't want to discuss Flux but I only say that when a big company pushes some idea, it has already a big leverage)
devin ivy
@devinivy
Jan 10 2018 14:24
which may mean scrapping the original library (for example) rather than adding onto it
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:24

Further, the problem with some of the libraries themselves is that the practical came first, without a solid understanding of what concepts they were even trying to achieve

yes, that's the major problem, you look at RxJS, Cycle.js, or even Elme/Redux, it seems exactly to be how they came about. A good idea, but without a solid foundation.

Łukasz Lityński
@hex13
Jan 10 2018 14:25
or even Virtual Dom idea - also pushed by Facebook (I also don't want to discuss virtual dom)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:25
@devinivy agreed, always anchoring what you do in well defined problems help
The problem is that we are creating generations upon generations of followers.
Fred Daoud
@foxdonut
Jan 10 2018 14:26
@devinivy you're right, there has to be a balance too :) all theory and no practical makes Jack a dull boy :D
Łukasz Lityński
@hex13
Jan 10 2018 14:26
Google also pushes some or other idea from time to time
e.g. material design
Jean-Jacques Dubray
@jdubray
Jan 10 2018 14:27
For the people old enough who have seen Corba, EJB, ASP.Net ... all this is a major dejavue :-)
Łukasz Lityński
@hex13
Jan 10 2018 19:28
I think programmers should learn more about history of programming as a whole. But this is a problem, because history of programming is considered to be "not practical".
maybe it should be learns in schools
but this is also a problem, programming is rarely considered a separate field of study
it is often mixed up with mathematics or physics (at least in Poland - there are "informatics" studies but their program is like math + physics).
Łukasz Lityński
@hex13
Jan 10 2018 19:34
From what I read sometimes about USA education, there also programming is mixed up with computer science, which is unfortunate
I think programming has more to do with philosophy or social sciences than with advanced math.
Łukasz Lityński
@hex13
Jan 10 2018 19:39
(though I think math itself is just a part of philosophy)
though for me programming from some perspective is just some social-cultural phenomenon.
some trends in programming come, some trends are then gone, some other are forgotten...
programmers should really spend more time learn about history of their field
Łukasz Lityński
@hex13
Jan 10 2018 19:44
because almost everything was invented already in the past, probably by employers of IBM, Xerox or Microsoft
or AT&T
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:10
Ultimately it's a personal choice more than instutitional. I am just puzzled as to how some of the fads of our industry take hold from OOP, to REST to functional programming or even agile, and now it seems people are trying to make FSM popular. It seems that the common denominator is:
  • take an obvious concept X that everyone can relate to (object, function, resource, microservice, agile)
  • take an accute problem Y (global state, mutation, WS-* is too hard to learn. monolith, user story)
  • pick a trivial example and show how X solves Y and voila
In programming we have only two dimensions (that I know of) that we can act upon when we invent new paradigms:
  • the semantics (I call it polyadism)
  • the degree with which we can express logic (I call it cogency)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:17
It seems to me that there are 4 key semantics that seem to be unreifiable: State, Type, Action, Relationship (STAR) but most programming model just pick one (OOP -> type, FP -> ~action ...). REST is interesting because if you look carefuly REST has all four: State Representation, Resources, Verbs, Links, but they have no way to express logic.
And for some reason, we never question the cogency of our programming model.
Really all I am saying is that:
  • you can evaluate and compare programming paradigms with STAR
  • we have missed, as an industry, the concept of temporal logic entirely
devin ivy
@devinivy
Jan 10 2018 21:20
temporal logic counts as what you call cogency, yes?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:20
it is part of cogency, but is missing in 100% of programming languages today
I am not saying that I found the best way to express it, far from it
devin ivy
@devinivy
Jan 10 2018 21:21
what are examples of some primitives to temporal logic?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:21
But I am certain that we have all, collectively, missed that and it is causing lots of aches and pains
devin ivy
@devinivy
Jan 10 2018 21:22
where do "events" fit in, or being able to say "A comes before B"?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:22
There are only three primitives:
  • primed operator
  • always operator
  • existence operator
Event are occurence of a state, so they are covered by STAR
A comes before B is a relationship
relationships are expressed with counters whether they are static or temporal
devin ivy
@devinivy
Jan 10 2018 21:24
how does STAR relate to temporal logic? can't each of S, T, A, R speak to temporal logic in certain ways?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:24
It doesn't
STAR are the unreifiable semantics of programming
I can't create a programming language with some degree of S, T, A, R
The temporal logic, as I see it (again, happy to be proven wrong) is:
  • proposal
  • mutation
  • nap
devin ivy
@devinivy
Jan 10 2018 21:27
is "mutation" inherently transactional?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:28
There is the notion of a programming step, I think it's preferable to refer to "programming step" rather than transactional
Programming step implies transactional
For instance, we could decide that "roll-back" is a common pattern in mutation and we need to implement it at the language level
devin ivy
@devinivy
Jan 10 2018 21:29
i see better what you mean
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:29
but inherently, it is not a fundational component
devin ivy
@devinivy
Jan 10 2018 21:30
these are good examples to see what you mean by saying that programming languages don't speak to temporal logic
what about the actor model?
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:31
they offer no structure that would help me do it properly, I'd have to think really hard to continuously code that way.
devin ivy
@devinivy
Jan 10 2018 21:31
or mutex locks?
i realize these are very basic examples, but don't they at least speak to temporal logic?
and are at times a part of languages
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:33
I'll have to dig a bit to make some informed comments, I never worked with Erlang or Scala/Akka
devin ivy
@devinivy
Jan 10 2018 21:34
totally different question!
curious of your impression of graphql– i notice you've mentioned it a few times recently
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:34
The problem with locks is that they don't come with a programming step. They are bound to assignments, not mutations.
They can be used to implement a programming step, but again, you'd have to be super conscious of the need for a programming step to do it. From all the code that I have seen in 40 years, developers don't bother thinking along these lines.
In other words, temporal logic is not a synchronization problem, it's more profound than that.
devin ivy
@devinivy
Jan 10 2018 21:37
sure, i see what you mean!
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:39
As I mentioned before, the idea behind GraphQL has been tried countless times:
  • MetaMatrix (now part of RedHat/JBoss)
  • Composite Software (now part of Software AG)
  • Service Data Object (SAP, IBM, BEA, ...)
  • ql.io (Subbu Allamaraju / eBay - I know Subbu well, we were nearly neighbors and had countless discussions about REST)
  • others??
First, the concept of virtual database does not scale because you will always hit the case where you need to do a join over the service/microservice boundaries. Second, you will never be able to deal with consistency (read/write) over API interfaces.
ql.io was exactly GraphQL, others could be argued that it was different enough, but the exact same problems should apply.
Why does GraphQL exist? because we can't properly articulate API calls in the React programming model. Again and again, frameworks come up with a programming model, each time they hit an issue, they never go back and question that programming model, they keep patching it (pun intended).
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:45
All this has been tried before. IMHO, the main contribution of React is functional HTML, everything else you can throw away, but we have developed a culture where you can never question what is popular.
Jean-Jacques Dubray
@jdubray
Jan 10 2018 21:52

For instance Eric Elliot just wrote:

After looking at this year’s numbers, I’m prepared to strongly recommend React for most general app development use cases,

it is insane, it's popular, therefore it is the right thing to do.
devin ivy
@devinivy
Jan 10 2018 22:00
ah yes, i saw that
Jean-Jacques Dubray
@jdubray
Jan 10 2018 22:04
It's the "nobody lost their job for picking Oracle or IBM" from the 90s.
You will not that there is not a single word of caution in the entire article.
So yes, people can say I am ranting whether it's about REST or State Management, but what choice do I have? objectively? It's all about deflecting any kind of questioning.
How many times people have told me you are wasting your time and your career when you could be making $300/hour explaining how to convert verbs to nouns?
devin ivy
@devinivy
Jan 10 2018 22:16
hahaha!! :) :pray: i enjoy your desire to make things better!
and that you're not just converting verbs to nouns, as magical as that is!
Jean-Jacques Dubray
@jdubray
Jan 10 2018 22:20
:-)
Jean-Jacques Dubray
@jdubray
Jan 10 2018 22:43
devin ivy
@devinivy
Jan 10 2018 22:43
haha i saw that
no more responsive websites because deep learning can't nail it :trollface:
i'll believe we're doomed when i see it! that is some incredibly impressive work, but the output isn't good enough to make me fear for my job :P
Jean-Jacques Dubray
@jdubray
Jan 10 2018 22:54
In a way, it's interesting we can get it done both from a UX and Logic/Rules perspectices considering the minutia of details involved. As soon as you pass the CRUD scenarios and have real (temporal?) logic then it seems that we still have a few years until AI catches up.
Jean-Jacques Dubray
@jdubray
Jan 10 2018 23:05
That's where I see STAR's benefit because it seems to provide enough structure to reason about it all.