New puzzle type: code-shuffleboard

Question

Before I discovered that code golf was "a thing", I'd played against myself quite a bit. Often, I'd get down to 104 characters, say, and crank on it until I could get it to 100. But, if I can't get it below 90, I like to get it back to 100, 'cause it's nice and round. I deem this "code shuffleboard".

The idea behind code shuffleboard is to implement an algorithm in exactly a certain number of bytes. Of course, it's trivial to inflate a golfed solution by adding whitespace, using longer variable names, etc. So, the rules would be:

• No unnecessary whitespace
• All variable / function names (if applicable to your language) defined in the code must be 1 letter (unless you run out of letters, then you can use 2-letter variables)
• No comments
• No useless code: deleting anything from the program must break it

In short, every character must contribute nontrivially to the functionality of the program.

Would other people participate in this? For a twist, one could require that the code fit inside of a certain sized rectangle, with no room to spare (though, that would risk favoring J/GS overly much).

Answer 1

I don't think it's such a good idea.

If I try to press the last byte out of my code, I often find a byte here and there, and another one later.

Collecting 3-4 techniques and reversing them would allow me to add some unnecessary, but hard to tell bytes to the code.

Examples: * In implementing rot13, I switched from f('A','Z') to f(65,90). In statically typed languages, it often only pays off, if you have enough invocations, to save a '.toChar' which gets necessary, by using Ints. So this will be hard to verify. * Sometimes a linebreak can be avoided:

 def foo(a:Int)=a match{
 case 42=> ...

can be written as

 def foo(a:Int)=a match{case 42=> ...

surely something I would do, to win a golf, but spot it in other peoples code? In languages, which I don't know that well?

In a code-golf, you have to find a clever solution, to enter - for example - the range of 90-110 chars, and then you may optimize some whitespace away, and here a bit and there. Then you land at 70-90 chars. But it's not a very creative process.

You collect some tricks over the months, and can apply them on every 2nd or 3rd solution you provided.

Another one:

def s(a:String,b:String,c:String)=...

can be golfed by type S=String def s(a:S,b:S,c:S)=...

You have to count and measure, whether it is a win in the end - it consumes much time, and is not very funny or challenging.

To submit a solution - if we think about something like 'must be divisible by 10' you need to produce a solution, and then work on it, even if you would notice, that you can't reach for example another solution with 90 chars, because you have 124 chars. Your approach might be different, and your language, but you now have to find a way to add 6 more characters, which don't look superfluous.

The 400-questions-challenge was a kind of such a challenge, but it was hard to reach such a short code, and increasing the length of a solution is a new challenge, but only once.

I guess: As a category, it will not work.

• It's not creative in the long run
• It's too hard to check, especially, if you aren't master of a language
• It will lead to debates where to draw the borderline

Answer 2

Just going to throw this out there as an idea. Why not try something a little more mixed?

Keep the intent of "lowest character count" (or similar goal), but as an additional criteria, the character count has to satisfy some extra condition.

For example, instead of "Code must be 100 characters", it could be "Shortest code with a character count that is a multiple of 10". Then, if you ended up with, say, 97 characters, you could pad the code an extra 3 characters for 100. Or you could see if you could cut off a whole 7 characters to end with 90 for a better victory. The end result is that you do get results that end in whole numbers, but still retains reasoning that inhibits putting fluff for fluff's sake.