3 ms·

Would you say I mischaracterise LISP, or the analogy between quoting and sending modules doesn’t apply? As I say in the article, I’m not familiar enough with L

Would you say I mischaracterise LISP, or the analogy between quoting and sending modules doesn’t apply? As I say in the article, I’m not familiar enough with LISP to understand how Electric works, but I’m a bit confused why you say there’s no content. I'm making a connection between the paradigms; if you find it vacuous, I think it would help to focus the criticism on the connection itself (why doesn't it hold?) rather than on me admitting the gaps in my knowledge. I appreciate the link you’ve shared about Racket. From what I see, their continuations seem server-only, i.e. there’s no way to express client-side code in Racket (beyond HTML). What I’m interested is a more mixed approach where LISP orchestrates both server and client code, which would be a closer analogy to RSC.

judofyr 1y ago
From the article: > It marks a piece of code to be treated as data (to be sent to the client). > This means that whoever imports onClick from the backend code won’t get an actual onClick function—instead, they’ll get '/js/chunk123.js#onClick' or something like that identifying how to load this module. It gives you code-as-data. Eventually this code will make it to the client (as a <script>) and be evaluated there. The point of quoting in Lisp is that you get the code actually as data: You can introspect it ("how many string literals are there in here"), rewrite it ("unroll every loop once"), serialize it, store it in a database. And more importantly: The code is structured in the same way as any data in a regular program (lists). It's not hard for the developer to do any of these things. If I get back '/js/chunk123.js#onClick' I simply have a reference, which I can use to invoke it remotely. The code appears to still be sent as bundled JavaScript, evaluated as usual, and then linked together with the reference. There's a small connection to code-as-data in the sense that you need to be able serialize code in order to share it between a server/client, but other than that I don't really see much of a connection.
- danabramov 1y ago
  Sure, and the article does acknowledge that directly: >Of course, this is a lot less powerful than quoting because the evaluation strategies are being prescribed by React, and there’s no kind of metaprogramming like transforming the code itself. So maybe it’s still a stretch. To me, the connection is that I'm able to treat a reference to serialized code as a first-class primitive that can be passed around the server code (and composed via component tag composition), but indeed it's not full-on metaprogramming.
kaoD 1y ago
As someone that knows both Lisp and RSC, I don't think this is a great analogy since it misses nuances and intention in both sides of the equation. The crux of Lisp's code-is-data-is-code is that you can manipulate S-expressions since they're a very simple data structure (think metaprogramming). I know you touched upon this in the article but acknowledging it doesn't make it less central to the issue. I don't see the parallels except a very superficial similarity due to code being "serialized" (for lack of a better term, since that's not even what Lisp does) but that's just (1) a technical detail that glosses over the actual intention/capabilities and (2) not even true if we go down to the technicals. But that might just be my personal priors, so take it with a grain of salt.
- danabramov 1y ago
  To me, the common thing is having a first-class way to deal with something that's poised to execute later. RSC's way to do it is opaque, whereas quoting isn't opaque. In that sense, quoting is more powerful — which is why it can express both RSC and more mixed paradigms like Electric. But I think it's a meaningful connection because it's both about intent and capabilities. There aren't a lot of programming paradigms that enable cross-runtime composition and orchestration.

judofyr 1y ago

From the article: > It marks a piece of code to be treated as data (to be sent to the client). > This means that whoever imports onClick from the backend code won’t get an actual onClick function—instead, they’ll get '/js/chunk123.js#onClick' or something like that identifying how to load this module. It gives you code-as-data. Eventually this code will make it to the client (as a <script>) and be evaluated there. The point of quoting in Lisp is that you get the code actually as data: You can introspect it ("how many string literals are there in here"), rewrite it ("unroll every loop once"), serialize it, store it in a database. And more importantly: The code is structured in the same way as any data in a regular program (lists). It's not hard for the developer to do any of these things. If I get back '/js/chunk123.js#onClick' I simply have a reference, which I can use to invoke it remotely. The code appears to still be sent as bundled JavaScript, evaluated as usual, and then linked together with the reference. There's a small connection to code-as-data in the sense that you need to be able serialize code in order to share it between a server/client, but other than that I don't really see much of a connection.

danabramov 1y ago
Sure, and the article does acknowledge that directly: >Of course, this is a lot less powerful than quoting because the evaluation strategies are being prescribed by React, and there’s no kind of metaprogramming like transforming the code itself. So maybe it’s still a stretch. To me, the connection is that I'm able to treat a reference to serialized code as a first-class primitive that can be passed around the server code (and composed via component tag composition), but indeed it's not full-on metaprogramming.

kaoD 1y ago

As someone that knows both Lisp and RSC, I don't think this is a great analogy since it misses nuances and intention in both sides of the equation. The crux of Lisp's code-is-data-is-code is that you can manipulate S-expressions since they're a very simple data structure (think metaprogramming). I know you touched upon this in the article but acknowledging it doesn't make it less central to the issue. I don't see the parallels except a very superficial similarity due to code being "serialized" (for lack of a better term, since that's not even what Lisp does) but that's just (1) a technical detail that glosses over the actual intention/capabilities and (2) not even true if we go down to the technicals. But that might just be my personal priors, so take it with a grain of salt.

danabramov 1y ago
To me, the common thing is having a first-class way to deal with something that's poised to execute later. RSC's way to do it is opaque, whereas quoting isn't opaque. In that sense, quoting is more powerful — which is why it can express both RSC and more mixed paradigms like Electric. But I think it's a meaningful connection because it's both about intent and capabilities. There aren't a lot of programming paradigms that enable cross-runtime composition and orchestration.