301–310 of 483 posts
Because it's the most popular & flexible cross platform user space compositor: - unlike QT it's free for commercial use. - I don't know any other user land GUI toolkit/compositor that isn't a game engine(unity/unreal/etc).
Why does it need to be cross platform? If code was free there would be a native app for each platform using its respective toolkit, not QT.
clearly the code isn’t free and writing for raw win32 is painful.
Earlier quoted context omitted.
Yeah. Everyone sort of assumes that not having personally written the code means they can’t debug it. When is the last time you had an on call blow up that was actually your code? Not that I’m some savant of code writing — but for me, pretty much never. It’s always something I’ve never touched that blows up on my Saturday night when I’m on call. Turns out it doesn’t really change much if it’s Sam who wrote it … or Cl…
"hey coworker, I know your team wrote this, can you help?" Except there is no coworker, just Claude
It means Sam is 7 beers deep on Saturday night since you’re the one on call. He’s not responding to your slack messages.
Claude actually is there though, so that’s kind of nice.
Earlier quoted context omitted.
> An engineer should be code reviewing every line written by an LLM, I disagree. Instead, a human should be reviewing the LLM generated unit tests to ensure that they test for the right thing. Beyond that, YOLO. If your architecture makes testing hard build a better one. If your tests arent good enough make the AI write better ones.
It’s amazing how often an LLM mocks or stubs some code and then writes a test that only checks the mock, which ends up testing nothing.
But once you figure that out, it's pretty effective.
Earlier quoted context omitted.
As a user I would trade fewer features for a UI that doesn't jank and max out the CPU while output is streaming in. I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. (edit: this applies to the mobile app as well)
> a UI that doesn't jank and max out the CPU While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help. I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candi…
Earlier quoted context omitted.
> An engineer should be code reviewing every line written by an LLM, I disagree. Instead, a human should be reviewing the LLM generated unit tests to ensure that they test for the right thing. Beyond that, YOLO. If your architecture makes testing hard build a better one. If your tests arent good enough make the AI write better ones.
There’s no way you or the AI wrote tests to cover everything you care about. If you did, the tests would be at least as complicated as the code (almost certainly much more so), so looking at the tests isn’t meaningfully easier than looking at the code. If you didn’t, any functionality you didn’t test is subject to change every time the AI does any work at all. As long as AIs are either non-deterministic or chaotic (s…
You just hit the nail on the head.
LLM's are stochastic. We want deterministic code. The way you do that is with is by bolting on deterministic linting, unit tests, AST pattern checks, etc. You can transform it into a deterministic system by validating and constraining output.
One day we will look back on the days before we validated output the same way we now look at ancient code that didn't validate input.
You just have to be really careful because the agent can easily slip into JS hell; it has no shortage of that in its training.
Earlier quoted context omitted.
"hey coworker, I know your team wrote this, can you help?" Except there is no coworker, just Claude
"Yeah our team wrote it but everyone who built that part of it has moved to different teams or companies since."
Boris from the Claude Code team here. Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it. That said, engineering is all about tradeoffs and this may change in the future!
> Finally, Claude is great at it. So the model is not a generalised AI then? It is just a JS stack autocomplete?
Earlier quoted context omitted.
"hey coworker, I know your team wrote this, can you help?" Except there is no coworker, just Claude
Do you know what on call means? It means Sam is 7 beers deep on Saturday night since you’re the one on call. He’s not responding to your slack messages. Claude actually is there though, so that’s kind of nice.
Claude is there as long as you're paying,and I hope he doesn't hallucinate an answer.
Earlier quoted context omitted.
As a user I would trade fewer features for a UI that doesn't jank and max out the CPU while output is streaming in. I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. (edit: this applies to the mobile app as well)
Both Anthropic's and OpenAI's apps being this janky with only basic history management (the search primarily goes by the titles) tells me a lot. You'd think these apps be a shining example of what's possible.
it is