An obvious point that took me way too long to appreciate: in software engineering, you should probably optimize for speed even when you don't have to, because it's one of the easiest/best ways to prioritize subtraction and parsimony in the solution space. https://www.nature.com/articles/d41586-021-00592-0 ….
-
This is not very good analysis. It omits the 'devil you know' and 'fools rush in' cautions that I think are intuitive. Yes it's expensive to default to add - but you don't run the risk that the previous structure, which you may not understand, won't collapse.
If you don't understand the previous structure, you are already f'd and fixing that is the #1 priority.
-
-
That wasn't the question scenario in the Nature article: ppl were shown a view, not how it got there or what might be out of sight. And yeah, sure, but somehow tech debt creeps up: and one reason is that not everyone can review let alone fix whole stack, so build what they can.
-
Im unqualified to comment here, but I definitely love Jonathan Blow as a game dev, and John Manoochehri as an AEC thought leader. The Witness is maybe the only game I actively tried to 100%... then found even more environmental puzzles to solve
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.