It's only "compressed" if it was made by compress(1) in France. Otherwise it's just sparkling entropy coding.
For reference:
1490 xmas-with-leading-comment.c
913 xmas-without-leading-comment.c
2357 xmas.out
1297 xmas.out.9.Z
1038 xmas.out.10.Z # actually better than with more bits!
1048 xmas.out.11.Z # compression with 11..16 bits have the same size
319 xmas.out.1.gz # compression levels 1..2 has same size
317 xmas.out.3.gz
307 xmas.out.4.gz # compression levels 4..9 have same size
Note that despite looking hard I haven't found a version of `compress` that supports `-H`, which is referenced and decompressable by gzip. I'm not sure how common it was in the wild.
% gcc xmas.c
xmas.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
2 | main(t,_,a)
| ^~~~
xmas.c: In function 'main':
xmas.c:2:1: warning: type of 't' defaults to 'int' [-Wimplicit-int]
xmas.c:2:1: warning: type of '_' defaults to 'int' [-Wimplicit-int]
% wc -c <xmas.c
913
% ./a.out | wc -c
2359
% ./a.out | compress | wc -c
1048
zstd -19 compresses the text of the song to 309 bytes.
To be a fair comparison, though, you'd have to write zstd -d in 604 bytes. I suppose to be REALLY fair, though, you have to count the bytes of code in the compiler itself. A convenient enough implementation of compression could index into the C compiler binary to find the bytes it needs. (For example, my GCC contains "first", "second", and "third" in the binary, which a sufficiently clever implementation could make use of. "Exit on the first error occurred.", "Append a second underscore if the name already contains an underscore.", "Warn about suspicious calls to memset where the third argument is constant literal zero and the second is not.", etc. I didn't check but I doubt turtle doves or maids-a-milking come up that often in the description of warning flags.)
And that comment was clearly written in 1988. I fail to see what's so hard to understand about that and why people feel the need to "prove" it's "wrong".
I don't think people are trying to prove it's wrong. Most of the comments are saying that general purpose technology in 2023 doesn't reduce the file size by as much as the manual job in 1988 did.
This particular entry to the IOCCC was for 1988, those two algorithms didn’t come about for a few more years after that, gzip in the early nineties and 7z later that decade. The note is probably correct when comparing against the state of the art at the time.
The program that produces the song, without the introductory comment, is 913 bytes, as presented in the article. Removing whitespaces it uses just 800 bytes and produces the song which is 2359 chars here. The whole C is:
Since the word 'compressed' is in quotes they are probably suggesting that they mean when processed by the 'compress' command as available on UNIX at the time, as opposed to some other compression available at the time.
The program was written in 1988. I ran the text through LZSS which was published in 1982, so was available before 1988. I used a 1989 public domain version by Haruhiko Okumura, which is after 1988, but I don't believe it is optimized to improve upon the compression level of the 1982 algorithm.
It took it from 2357 bytes to 534 bytes, which is smaller than the Xmas.c program which I counted as 917 bytes, but another poster counted 913 bytes.
For reference:
Note that despite looking hard I haven't found a version of `compress` that supports `-H`, which is referenced and decompressable by gzip. I'm not sure how common it was in the wild.