News for hackers. Stuff that matters.
Re:An overengineered solution to `sort | uniq -c` with 25x t... by chii on Monday October 27, 2025 @03:07AM (#45718160)
> That is it's better to have prematurely optimised things than finding "everything is slow".

or you found that you've optimized a game that is unfun to play and thus doesn't sell, even tho it runs fast...

Re:An overengineered solution to `sort | uniq -c` with 25x t... by wongarsu on Monday October 27, 2025 @06:42AM (#45719435)
The best-practice solution would be to write a barely optimized ugly prototype to make sure the core idea is fun, then throw away the prototype and write the "real" game. But of course that's not always how reality works
Re:An overengineered solution to `sort | uniq -c` with 25x t... by chii on Monday October 27, 2025 @08:14AM (#45720090)
> not always how reality works

yep. The stakeholder (who is paying the money) asks why the prototype can't just be "fixed up" and be sold for money, instead of paying for more dev time to rewrite. There's no answer that they can be satisfied with.

Re:An overengineered solution to `sort | uniq -c` with 25x t... by mabster on Tuesday October 28, 2025 @05:38PM (#45739578)
Or the timeline just doesn't have capacity for experimentation so the expectations are clear right from the start!
Re:An overengineered solution to `sort | uniq -c` with 25x t... by mabster on Tuesday October 28, 2025 @05:37PM (#45739563)
In context most of the major optimisation work was on the engine. The game code can be and usually is slow but we do try to tame things in an O() sense.

I worked licensed titles for a while and that area the quality of a title and whether it sells were largely uncorrelated haha!