|
This idea you had, interestingly, has nasty traps. 1. You need to specify an “origin” which is (0,0). This is hard because there is more than one good choice (base or top of a brick?), the structure base may be more than a single brick wide, and you still need an orientation for the base bricks relative to the table, since if they’re at an angle, it isn’t the same. 2. This fails, or at least complicates, on structures that are not fully connected, like 2 towers next to each other. XYZ doesn’t have tools for two towers, rotated, at an angle not parallel to the table. 3. You’re fucked on units if there are any “small” half bricks in the structure, which are common in lego sets. 4. It’s not human optimized. If you forget the origin (easy in a big structure, you fail. It’s not a bad idea, for some forms of the problem, but this underconsideration is why explaining things is hard. |
I've had to explain to folks many times (and convince myself) that at some point, once you recognize there are multiple valid 'good' options, you need to move forward. There's often little long term benefit to identifying the 'better' or 'best' option for many projects - you just need an agreed consensus on the ground rules.
Also, what seems to be left off of these exercises sometimes is the concept of subroutines. At some point, rather than giving you explicit instructions for PB&J (like, extend hand, move towards knife, curl fingers around knife handle, move arm back to original position, etc), that can be coded as a named macro/subroutine, and we can just say "grab knife". (or... "grab knife by handle!")