I'd counter and agree it's misleading. Repeating a word "pacman" int(512/len(word)) times does not give me the idea of how small 512 bytes is. It actually looked like a lot of text to me (whereas my description of that comment fit in ~45 characters).

If the original code was 512 (well, 510 if you deduct the signature, 446 if you also include the DOS partition table) bytes of asm source code, then the analogy might make sense.

Yet your whole refutation, which is quite a small comment, a couple of lines is 432 characters.

512 characters isn't a whole heap. It's more than some, but not a lot, and less than the kind of binary most languages do produce today.

A visual demonstration doesn't need to be nitpicked. (293)

As you say yourself, my comment not saying much being almost 500 bytes tells me more how tiny 500 bytes is, than the "visual demonstration".

The fact that it is so, tells me that the visual demonstration is off. I am not the only one who feels that way, so while it's definite that any visual demonstration will fail with some, this one seems to fail with many.

That, to me, is a bad visualisation, and defeats the purpose of the visualisation: you may call it nitpicking, I just call it bad use of a tool (visualisation and analogy). I even feel it confuses the scale, instead of clarifying it, which means that it should be called out.

Note that at no point was I claiming that 512 bytes is a lot, which you seem to also be arguing against. FWIW, I've written bootloaders in my high school days in 446 bytes, so I understand how little that is, even if one uses BIOS to drive the keyboard and the screen.