I imagine lots of games do already, but offline. Most games don’t have gameplay that requires real-time terrain generation. The idea of generating terrain procedurally is not new, but this technique that gets a great-looking erosion effect in real time is.
As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.
> As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process
And yet, plenty of people all around the world are able to get traction for their products without mentioning the hate of another.
> I didn't build Qite because I hate React,
I get that React being the most popular front-end framework means it's going to get it's fair share of criticism, but it's become pathetic the degree to which people have made hating it their personality. Even going so far as to market their own frameworks in terms of their personal feelings towards it.
Nobody is saying humans aren't emotional, you're trying to deflect from being unable to disconnect your emotions from another library.
I dislike React because it’s large, slow, and completely unnecessary. If I can write a spa that both 10x faster and 10x smaller without it then why would I bother with React? That isn’t any kind of syndrome. It’s me not wasting my time on vanity bullshit.
I really think autism has a lot to do with the necessity of large frameworks. They provide a vanity layer to hide behind for people who cannot introspect and cannot measure.
> I dislike React because it’s large, slow, and completely unnecessary.
You're personal opinion is irrelevant to the point I'm making. And that's exactly my point. For whatever reason people can't stop talking about their dislike for it. Going so far as to literally have it be your framework's tagline.
You can't even read a comment about Svelte without their need to bring React up.
> I really think autism has a lot to do with the necessity of large framework
No it's because the needs of the web have dramatically changed in the last 20 years. That's why people reach for things to help them build front-end apps. It's almost comical how different it is.
Interesting to note how similar this seems to what happened with Benj Edwards at Ars Technica. AI was used to extract or summarize information, and quotes found in the summary were then used as source material for the final writing and never double checked against the actual source.
I’ve run into a similar problem myself - working with a big transcript, I asked an AI to pull out passages that related to a certain topic, and only because of oddities in the timestamps extracted did I realize that most of the quotes did not exist in the source at all.
It might be a solved problem in the sense that it has a possible solution, but not in the sense that it doesn’t happen with the tools most people would expect to be able to handle the task.
That’s an interesting approach, but what do you learn from it that is applicable to the next task? Do you find that this eventually boils down to heuristics that generalize to any task? It sounds like it would only work because you already put a lot of effort into understanding the constraints of the specific problem in detail.
I wonder why they fail this specific way. If you just let them do stuff everything quickly turns spaghetti. They seem to overlook obvious opportunities to simplify things or see a pattern and follow through. The default seems to be to add more, rather than rework or adjust what’s already in place.
I suspect it has something to do with a) the average quality of code in open source repos and b) the way the reward signal is applied in RL post-training - does the model face consequences of a brittle implementation for a task?
I wonder if these RL runs can extend over multiple sequential evaluations, where poor design in an early task hampers performance later on, as measured by amount of tokens required to add new functionality without breaking existing functionality.
Yeah I've been wondering if the increasing coding RL is going to draw models towards very short term goals relative to just learning from open source code in the wild
To me this seems like a natural consequence of the next-token prediction model. In one particular prompt you can’t “backtrack” once you’ve emitted a token. You can only move forwards. You can iteratively refine (e.g the agent can one shot itself repeatedly), but the underlying mechanism is still present.
I can’t speak for all humans, but I tend to code “nonlinearly”, jumping back and forth and typically going from high level (signatures, type definitions) to low level (fill in function bodies). I also do a lot of deletion as I decide that actually one function isn’t needed or if I find a simpler way to phrase a particular section.
Edit: in fact thinking on this more, code is _much_ closer to a tree than sequence of tokens. Not sure what to do with that, except maybe to try a tree based generator which iteratively adds child nodes.
This would make sense to me as an explanation when it only outputs code. (And I think it explains why code often ends up subtly mangled when moved in a refactoring, where a human would copy paste, the agent instead has to ”retype” it and often ends up slightly changing formatting, comments, identifiers, etc.)
But for the most part, it’s spending more tokens on analysis and planning than pure code output, and that’s where these problems need to be caught.
I feel like planning is also inherently not sequential. Typically you plan in broad strokes, then recursively jump in and fill in the details. On the surface it doesn’t seem to be all that much different than codegen. Code is just more highly specified planning. Maybe I’m misunderstanding your point?
reply