I have a blanket, unignorable 'files must be <= 1000 lines' lint for my Rust projects for exactly this reason. Exploring large files is _costly_ for agents, so it's much better to lean into the filesystem hierarchy to a greater extent than you would normally with a team of human developers.
The solution is to mandate that websites are built for browsers/devices as much as they are for humans. That way you never see a cookie banner because you've set up your device to never accept marketing cookies; A Google Maps link clicks through to Google Maps because you told your browser Google Maps was your preferred online mapping tool.
This reminds me of my experience as a senior contractor joining teams that seem to enjoy endless discussion. For example, when implementing a new feature using an open-source library or framework they will want to make a prototype of all possible libraries, make a report about each of them, have some big discussions about which to choose, and only _then_ start the real implementation. My advice is always to just pick the one your gut tells you is the right one -- if the prototype works, then that _is_ the implementation and we can stop considering alternatives unless we have a good reason to reconsider them.
If a decision is hard to make, its often because the differences are small, and therefore it doesn't matter much and you might as well decide by dice-roll.
> If a decision is hard to make, its often because the differences are small, and therefore it doesn't matter much and you might as well decide by dice-roll.
My life became soo much easier when I had that insight. I used to spend so much mental energy on decisions that most often were inconsequential.
That is often a different type of difficulties. I was thinking about decision like, should I buy car A or car B. I've done my research. Economy, safety, et c. are very similar. But it is a lot of money, and I don't know which is the "best", and of course I want the "best". I could spend weeks on a decision like this. Now I just acknowledge that they seem to be equal. Car B comes in a nice shade of red that I really like, so I buy car B.
Regarding your question, there's always going to be known and unknown unknowns down the line. My only advice in that case is to get to the unknowns as fast as possible. And from the start take into account that you most likely will have to rebuild a big part when you learn more. That is one of the reasons modularity and decoupling is so important. You want to be able to easily scrap and replace one part without it affecting everything. And keep it simple. Never try to build something that should be capable to handle all imaginable scenarios in the future. You'll be bitten by one of the unimaginable ones, and your complex "can handle everything" architecture will be too rigid to change.
I don't know what the black art of tool selection is, but I'm at least a couple std deviations above average on picking libraries that have legs. Nobody gets it right every time, but some people seem to get it wrong every time.
Be sure the work is given to someone who puts some intention into tool selection and you'll probably be okay though. We don't need three different tools doing the same kind of tasks. But sometimes the old old stuff gets moved to the new tool because the old tool couldn't handle that scenario.
As with quicksort, quickselect is generally implemented as
an in-place algorithm, and beyond selecting the kth
element, it also partially sorts the data.
When the above is applicable, those quickselect implementations would violate the original assertion of:
Only the median (or pair around the median) needs to be
sorted, the other numbers can be unsorted
Rust has testing in the standard library -- IMHO Bevy is far easier to test than most game engines because it's "just rust". You can test game logic by starting headless apps, proding the ECS, and making assertions on the results.
For acceptance tests I've dusted off cucumber (after ten years of not thinking about BDD), as I it works great with Bevy
Not OP but I'm currently make a city-builder computer game with a large procedurally-generated world. The terrain height at any point in the world is defined by function that takes a small number of constant parameters, and the horizontal position in the world, to give the height of the terrain at that position.
I need the heights on the GPU so I can modify the terrain meshes to fit the terrain. I need the heights on the CPU so I can know when the player is clicking the terrain and where to place things.
Rather than generating a heightmap on the CPU and passing a large heightmap texture to the GPU I have implemented the identical height generating functions in rust (CPU) and webgl (GPU). As you might imagine, its very easy for these to diverge and so I have to maintain a large set of tests that verify that generated heights are identical between implementations.
Being able to write this implementation once and run it on the CPU and GPU would give me much better guarantees that the results will be the same. (although necause of architecture differences and floating point handling they the results will never be perfect, but I just need them to be within an acceptable tolerance)
That's a good application but likely not one requiring a full standard library on the GPU? Procedurally generated data on GPU isn't uncommon AFAIK. It wasn't when I was dabbling in GPGPU stuff ~10 years ago.
If you wrote in open cl, or via intel libraries, or via torch or arrayfire or whatever, you could dispatch it to both CPU and GPU at will.
There are GPU-based picking algorithms. You really should not have to maintain parallel data generation systems on both the GPU and CPU just to support picking. Maybe you have a different issue that would require it, but picking alone shouldn't be it.
I remember DSL had a window manager that would allow you to merge applications into tabs ... it's nice having only one window ... I reminds me of the 50 MB operating system days. Except this time the browser doesn't suck ... I can't believe I'm watching youtube cat videos in iterm2 \m/
