>
Rather, it stems from the obvious lack of real value that the hack added to the program. It's very unlikely that a standard loop would have degraded the program's performance in any noticeable way. Mel's testless loop was clearly a vain addition of complexity.Firstly, there is a false premise here which is that the story is about a great programmer who worked hard to do nothing but add real value to a program. Obviously, this is not so.
The story makes it clear by including detail like '"Even the initializer is optimized", [Mel] said proudly', where is it clear that Mel understands that the initializer runs only once, but he optimized it anyway. Some of what Mel did added value, and some of it was just done for Mel's own benefit of learning and self-actualization.
Secondly, it is not necessarily true that the testless loop isn't an optimization. We cannot assume that Mel was always optimizing for time. He probably optimized for code size in cases when optimizing for speed wouldn't make a difference.
If a program obeys the 80/20 rule, where 80% of its time is in 20% of its code, then you can make the biggest speed improvementsin 20% of the code. But then what do you do with the 80% of the code that doesn't execute often enough to make a difference? You can optimize that for size to end up with a small program that is still blazingly fast.
Size doesn't follow any 80/20 rule: 100% of the size of the program is evenly spread into 100% of the code. Shaving an instruction from anywhere makes it one instruction shorter, whether that instruction is in three levels of loop nesting, or initialization code that executes once.
Still, if the machine runs only one program, such as doing nothing else but providing that blackjack game, and if that program fits, there is no value in making it any smaller.