3 ms·

Claude Code's renderer is more complex than a game engine

40 points by dboon 8mo ago

chrisjj 8mo ago
And the further problem with this statement is any game engine comprises quite a lot more than merely a renderer.
andrewstuart 8mo ago
And it still can’t display Arduino .ino files as text.
Thristle 8mo ago
https://www.youtube.com/watch?v=LvW1HTSLPEk https://www.youtube.com/watch?v=LvW1HTSLPEk this statement is ridiculous and stinks of AI bro superiority
- jgbuddy 8mo ago
  Agreed
copilot_king_2 8mo ago
Too bad it can't write usable GDScript code.
SCdF 8mo ago
So erm, is this a good thing? I've only been using it for a month, but it quickly becomes incredibly laggy. I have to kill it completely and reopen it[1]. I've also had some unique hard locks never before seen on my machine[2], only while it's open and doing things. I also haven't noticed it outputting anything that would warrant it being more complex than ncurses or the current fashionable equivalent? [1] /clear helps but not 100%, and the time to get back to lag land increases each time [2] (Framework 13" AMD 7840U 32GB RAM)
- dboon 8mo ago
  It’s not a good thing, because it’s not a thing. The title is a sarcastic reference to the fact that it uses an order of magnitude more instructions per frame than SM64 did
  - SCdF 8mo ago
    Sorry, I was referring less to the sarcastic elements of this article and more the not sarcastic elements of the Claude Code engineer's post on Twitter / Bsky.
    - dboon 8mo ago
      Ah, I understand. Yeah, it read to me as a "good thing" in the sense of "look, it's slow, but it has to be slow". That the complexity was inherent and therefore in some sense good.
moregrist 8mo ago
> Claude Code is churing out an order of magnitude more instructions than SM64 did, to…diff a terminal panel’s worth of text and draw it. What bothers me is that the maintainer quoted at the beginning of the piece is holding this up as almost a virtue: look at this complex thing we've done! But... at its core it's a TUI rendered perhaps what is the most complex and least efficient way possible. I'm not part of a hypergrowth LLM company, but I do wonder why someone there would take such pride in such inefficient choices. And as someone who's been using TUIs for ... more years than I'd care to admit ... it's not a particulalry stunning example of one either. I like it fine. It mostly does the job. But it's pretty simple as TUIs go and I could think of ways it could be better.
dpiers 8mo ago
The title is a lie - the original statement was that it was closer to “a small game engine” than a basic text UI. CC has a complex scene rendering pipeline with a 16ms/frame budget. That is much closer to a game engine than a print statement.
uargos 8mo ago
What I don't understand is, with all the good tui frameworks/applications existing these days, how was Claude opus/sonnet/whatever not able to help anthropics engineer implement a normal approach ? I mean man, react before rasterizing ? Did any try that before ? That's clearly not what I would consider a good ad for their technology...
flowerthoughts 8mo ago
Yeah, and their customers have repeatedly asked them to stop doing that. For instance https://github.com/anthropics/claude-code/issues/2327 https://github.com/anthropics/claude-code/issues/2327 https://github.com/anthropics/claude-code/issues/2479 https://github.com/anthropics/claude-code/issues/2479 https://github.com/anthropics/claude-code/issues/4851 https://github.com/anthropics/claude-code/issues/4851 https://github.com/anthropics/claude-code/issues/3105 https://github.com/anthropics/claude-code/issues/3105 Latest news is that they've doubled down on it instead.
zizon 8mo ago
Isn't that exactly what React was designed for?
omnicognate 8mo ago
This accepts the idea that the flickering problem (which is what that comment was about) is to do with slow rendering. It isn't. The solution to the flickering is almost certainly trivial and it's in the open source Ink library that Claude Code uses. I outlined it in [1]. Basically, Ink clears lines before rendering the page. That's not how you render TUIs if you don't want them to flicker. All you have to do is write the lines, and include a clear to end-of-line at the end of each one. That means you overwrite what's there and only erase what is removed. Where nothing changes, nothing visibly happens. My comment [1] contains links to the source that needs changing, and I think it would probably be a single-digit line PR to fix it. I'm not going to do so because I neither use Claude Code nor really approve of it. It's hilarious that the quoted comment framed the issue as if it's rendering to a vsynced framebuffer and only has 16ms to do so, and everyone went with it. That's not how TUIs work at all. It's writing to stdout, ffs. [1] https://news.ycombinator.com/item?id=46853395 https://news.ycombinator.com/item?id=46853395

40 points by dboon 8mo ago

chrisjj 8mo ago

And the further problem with this statement is any game engine comprises quite a lot more than merely a renderer.

andrewstuart 8mo ago

And it still can’t display Arduino .ino files as text.

Thristle 8mo ago

https://www.youtube.com/watch?v=LvW1HTSLPEk https://www.youtube.com/watch?v=LvW1HTSLPEk this statement is ridiculous and stinks of AI bro superiority

jgbuddy 8mo ago
Agreed

copilot_king_2 8mo ago

Too bad it can't write usable GDScript code.

SCdF 8mo ago

So erm, is this a good thing? I've only been using it for a month, but it quickly becomes incredibly laggy. I have to kill it completely and reopen it[1]. I've also had some unique hard locks never before seen on my machine[2], only while it's open and doing things. I also haven't noticed it outputting anything that would warrant it being more complex than ncurses or the current fashionable equivalent? [1] /clear helps but not 100%, and the time to get back to lag land increases each time [2] (Framework 13" AMD 7840U 32GB RAM)

dboon 8mo ago
It’s not a good thing, because it’s not a thing. The title is a sarcastic reference to the fact that it uses an order of magnitude more instructions per frame than SM64 did
- SCdF 8mo ago
  Sorry, I was referring less to the sarcastic elements of this article and more the not sarcastic elements of the Claude Code engineer's post on Twitter / Bsky.
  - dboon 8mo ago
    Ah, I understand. Yeah, it read to me as a "good thing" in the sense of "look, it's slow, but it has to be slow". That the complexity was inherent and therefore in some sense good.

moregrist 8mo ago

> Claude Code is churing out an order of magnitude more instructions than SM64 did, to…diff a terminal panel’s worth of text and draw it. What bothers me is that the maintainer quoted at the beginning of the piece is holding this up as almost a virtue: look at this complex thing we've done! But... at its core it's a TUI rendered perhaps what is the most complex and least efficient way possible. I'm not part of a hypergrowth LLM company, but I do wonder why someone there would take such pride in such inefficient choices. And as someone who's been using TUIs for ... more years than I'd care to admit ... it's not a particulalry stunning example of one either. I like it fine. It mostly does the job. But it's pretty simple as TUIs go and I could think of ways it could be better.

dpiers 8mo ago

The title is a lie - the original statement was that it was closer to “a small game engine” than a basic text UI. CC has a complex scene rendering pipeline with a 16ms/frame budget. That is much closer to a game engine than a print statement.

uargos 8mo ago

What I don't understand is, with all the good tui frameworks/applications existing these days, how was Claude opus/sonnet/whatever not able to help anthropics engineer implement a normal approach ? I mean man, react before rasterizing ? Did any try that before ? That's clearly not what I would consider a good ad for their technology...

flowerthoughts 8mo ago

Yeah, and their customers have repeatedly asked them to stop doing that. For instance https://github.com/anthropics/claude-code/issues/2327 https://github.com/anthropics/claude-code/issues/2327 https://github.com/anthropics/claude-code/issues/2479 https://github.com/anthropics/claude-code/issues/2479 https://github.com/anthropics/claude-code/issues/4851 https://github.com/anthropics/claude-code/issues/4851 https://github.com/anthropics/claude-code/issues/3105 https://github.com/anthropics/claude-code/issues/3105 Latest news is that they've doubled down on it instead.

zizon 8mo ago

Isn't that exactly what React was designed for?

omnicognate 8mo ago

This accepts the idea that the flickering problem (which is what that comment was about) is to do with slow rendering. It isn't. The solution to the flickering is almost certainly trivial and it's in the open source Ink library that Claude Code uses. I outlined it in [1]. Basically, Ink clears lines before rendering the page. That's not how you render TUIs if you don't want them to flicker. All you have to do is write the lines, and include a clear to end-of-line at the end of each one. That means you overwrite what's there and only erase what is removed. Where nothing changes, nothing visibly happens. My comment [1] contains links to the source that needs changing, and I think it would probably be a single-digit line PR to fix it. I'm not going to do so because I neither use Claude Code nor really approve of it. It's hilarious that the quoted comment framed the issue as if it's rendering to a vsynced framebuffer and only has 16ms to do so, and everyone went with it. That's not how TUIs work at all. It's writing to stdout, ffs. [1] https://news.ycombinator.com/item?id=46853395 https://news.ycombinator.com/item?id=46853395