Live offers a true return, in the form of yeet(value) (aka {value}). This passes a value back to a parent.
…
Each fiber in a reduction has a fiber.yeeted structure, created at mount time. Like a context, this relation never changes for the lifetime of the component.
It acts as a persistent cache for a yeeted value of type A and its map-reduction reduced of type B:
I’m really not sure how I feel about yeet and fiber.yeeted as names. On the one hand, the slang meaning of yeet fits perfectly. On the other hand, slang ages badly. It can evolve from quirky/funny to cringy pretty quickly.
When you put it that way, I absolutely would avoid a library someday if it asked me to write cringe. Never considered that as a potential factor before.
The entire exercise is about shoehorning it into existing React conventions, so it was never going to be pretty. And you never interact with the contents of a fiber, so shrug.
What bothers me is that nobody in this thread has said anything useful about the material presented other than to nitpick terminology. And that’s after admitting it is a semantic perfect fit regardless.
It’s a pretty in-depth and not very short post about a solution that you created, for a niche (and if this gets widely used, you pioneered that - made the niche a big thing *). Which means it is a good piece, but not something most people will just read and have a strong opinion about.
Maybe, just maybe people didn’t have anything strong to say about everything else you wrote.
If you take a look at lobste.rs in general, most (in-depth) posts get a tiny amount of comments (while receiving over 10k views per comment, according to pushcx).
And obviously the posts that do have a lot of comments are - most of the time - not that in-depth, which makes it easier for other people to have an opinion about them. (Vim vs Emacs)
Nerds, not even once.
Sorry, I’m still taking the dancing lessons from last time. Maybe you are “the biggest nerd” and thus suffer from being alone with your specific interests. If this was too close for comfort, maybe stop giving passive aggressive comments. Saying “it’s sad no one has to say anything about the actual content” would’ve given the same message, without invoking this conversation (and is also totally valid).
* And if this sounds stupid, that’s the level of knowledge and thus commentary I have about this topic we’re talking about. I see why this is nice, I don’t have any usecase for this whatsoever.
You’ve built an inner system. If we want to draw with the GPU, why not send draw commands directly to the hardware, as DRI already allows? I’m impressed by what you’ve built, but I gave up relatively early on building something similar purely because I recognized that I was developing an inner platform within the browser.
I was planning to write a post about Live anyway, because it’s just that interesting. What are the implications of an incremental effect-based runtime?
There’s an incredible idea at the core of Live that needs more attention. This idea could be summarized as, “with Live, developers write programs as if they render a single frame: Live handles rewinding evaluation incrementally due to state change to make programs interactive.” Because of Live’s React-based heritage, this frame is going to be a rendered web page. But I think the React-based framing is a little distracting, because it’s not the principal innovation here.
Under a generalized model of an effect-based runtime, this concept of a ‘frame’ could be anything. For example, if our ‘program’ were a compiler, and our ‘frame’ were a compiled program, we could use generalized-Live to develop “an interactive compiler written as though it compiles a single program: generalized-Live handles rewindinding compilation incrementally due to programmer edits to make the compiler interactive.”
And indeed, Wittens hints towards the possibility of generalized-Live at the end of his post, when he starts talking about loosening Live from its React-shackles to create a “data-oriented lisp”. This is what I find interesting.
Drawing attention to the table at the start of the post, Wittens proposes two solutions: add returns to React, or add incrementality and state to an effect system. Wittens goes with the former approach, because it’s a better fit for his domain. I think that developing a ‘generalized-Live’ would require taking the latter approach.
After all, effect systems are the generalized form of what Live is trying to do here. I’ve been thinking a lot about how to add incrementality and state to a language with Algebraic Effects. Although I’m still working through Live’s source code to digest some of its finer points, I can say that Wittens proposed isomorphism between Quote/Unquote and hygienic macros is spot-on. Generalized-Live starts walking into the territory of an image-based lisp, where compile-time macro expansion becomes equalivalent to evaluating, freezing, and reifying a Live component tree. But that’s a discussion for another time.
Effects feel like a missing part of programming. As more languages adopt effect systems, and subsequently encounter their limitations, I think that looking at the patterns pioneered by Live would be a worthwhile endeavor.
Lobsters has a pretty big community of language designers and compiler writers. Live approaches a solution the problem from a perspective of “React with returns.” I would love to hear your opinion about the other side of the coin: how we could make “adding state and incrementality to a language with effects” a feasible possibility?
I’m really not sure how I feel about
yeetandfiber.yeetedas names. On the one hand, the slang meaning of yeet fits perfectly. On the other hand, slang ages badly. It can evolve from quirky/funny to cringy pretty quickly.When you put it that way, I absolutely would avoid a library someday if it asked me to write cringe. Never considered that as a potential factor before.
So yes, let’s not discuss the incremental run-time or the implications for programming. That would be silly.
regardless, the past tense of “yeet” is “yote”, anyways :^)
I’m reminded of a classic SMBC comic.
PEEK and POKE are back with a vengeance.
The entire exercise is about shoehorning it into existing React conventions, so it was never going to be pretty. And you never interact with the contents of a fiber, so shrug.
peek has never bothered me, but poke absolutely does
could be because poke is less common (peek is on almost every library stack implementation. poke is rare)
could be because facebook had a poke, and it was annoying. could be because being poked irl is annoying
What bothers me is that nobody in this thread has said anything useful about the material presented other than to nitpick terminology. And that’s after admitting it is a semantic perfect fit regardless.
Nerds, not even once.
It’s a pretty in-depth and not very short post about a solution that you created, for a niche (and if this gets widely used, you pioneered that - made the niche a big thing *). Which means it is a good piece, but not something most people will just read and have a strong opinion about.
Maybe, just maybe people didn’t have anything strong to say about everything else you wrote. If you take a look at lobste.rs in general, most (in-depth) posts get a tiny amount of comments (while receiving over 10k views per comment, according to pushcx). And obviously the posts that do have a lot of comments are - most of the time - not that in-depth, which makes it easier for other people to have an opinion about them. (Vim vs Emacs)
Sorry, I’m still taking the dancing lessons from last time. Maybe you are “the biggest nerd” and thus suffer from being alone with your specific interests. If this was too close for comfort, maybe stop giving passive aggressive comments. Saying “it’s sad no one has to say anything about the actual content” would’ve given the same message, without invoking this conversation (and is also totally valid).
* And if this sounds stupid, that’s the level of knowledge and thus commentary I have about this topic we’re talking about. I see why this is nice, I don’t have any usecase for this whatsoever.
You’ve built an inner system. If we want to draw with the GPU, why not send draw commands directly to the hardware, as DRI already allows? I’m impressed by what you’ve built, but I gave up relatively early on building something similar purely because I recognized that I was developing an inner platform within the browser.
Ok, I’ll bite.
I was planning to write a post about Live anyway, because it’s just that interesting. What are the implications of an incremental effect-based runtime?
There’s an incredible idea at the core of Live that needs more attention. This idea could be summarized as, “with Live, developers write programs as if they render a single frame: Live handles rewinding evaluation incrementally due to state change to make programs interactive.” Because of Live’s React-based heritage, this frame is going to be a rendered web page. But I think the React-based framing is a little distracting, because it’s not the principal innovation here.
Under a generalized model of an effect-based runtime, this concept of a ‘frame’ could be anything. For example, if our ‘program’ were a compiler, and our ‘frame’ were a compiled program, we could use generalized-Live to develop “an interactive compiler written as though it compiles a single program: generalized-Live handles rewindinding compilation incrementally due to programmer edits to make the compiler interactive.”
And indeed, Wittens hints towards the possibility of generalized-Live at the end of his post, when he starts talking about loosening Live from its React-shackles to create a “data-oriented lisp”. This is what I find interesting.
Drawing attention to the table at the start of the post, Wittens proposes two solutions: add returns to React, or add incrementality and state to an effect system. Wittens goes with the former approach, because it’s a better fit for his domain. I think that developing a ‘generalized-Live’ would require taking the latter approach.
After all, effect systems are the generalized form of what Live is trying to do here. I’ve been thinking a lot about how to add incrementality and state to a language with Algebraic Effects. Although I’m still working through Live’s source code to digest some of its finer points, I can say that Wittens proposed isomorphism between Quote/Unquote and hygienic macros is spot-on. Generalized-Live starts walking into the territory of an image-based lisp, where compile-time macro expansion becomes equalivalent to evaluating, freezing, and reifying a Live component tree. But that’s a discussion for another time.
Effects feel like a missing part of programming. As more languages adopt effect systems, and subsequently encounter their limitations, I think that looking at the patterns pioneered by Live would be a worthwhile endeavor.
Lobsters has a pretty big community of language designers and compiler writers. Live approaches a solution the problem from a perspective of “React with returns.” I would love to hear your opinion about the other side of the coin: how we could make “adding state and incrementality to a language with effects” a feasible possibility?