i think the sad pattern I see in a lot of these code golf implementations is the solution score is based on Lines of Code, which we already agree is a POOR representation of either complexity or simplicity.
I think it would be far more interesting to measure number of instructions to complete the objective. Though I suspect the folks familiar with assembly would run circles, perhaps you could segment by solution language?
Given the entirely whimsical and (hopefully) intentionally rebellious nature of Code Golf, I don't think that worrying about the usefulness of the metric is really worth it.
You may be interested in http://www.zachtronics.com/tis-100/. It's essentially a code golf game with many different metrics to optimize including number of instructions.
The reason lines of code is a poor way to score solutions is that you should be counting characters! :-)
My favorite Perl golf challenge is something I got from Boston Perl Mongers many years ago:
You have the numbers 1 to 9 (in order), and in between each number you can insert a plus, a multiply, or nothing. Your program should print all expressions that evaluate to 2002. For instance it should print the solution
1*23+45*6*7+89
(and one other)
I have a command-line solution in 80 characters, including the `perl ` at the beginning. It works on 5.10 and 5.16. I think there was a better solution back in the 5.8 days, but my notes are unclear.
Comments
i think the sad pattern I see in a lot of these code golf implementations is the solution score is based on Lines of Code, which we already agree is a POOR representation of either complexity or simplicity.
I think it would be far more interesting to measure number of instructions to complete the objective. Though I suspect the folks familiar with assembly would run circles, perhaps you could segment by solution language?
Given the entirely whimsical and (hopefully) intentionally rebellious nature of Code Golf, I don't think that worrying about the usefulness of the metric is really worth it.
You may be interested in http://www.zachtronics.com/tis-100/. It's essentially a code golf game with many different metrics to optimize including number of instructions.
wow, thanks! great line: "It’s the assembly language programming game you never asked for!"
It's DRM-ed, sadly.
Not anymore: http://www.gog.com/game/tis100
The demoscene may be of interest if you're into optimising the binary for size and not the source:
http://www.hugi.scene.org/compo/
That one seems abandoned for a few years now but you can find plenty of tiny graphical effects here, executables are 512 bytes and below:
http://www.pouet.net/prodlist.php?type%5B%5D=32b&type%5B%5D=...
The reason lines of code is a poor way to score solutions is that you should be counting characters! :-)
My favorite Perl golf challenge is something I got from Boston Perl Mongers many years ago:
You have the numbers 1 to 9 (in order), and in between each number you can insert a plus, a multiply, or nothing. Your program should print all expressions that evaluate to 2002. For instance it should print the solution
(and one other)I have a command-line solution in 80 characters, including the `perl ` at the beginning. It works on 5.10 and 5.16. I think there was a better solution back in the 5.8 days, but my notes are unclear.
Once you know the other solution you can do much better than 80 characters!
Lines of code is a poor representation, but non-whitespace characters is a somewhat better one. Perl golf and vim golf both use that.
You are not describing code golf, though. "A sad pattern in chess is checkmate; the goal should be to eliminate the other player entirely."
I agree what you describe would be fun, too, but it isn't code golf.