10
\$\begingroup\$

I was under the impression that the point in code-golf was to generate the shortest source code in some programming language.

However, some of the answers are binary files, e.g. MS-DOS .com files. Now don’t get me wrong, obviously there’s no problem with posting these, especially if the solution is elegant and interesting. But should the compiled/assembled binary be considered for the length of the code?

If so, would it be similarly acceptable to write the solution in C/C++, use a code-size super-optimising compiler to generate a binary, and then claim the size of the compiled binary as the score? What about managed code, e.g. JVM bytecode, .NET IL, Parrot, etc.?

\$\endgroup\$

4 Answers 4

Reset to default
22
\$\begingroup\$

I see no good reason not to allow machine code submissions in code golf challenges — it's a programming language, same as any other, and should not be unfairly discriminated against.

I would recommend, though, that any machine code submissions be accompanied by the corresponding assembly code, just to make them more readable to visitors who may not have a disassembler handy. But that's just common courtesy.

\$\endgroup\$
1
  • 11
    \$\begingroup\$ If there is corresponding assembly, then the assembly character count should be the score. My 'c' compiler may be able to reduce reduce y=m*x+b; into a single instruction word, but I stil get dinged for 8 characters. You should be scored on the language you write in, not your compiler's output. (Unless you really are writing in raw binary...) \$\endgroup\$
    – AShelly
    Jan 31, 2012 at 19:31
2
\$\begingroup\$

Anarchy Golf does indeed allow submitting binary files for submissions. But remember, many executable files have headers, and those take up space too. So often you'll find that they do not give you an advantage, unless you're a hardcore object code coder.

I encourage people writing questions to clarify whether they permit object code answers, by listing the winning criterion as either smallest code size or smallest source code size, as the case may be.

\$\endgroup\$
1
  • 6
    \$\begingroup\$ The reason that user (I've seen only one) posts MSDOS .com files is that they're pure headerless assembled code. I believe the OP's grievance is that gazing at binary is just boring, be it ASCII or Base64. (disassemblies are seldom there, and uninteresting in themselves) I concur. I don't think binary qualifies as a programming language by default (because most people can't read it back), and consider using an assembler as a compressor a bit lame. OTOH assembly, by nature, usually starts with a huge disadvantage. That comment's too long, I should've made it an answer. Drat. \$\endgroup\$
    – J B
    Mar 28, 2011 at 19:36
-1
\$\begingroup\$

I think the community will handle this one by voting and it doesn't need to be answered that badly. In most cases, though, I think binaries would be off limits because they couldn't reside directly in the answer; this is not a coincidence, because code is almost always text. There are corner cases like Piet, and naturally lots of challenge opportunities, where it would be better to let the votes decide than make a hard and fast rule.

This brings up other issues, though -

  1. Answers that use machine-generated source-code, e.g.
    • Answers that use J's : operator to get tacit definitions
    • Answers like this example where lambdabot is used to go from points to point-free.
    • Esoteric cases: Using a 'Whitespace' compiler to compile to Whitespace (I've done this on SPOJ where it's not such a big deal)
  2. Image-based languages (Smalltalk & Self)

Maybe those should be discussed elsewhere?

\$\endgroup\$
2
  • \$\begingroup\$ @Timwi: Yeah, too clever, I guess. Or maybe too clever in my own head? \$\endgroup\$
    – Jesse Millikan
    Mar 23, 2011 at 3:59
  • \$\begingroup\$ I do think binary is very different from tool-assisted golfing. J tacit definitions and lambdabot-assisted golfing are still the same language as the original, and there's a fine point when tacit/point-free becomes longer than explicit/pointed. Binary is (usually) not the same nature as assembly language, and always shorter. \$\endgroup\$
    – J B
    Mar 28, 2011 at 19:21
-1
\$\begingroup\$
  • Binary code needs often a certain hardware and a certain OS, so it is hard to test.
  • Binary code might be hard to read/submit - UUencoding would be a solution, but checking the code size needs an extra step here.
  • How is dynamically linked code handled? As usual? :)

If not explicitly allowed, it should be disallowed. For special purpose, I don't see a reason to disallow it in general. In the concrete circumstances, machine and OS, submission form and so on can be specified case by case.

\$\endgroup\$

You must log in to answer this question.

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