7
\$\begingroup\$

This conversation popped up in chat at one point.

There is a subtle (yet important) distinction between code golfing and sizecoding: code golfing is an attempt to reduce the human readable source code, while sizecoding is an attempt to reduce the machine code.

Is sizecoding under the general heading of "Programming Puzzles", and therefore on topic, or not?

\$\endgroup\$
4
  • 2
    \$\begingroup\$ A question though: 1. How would you submit these? There is a common minimal executable size of about 670 bytes. Common categories are 1k, 4k, 8k, 64k. Would you require a hexdump or just the total amount of bytes? 2. How'd you prevent malicious entries? On this site here we don't really have any "realworld" penalties. I'd suggest that including a compilable source must be a mandatory requirement (as well as a binary - because compiling sizecode binaries is often a very complex and increasingly proprietary process) \$\endgroup\$
    – user42643
    Oct 28, 2015 at 20:07
  • \$\begingroup\$ Aaand another remark: We already have answers that use x86 machine code :). \$\endgroup\$
    – user42643
    Oct 28, 2015 at 20:10
  • \$\begingroup\$ @mınxomaτ Please add these comments as parts of an answer. :P \$\endgroup\$
    – Addison Crump
    Oct 28, 2015 at 20:12
  • \$\begingroup\$ How do you define machine code? Should it be anything executable? Will a text file with a shebang count? What about .NET programs? I guess one options would be to fix the output format (i.e. "64bits elf binary" or "MSDOS COM file"); if you don't peoples will start designing their own CPUs specially shaped to win those challenges in the same ways they designed things like Pyth or C-Jam (bottomline: you could probably design a CPU to natively run C-Jam or Pyth). \$\endgroup\$
    – LeFauve
    Nov 8, 2015 at 5:32

2 Answers 2

Reset to default
11
\$\begingroup\$

Size coding is on topic; I agree with Peter Taylor that an objective winning criterion can be in theory formed. However, it doesn't seem to have many advantages over questions, which as @mınxomaτ pointed out are commonly answered in machine code.

Here are some issues that may come up:

  • Interpreted languages are automatically excluded, and languages without short binaries won't be competitve. We generally discourage questions with language restrictions.

    • Should competitors be forced to use a single language/compiler?

  • What counts as machine code anyway? Should bytecode be allowed?

  • Optimizing an answer for size will require repeatedly making changes to the source, then recompiling and measuring the binary size. No one wants to do that.

Of course, there's another way to write answers for sizecoding challenges, which leads to a problem:

  • What if people write the machine code first? It's possible to know the exact machine code that is optimal or near-optimal for a given challenge, but not be able to write a program that compiles to it! Why should we restrict machine code submissions to those generatable by a compiler?

    • For short challenges, this will probably be the case, and the challenge will be to get the compiler to spit out the correct thing.

    • This is assuming inline assembly is disallowed. If it's allowed, solutions written in assembly "in C" will win every time, and their authors will essentially be golfing in machine code.

In conclusion, although it is not off-topic, would eventually reduce to a more tedious form of in machine languages.

\$\endgroup\$
6
  • \$\begingroup\$ If bytecode is allowed, why would interpreted languages such as python be excluded? \$\endgroup\$
    – Blue
    Oct 29, 2015 at 15:52
  • 3
    \$\begingroup\$ @muddyfish Good point, but if bytecode is allowed, then what counts as bytecode? I could write an language called "Sizecode Pyth". It's the same as regular Pyth, and to compile into Pyth you use cat (i.e. do nothing). This issue seems worse to me than excluding interpreted languages. \$\endgroup\$
    – lirtosiast
    Oct 29, 2015 at 16:08
  • \$\begingroup\$ I wouldn't call pyth bytecode because it compiles down into python which in turn compiles down into python bytecode which runs in the python vm. Java also runs bytecode as well on its own virtual machine. But I see your point in general. \$\endgroup\$
    – Blue
    Oct 29, 2015 at 16:19
  • \$\begingroup\$ I don't see why codesizing challenges entries would need to be compiled by a compiler; the goal is to provide a small executable; assembling it by hand would provide more opportunities for optimization than using a compiler. \$\endgroup\$
    – LeFauve
    Nov 8, 2015 at 5:20
  • \$\begingroup\$ @LeFauve Then sizecode would just become code-golf in machine code. That isn't necessarily a bad thing, but we often discourage language-specific questions. By current standards, to be good questions, they should be exceptionally interesting. Machine code could be different, because there's a good reason to exclude other languages, but that's another issue. \$\endgroup\$
    – lirtosiast
    Nov 8, 2015 at 5:29
  • \$\begingroup\$ @ThomasKwa What I mean is by assembling by hand, you can do pretty neat stuffs like self modifying code, which can be really great (a little hard to use on modern CPU though, but who said you cannot propose a solution running on old hardware?) of course, if you allow self modifying code you de-facto allow self extracted compressed code, which sounds a little more like cheating. While sizecoding sounds like a nice idea, it may be hard to implement rules preventing cheating. \$\endgroup\$
    – LeFauve
    Nov 8, 2015 at 5:40
4
\$\begingroup\$

Sizecoding looks like in principle it should give an objective winning criterion, so it looks on-topic. I say "in principle" because unless you require answers to be in assembly I'm not sure how reproducible the machine code would be.

\$\endgroup\$

You must log in to answer this question.

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