How to Make Code Golf More Enjoyable: Winners by Language?

Question

So, I was reading the related question here, when I went off on a tangent.

The point of the given post, as I read it, is that certain languages like GolfScript, K, and some other extremely-high level languages can trivialize Code Golf by taking problems (for the sake of discussion, determining whether some string is a palindrome), and creating a solution in likely less than 15-20 characters, which totally blows other more verbose languages out of the water; they simply can't compete!

A potential solution I want to discuss is probably not a real shocker, and might seem a tad obvious: winners can be tallied by language. To return to the palindrome example, say User A creates a 65-character Python solution and a 15 character GolfScript solution, while User B creates a 45-character K solution and a 25 character GolfScript solution. In categories, User A would be the winner for GolfScript, while User B would be the winner for K (at least, until some challenger comes to take their title away.)

The major point I can see against this idea is that there's only one Green Checkmark of Victory. This idea is imperfect because splitting things up by category raises the question of what it really means to win at Code Golf. Dividing by language means the possibility of multiple winners, which is thoroughly incompatible with the format of a Q/A site.

So, the Meta-Question: A) How can we compartmentalize these competitions such that users of arcane, high-level languages can recieve recognition alongside users of more verbose languages, and B) If we accept a multi-winner paradigm, how can we crown the One True Winner?

Answer 1

I thought of (some form of) this question probably since the first day I checked out the site. And my view is that this is something the platform is supposed to provide, but afaik support for this kind of features is missing (in stackexchange).

The way I imagine it is this: each answer can specify a language and a score (in separate fields from the main textarea), then the system automatically shows the list of languages used, and for each language it provides some info about the best answer (perhaps the user's name with a link to the answer) and a filter to show only answers in that language. Also, there should be an option to sort answers by score (both when filtered and globally), and sort languages in the list by score and by number of answers (not just alphabetically).
So that would answer question A.

For question B, I think we can either remove the option to have a global winner, or (better) let the asker choose whichever winner they desire (including none), perhaps even having an option to automatically select the answer with the best score.

I think voting just doesn't cut it, except for challenges where there is no objective score and the winner is actually determined by voting. So yes, some questions will have no objective score (e.g. the recent code-trolling ones) and others will have no direct language association (e.g. polyglot challenges) but generally they have both.

If this kind of system can't be done on stackexchange, then what about making a separate site for it?

Answer 2

The point of the given post, as I read it, is that certain languages like GolfScript, K, and some other extremely-high level languages can trivialize Code Golf by taking problems (for the sake of discussion, determining whether some string is a palindrome), and creating a solution in likely less than 15-20 characters, which totally blows other more verbose languages out of the water

I disagree with that analysis. Trivial questions get trivial answers. Non-trivial questions may sometimes get very short answers, but at the cost of substantial effort.

A) How can we compartmentalize these competitions such that users of arcane, high-level languages can recieve recognition alongside users of more verbose languages

Why is it necessary to compartmentalise? Upvotes are recognition. Is the question that interests you how to get people to upvote answers in verbose languages?

Answer 3

I don't think it is necessary to have language specific winners.

For example, I know python better than most languages, and know that in most challenges it isn't really a contender. How ever, I can appreciate the terseness of some responses. However, when I see a ridiculously short python answer I almost always up-vote it as I know how hard it must have been.

I'd like to think the community will always acknowledge good golfing, regardless of language.

Answer 4

languages like GolfScript, K, and some other extremely-high level languages can trivialize Code Golf by taking problems

While it is true that those languages are in fact made for expressing simple tasks with very short code everybody seems to miss a certain point:

• It is by far NOT easy to golf in those languages

It may be easy to write a shorter program than Java in those languages but still, finding the shortest solution requires the same amount of skill (or even more) as golfing in any other language.

If you take 'The Burlesque Programming Language' as an example: It has many built-ins. The idea is, that stuff you have to do often should be accessible very easy. Therefore it has a built-in function to do X etc. Obviously when it comes to EXACTLY DO X you CAN'T beat it with another language. However, when it comes to array manipulation you don't stand a chance with Burlesque. But that's not really the point. The point is, that it's still difficult to golf in Burlesque.

When golfing in Burlesque you do exactly the same process as golfing in any other language: You start with an idea, write it, shorten the code. Start with another idea, write it shorten the code. Try to abuse test cases. Abuse bugs, abuse undocumented stuff. Abuse weird behaviour. I'll attach a documentation about a solution of mine for a problem to calculate binomial coefficients with the input format " , "

wd{-]}[M^pnr [12B]

","""r~penr [11B]

psShra^pnr [10B]

psRT[-p^nr [10B]

ps^p/vnr [8B]

Removing the ',' is the tricky part.

wd{-]}[M^pnr does this by splitting into words and then calling Head inside MapParse.

","""r~penr obviously uses a regex to remove the ',' from the input

psShra^pnr uses Parse and then converts to Pretty and back to a string obtaining a format parsable by read array which has a weird behaviour that skips over the ','

psRT[-p^nr uses Parse and then rotates and tails the block to remove the ','

ps^p/vnr uses Parse and pushes all elements to the stack and uses SwapPop to remove the ','

As you hopefully will see, it really still takes skill, time and endurance to find the shortest solution. And that's what golfing is about as far as my opinion goes. Saying: "Oh no. It's too easy to golf in golfscript" is just wrong.