3 ms·

I get the idea, but I'm not convinced about its usefulness. I fear that it would make it really easy to write horribly inefficient apps, interspersing client an

I get the idea, but I'm not convinced about its usefulness. I fear that it would make it really easy to write horribly inefficient apps, interspersing client and server code willy-nilly, ending up with an entangled async mess that noone can really reason about. I saw this unfolding first-hand in functional reactive codebases... Sometimes explicit boundaries are a good thing. In fact, I would argue that they are more often than not.

convolvatron 4y ago
I really can't see how unifying the value domain and language semantics of the back and front end necessarily involves more complication than maintaining the mapping between them.
- aaaaaaaaaaab 4y ago
  ORM frameworks also unify the value domain and the language semantics of the database and the host app, and make it very easy to shoot yourself in the foot with the N+1 query issue and such. This will suffer from the same issues once you move beyond toy examples.
  - convolvatron 4y ago
    just for your one example, it seems pretty clear from the discussion that the datalog planner here making the cut across the network connection specifically to minimize data motion. certainly people can build bad things. there is however a very real likelihood that a programming model which includes distribution will turn out to be effective
  - dustingetz 4y ago
    (speaker here) Photon is not an object mapper, we do not have an N+1 problem and in fact that is the exact topic of this talk. Photon is designed to scale in complexity without loss of performance or ability to reason. The computational structure that achieves this is single directional dataflow with pure functions; the abstraction is “referentially transparent” which means it composes mathematically the way pure functions compose. Strong composition as a basis for abstraction scalability (in the domain of UI) is the core innovation here.

convolvatron 4y ago

I really can't see how unifying the value domain and language semantics of the back and front end necessarily involves more complication than maintaining the mapping between them.

aaaaaaaaaaab 4y ago
ORM frameworks also unify the value domain and the language semantics of the database and the host app, and make it very easy to shoot yourself in the foot with the N+1 query issue and such. This will suffer from the same issues once you move beyond toy examples.
- convolvatron 4y ago
  just for your one example, it seems pretty clear from the discussion that the datalog planner here making the cut across the network connection specifically to minimize data motion. certainly people can build bad things. there is however a very real likelihood that a programming model which includes distribution will turn out to be effective
- dustingetz 4y ago
  (speaker here) Photon is not an object mapper, we do not have an N+1 problem and in fact that is the exact topic of this talk. Photon is designed to scale in complexity without loss of performance or ability to reason. The computational structure that achieves this is single directional dataflow with pure functions; the abstraction is “referentially transparent” which means it composes mathematically the way pure functions compose. Strong composition as a basis for abstraction scalability (in the domain of UI) is the core innovation here.