3
\$\begingroup\$

The 12 Days of Christmas Lyrics challenge has several solutions of the form "Use an external decompression utility on this file to create a solution.language file, then execute the decompressed file."

Does that count? If so, I'd expect every answer from now on to shave off bytes by using this technique. It just seems outside the spirit of golf to take credit for the bytes saved by a compressor.

I'd suggest that compressed solutions are only valid if they include a self-extractor.

\$\endgroup\$
8
\$\begingroup\$

Solutions that aren't 100% human-created aren't interesting in my eyes. The first one could have been, once, in the site's early days. But the trend I observe now is that they're becoming the default trick, just like UCS2 was a few months ago. So boooooring. And all the more demoralizing when the top voted answer in a thread is my solution, compressed by someone else. How lame can we get.

Solutions that aren't 100% human-readable could be okay if they're reasonably well explained, assuming the work to make them unreadable was human-performed, and seems task-specific enough.

I wouldn't like to see an arbitrary ban on any external library, though. I still see the search for the right way of doing things as a fundamental aspect of code golf. That includes finding the right tool for the job, who could be a library. In my opinion, the core issue is that we're seeing too many problems for which the right way of solving them is through dumb compression.

Obviously, is the usual suspect here. Maybe we should start devising a specific set of (default) rules for problems under that tag. I'd dream of simply punishing the problem submitter with downvotes when the winning entry is a compressed one, but that's far from populist enough to work. Our eternal September has started, and I'm not sure how to handle that gracefully.

\$\endgroup\$
1
\$\begingroup\$

Most (all?) of the compressed solutions in that thread, including mine, do include a self-extractor. It might be implemented using an optional module/library, but if that library ships with the language by default (as Compress::Zlib does with Perl, for example), then I really don't see how it could be disallowed in general.

Of course, individual challenges may well specify "no calls to zlib or other pre-written decompression libraries" if they want.

In the ASCII art hello world challenge I just posted, I required programs to be written using printable ASCII characters only; this doesn't rule out the use of external compression libraries, but it does handicap them. (Alas, it also rules out Piet, much of APL and other potentially interesting languages, so it's not a perfect solution. But it seemed to fit the theme of the question, so I went with it.)

\$\endgroup\$
  • \$\begingroup\$ I was looking at the parts that said "To unencode the program, you can use the following helper Perl script", and "To create the actual code from the hexdump, put it in a file and run xxd -r hexdump > 12days.rb." Reading closer, I guess those just take the web-displayable output into a language file, so I see your point. But I'm still not looking forward to seeing lots of solutions that consist of unreadable binary. \$\endgroup\$ – AShelly Dec 15 '11 at 22:52
  • \$\begingroup\$ I have a proposed solution to this. Any opinions you have on this would be welcome. :-) \$\endgroup\$ – Chris Jester-Young Dec 18 '11 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .