Sure, users don’t care if the code is a mess. At least at first. I mean, they can’t know.
But they DO care when the same bugs exist for years, when new features dry up, when it drains their battery, etc. When technical debt becomes due, users notice in other ways.
Now, whether they care enough or just don’t have a choice is another matter.
So I’m wondering what ‘rasterizing’ literally means in this case. I imagine it’s just creating a 2D map of elements at a very low (probably character) resolution, then diffing that against the last generated map to come up with an optimal ANSI sequence to send to the terminal, would that be right?
Seems like a cool puzzle to solve. I wonder what the engineering and organisation tradeoffs were that lead to it — does it let them reuse a bunch of existing code?
I wrote a TUI library back in the day for Turbo Pascal — it was essentially taking an immediate-mode approach (which in this context is just a fancy way of saying it was procedural haha).
"Rasterizing" means just one thing in this context: to transform a data structure into an array of pixels. It seems absurd to do this, given that the next step must be to convert back from pixels to text data, but maybe they have some way to generate predictable sequences of pixels (e.g. the character "t" is always rendered as the same pattern of pixels), such that they're cheap to convert back.
If they're doing anything else, the word "rasterizing" is being misused.
Yes, the much more plausible explanation is that the word rasterize was misused there. They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive.
> They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive
No one has ever done that. Even top[0], which does full screen refresh, clear the screen (if necessary) and write the new information (the period is in seconds, not ms). No need to diff. That would be like diffing a file, just to find which bytes to update.
I don't understand why you would make such a confident negative claim rather than ask for an example or otherwise engage in discussion. Particularly given that you replied to a comment elsewhere in this very thread that links to a real world example of exactly such an implementation! [0] See in particular this part of the source. [1]
I agree that most programs don't bother to do that but please recall that my claim was merely that what Claude Code is claimed to be doing with regards to diffing is a well established and long standing optimization. The important point being that it is neither expensive, novel, or particularly complex thus not an excuse for poor performance.
The emacs code is not purely diffing. They already have the final output, they’re mostly comparing it to see a cheaper way to update than render the output. I’m pretty sure the curses library have the same thing.
But ink, the library Claude is using, defines a tree data structure for the main concept. The diff there is about comparing the old tree and the new tree created by the update, and then updating the node that has changed. That means if a single character change inside a bing panel, the whole thing is rewritten. And if you have something that is updating a lot, that means flickering.
The diffing that ink does is just architecturally wrong. You can create a dom, but a dom is not a concept for the terminal. It’s up to you to optimize its rendering. But just diffing the dom structure like react does is not optimizing, it’s busywork.
Also fun, Google purchased movies over the years getting moved to Youtube and then seemingly losing all surround sound content and coming through as 2-channel only (Android TV).
Had a few eye surgeries (vitrectomies) under sedation, no pain but lots of flashing lights and lots of kaleidoscope patterns. It was pretty wild.
I was lucky that coming out of sedation was actually fantastic, like the only time I can remember feeling that blissfully relaxed was in maybe a few beach holidays I went on as a kid.
I actually think it would have done well if it was just like those button boxes / Stream Deck / etc. Like a row of transparent function keys with screens, but then that would have been a flexibility tradeoff.
What I’m curious about is what lead to larks ‘winning’ in the sense that there’s this massive prejudice against night owls.
Though I have heard that there are natural biological functions that depend on the sun such that night owls who are sleeping their natural pattern are STILL predisposed more towards certain physical/mental conditions. Though who knows?
I _wish_ I could nap after hearing all the benefits, but for me it’s either doze off for five minutes and wake up feeling blah, or lie there for 10 minutes, MAYBE go to sleep for a bit and wake up feeling horrible.
If I have light to anchor my circadian rhythm, I’m happiest waking up around 5:30-6:00 and going straight through, starting to wind down at 8:30.
If I sleep later, I’ll end up shifting more towards naturally waking up around 10:30, going to bed at 11:30 PM and generally feeling not terrible but not great and slightly tired during the entire day.
Luckily the light can be artificial that wakes me up — I use smart bulbs as an alarm.
If it doesn't come naturally don't worry about it. Not everyone is the same. It sounds like the most beneficial thing for you is probably what you're already doing.
For myself my attentiveness and energy tend to slump later in the day if I don't so obviously I'm better off the other way around from you.
> I _wish_ I could nap after hearing all the benefits, but for me it’s either doze off for five minutes and wake up feeling blah, or lie there for 10 minutes, MAYBE go to sleep for a bit and wake up feeling horrible.
You just need to get used to it, then you will feel horrible if you miss the nap. :)
reply