# Reconsidering the Code-Golf tag for questions [duplicate]

I was reading a question on Meta discussing how this site fits into the mission of Stack Exchange. A lot of the answers and comments all point to the same thing, that this site gives us a chance to look into different possible ways of problem solving in our favorite languages.

The problem is, this site has become dominated by code-golfs. On it's own, that's not really a problem. The problem is that there are languages specifically designed for that purpose that don't really serve purposes in the outside world.

I've seen very, very interesting methods of solving a problem written in C or Java or Python that were buried under a pile of CJam and GolfScript solutions that were 20-50 bytes long. They all use the same algorithm, but have their own clever ways in their language of solving the problem.

I'm not saying that golfs or golf languages are bad. I Think that there are many good examples of them. I also think that there are many interesting algorithm type questions that don't get answered in many languages because they are a golf. They are not won by coming up with a unique algorithm but by how little code you can write.

I'm trying to see if people are open to reconsidering the code-golf criteria for something more algorithmic or the like. Basically, consider if the best scoring model is shortest code instead of most efficient algorithm, most creative use of language, etc.

• Closing as duplicate because this question appears to be about the same problem. I can't really find the actual question though, so feel free to edit a more specific point of discussion in so this can be reopened. – Doorknob May 7 '15 at 15:57
• @Doorknob I believe that the implied question is "How can we claim to be fulfilling the Stack Exchange mission when the answers that win serve no purpose?" The complaint is the same, but the question is subtly different in my opinion. (Disclaimer: I do not share this sentiment. I have fun golfing in lengthy languages and not winning because my parents raised me to be a sheep instead of a wolf.) – Rainbolt May 7 '15 at 16:15
• @Doorknob I did see that one. I guess I thought the last paragraph was meant to be the more specific point. I'm trying to see if people are open to reconsidering the code-golf criteria for something more algorithmic or the like. Basically, consider if the best scoring model is shortest code instead of most efficient algorithm, most creative use of language, etc. – tfitzger May 7 '15 at 16:16
• There's nothing stopping anyone from using other winning criteria like fastest-code fastest-algorithm or roll their own using code-challenge (often used for optimisation challenges), as long as the criterion is objective (which "most creative use of language" isn't). But if people like code golfs, they'll post code golfs, and this criterion definitely has the benefit of simplicity - people get the others wrong much more often than they get them right. – Martin Ender May 7 '15 at 16:36
• Also, I'm not sure why you'd be worried about the green checkmark. It's worth 1.5 upvotes. If you post an immensely clever solution in Java, even if it's longer than CJam (but maybe beats all other Java/C# submissions by 30%), I'm sure you'll get more than those 1.5 upvotes for it. If it helps, think of the (code golf) winning criterion just as a incentive to think outside of the box - optimising towards a hard and unambiguous criterion inspires much more creativity than asking for "creative use of language". – Martin Ender May 7 '15 at 16:39
• @MartinBüttner If you look at the post doorknob references, the poster there specifically states that there have been challenges they ignored because there was no point to play the game. It's not that I care about the green checkmark, it's more that I've seen many people post comments stating that they have shied away from a question because they couldn't possibly win. To me, that seems counter-intuitive to the SE mission. – tfitzger May 7 '15 at 16:49
• As for code-golf being simple, that doesn't mean it's optimal. I recognize a desire for objective measures, but there are hundreds of them that don't require code length. Look at the code-competition and popularity-contest tags to see what I mean. – tfitzger May 7 '15 at 16:51
• @tfitzger But code-golf being simple mean that it is more accessible to everyone involved. "Calculate your time complexity" is a lot more daunting for new users than "count your characters". So code-golf is optimal in that sense. What optimums are you considering? e.g. what's the "optimal" method for scoring ascii-art questions which are usually code-golf? – Calvin's Hobbies May 7 '15 at 17:35
• "this site has become dominated by code-golfs". Given that this site's raison d'etre was to move code-golf questions out of stackoverflow main, I don't see the problem of a large proportion of code-golf questions here – Digital Trauma May 8 '15 at 18:49
• I think the community seems to be handling the golfing vs regular language thing just fine. For example out of the 4 top-voted answers here only one is in J. Currently the CJam and Pyth answers are significantly lower, even though they crush the competition purely in terms of the golfing scores. – Digital Trauma May 8 '15 at 18:54
• @DigitalTrauma And that is exactly one question out of many. Stroll through the list under the code-golf tag and you will see that the consistent top, both for votes and for golf score are esoteric languages. The only one that I see in any level of competition for the esolangs is Python. All I meant to ask was whether or not some questions under the code-golf tag could be better served under other tags. I have nothing against code golfing, but I feel that there have been challenges listed as golfs that are better suited as an algorithms challenge, restricted source, etc. – tfitzger May 8 '15 at 19:02
• To add to the point that @Calvin'sHobbies made, it's not always even possible to calculate your time complexity. E.g. consider maps / associative arrays in high-level languages (including things like JavaScript object properties). The time complexity of using them might depend on the specific implementation of the language. If the spec guarantees O(n^2), but you know the implementation you're using is O(n lg n) and Theta(n) expected time, how do you score that? – Peter Taylor May 9 '15 at 13:43