‹ BackHN Continuity

Thread

Once Claude can measure something, it can make it faster

231 points · 153 comments · matthieu_bl

  1. applfanboysbgon · · focus · HN ↗
    tl;dr if you make absolute dogshit software that takes 4.38 seconds to stabilize its first paint you can make really nice headline claims by "optimizing" it later
    1. sashank_1509 · · focus · HN ↗
      Unironically true, can someone question, what is Claude desktop app doing that needs 500k+ lines of code?

      Agents complicate something that should be much smaller and simpler and then agents speed it up adding more complexity. I suppose functionally you may say this is fine but aesthetically it is hideous!

      1. applfanboysbgon · · focus · HN ↗
        There is nothing even functionally fine about this. The me who has programmed for a 4mhz computer with 128kb of RAM is crying inside. It's a fucking trivial interface for writing and displaying text and sending HTTP requests. You could have that displayed ~instantly on an 80s home PC. Now we have home computers that can execute somewhere between billions and trillions of instructions per second and yet a task that should take <10ms takes 4500ms. Our industry has become an absolute embarrassment.
        1. Daishiman · · focus · HN ↗
          The Claude CLI does a lot more....
          1. applfanboysbgon · · focus · HN ↗
            This article is about the graphical interface, not the CLI.
            1. aesthesia · · focus · HN ↗
              The Claude graphical interface does a lot more...
              1. applfanboysbgon · · focus · HN ↗
                Sure, sure. There is still absolutely nothing it does that warrants such a slow paint (including the "optimized", still >1000ms paint).
                1. aesthesia · · focus · HN ↗
                  Definitely, but hyperbole about feature parity on a 4 MHz CPU with 128k of RAM doesn't help. I have conversations with Claude that wouldn't fit in that amount of memory.
        2. adamddev1 · · focus · HN ↗
          Thank you. The apps created like this are absolutely an embarrassment. But to me the bigger horror is if people are going to be convinced to develop the critical libraries and infrastructure in the same way. Then we'll have bloat and rot in the deeper levels and everything will become exponentially worse and unreliable. It makes me so sad that people can't see this.
      2. bigwheels · · focus · HN ↗
        TempleOS had kernel, compiler, 2D and 3D graphics drivers + libs, and tons of games and applications and the entire thing weighed in at less than 100kloc.

        AI coding agents of today definitely bloat things up [egregiously].

        1. theshrike79 · · focus · HN ↗
          On the other hand applications on TempleOS are expected/assumed to be perfect and have no bugs. It makes things a lot simpler =)
        2. phoghed · · focus · HN ↗
          That’s pretty cool. What are you using temple os to do?
      3. winstonp · · focus · HN ↗
        the codex desktop app bundles libreoffice's libraries. i wouldn't be surprised if claude does something similar.
        1. sashank_1509 · · focus · HN ↗
          This 500k lines doesn’t count libreoffice source code etc afaict.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.