A Critique of GPUI
3 points by Jackevansevo
3 points by Jackevansevo
Any real argument here is undermined by the heavy use of LLMs to write the article, to the point that you wonder if there is any thought at all behind this or if it's just machine noise.
My advice to anyone who wants to be taken seriously is to think your own thoughts, discuss them with others capable of critical thinking, and then write them down in your own voice.
Maybe I'm getting old, but this article is not triggering my bogo sensor. What are you picking up as LLM here? I see sentences starting with conjunctions, I see missing hyphens, the structure promised in the opening paragraph looks to match the rough deliverable, there are callbacks/"foreshadowing" (call-forwards, since this is non-fiction? not sure what to call those), etc. I'm not even disagreeing as such, but this one doesn't seem superficially clanked
For me, when I read "It is a signal graph built by hand from much heavier parts, where a missed edge is silent." I tabbed back to this thread to see if someone else had raised the alarm.
I think rather than policing LLM or not, a more useful framing is to police bad writing or not. I found the article pretty confusing and I used to even work in this space.
The LLM tell for me is something like "the individual sentences are written much better than the larger incoherence of the text", and that can happen even in human-authored text.
"The only question that matters" as a headline is LLMese
"So every framework has to answer one question: when one value changes, what runs?" - this is LLMese
"Who finds the change" in small caps is LLMese
"What a write runs: Closures that read it" is extreme LLMese
"notify carries the entity id" is LLMese
"notify is more precise than a zone, since it names an entity, but ultimately it makes the same kind of statement" = LLMese
"On a linear axis, the cost per row is the slope" come on now
To address the actual claim of the article, I don't think it's very good. GPUI is most likely as fast as it needs to be to work for Zed and no faster because spending time to make it faster would mean spending less time on other things. Immediate mode is not inherently required to retain or cache less than a scene graph approach, the caching is just implicit as part of the render pass. The article even concedes this in that the framework has facilities for caching but they are rarely used in practice, because in practice things are fast enough.
My ADHD eyes and brain slid over every sentence, as if they were too smooth and every word perfect, but lacking any meaning or salient sentence to latch on to. It is like reading a corporate brochure. Whereas human writing is rough, inconsistent, imperfect. The words don’t always match the tone, there are spelling and stylistic mistakes. There are unusual choices of words. They always betray the inner workings of another human mind.
LLM writing tastes inoffensive and bland, and the content always too in-depth, too precise for its own good. Humans are lazy, and omit much more than they include.
I don't have ADHD, but as someone young / inexperienced / unknowledgeable about this particular subject, I had the same feeling. And I've been having that feeling a lot more recently, as the frontier models have learned to avoid the obvious tells that were common just a couple months ago.
There's a lot of human writing on the internet that is way above my level of understanding, but I always felt that there was something to grab onto, dig into, and learn from. With LLM writing, even though it's less obvious now, I still struggle to parse it.
It'd really help if people disclosed their use of AI to write. Because of my inexperience, my first instinct is to blame myself when I can't understand a paragraph after reading it three times. But I don't think anybody can be expected to reliably understand the nonsense that LLMs often put out.
In my view the titles on graphs are the biggest offender. Actually, not just the titles, the legends are also just a little bit too "linkedin", and refer to things not quite present in the text of the article. And when your graphs are really stinking of slop, it's hard to trust the numbers presented in them.
And then there's the fact that the whole article is ultimately comparing apples to oranges, taking retained mode GUIs and treating the fact that they aren't as easy to cache as retained mode GUIs as some sort of a revelation.
I agree. I read this article and can't not claim this is LLM written/assisted. But I wasn't triggered.
As I was recently debating using egui vs gpui I found this article a datum, with our without "purity".
Just a reminder: LLM writing should be flagged as spam.
Spam which should be used for content that either is designed to promote a commercial service or for content that is created without meaningful human authorship.
Emphasis mine. This is the most thorough breakdown of competing UI state management strategies I've ever read, and there is absolutely no chance this was created without meaningful human authorship.
I completely understand disliking the article because LLMs were obviously used in its writing, but this should unquestionably not be flagged as spam.
Without an AI usage disclosure, it's impossible to say how much was actually driven by the author. I genuinely can't tell if this was steered a lot by the author or it's just the result of a prompt like "research gpui and alternatives then benchmark them [using toolchains available to you on this box], make an article with the results and cite references and your methodology".
I personally read "without meaningful human authorship" as requiring more than just some minimal steering by an author, so I am flagging this as spam.
You're not paying me enough to spend my time evaluating the precise portion of LLM output -- and even if I were paid to make it my full time job, I'm not sure I could do it sufficiently accurately, nor am I sure that it matters. If it seems sloppy, I'm flagging it. There are plenty of other places on the internet that are happy to accept slop.
It's amazing how far a dumb imgui approach can scale. But I agree for quiescent apps, or lots of them, or very complex ones, read tracking really scales. It's a pity that the syntax of instrumented reads isn't great in most (all?) languages.