3 ms·

It's not misleading at all. It could have been 512 of the same character. It's not about how it can be stored more efficiently, it's just to visually demonstrat

by LocalH 7y ago

It's not misleading at all. It could have been 512 of the same character. It's not about how it can be stored more efficiently, it's just to visually demonstrate 512 bytes, which requires 512 characters (in straight ASCII anyway).

necovek 7y ago
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.
- shakna 7y ago
  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)
  - necovek 7y ago
    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.

by LocalH 7y ago

necovek 7y ago

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.

shakna 7y ago
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)
- necovek 7y ago
  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.