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

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?

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?

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?

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.

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.

• The problem isn't that golfing in the language is easy; the problem is that these minimalistic, esoteric languages consistently beat everything else, which makes them an obvious choice to win the competition, and are hard to read (unless you already know the language, in which case you're fine.) I assert that these languages, while requiring skill, remove the sportsmanship from Code Golf, which is what I want to find a way around. Sep 9 '13 at 13:45
• If you happen to do 'language agnostic' golfing than obviously the language you're using is a huge factor. The language becomes a tool(and with any competitions that use tools)you can't win if your tool is not the best choice. Obviously my chances of winning a archery competition where those high-tec bows are allowed with my own plain bow is not an option because it's just the wrong tool for these competitions. As for sportmanship: If you do language agnostic competitions and you are aware that your language can't win you have to consider learning how to use better tools. Sep 12 '13 at 8:31
• Or you can choose to ignore that and keep using a tool even if you know that it's obsolete and a bad choice. You can't play soccerr without the right shoes, it's just too slippery when wet. Not using the right shoes doesn't make you a good sportsman, it makes you a bad and ignorant one. Sep 12 '13 at 8:34
• Also the definition of "esoteric" is somewhat subjective. APL and J are not actually considered esoteric but they really rock at code golfing. You can't ban them just because they are good. That's also not good sportsmanship. Other languages like awk, vi(m script), sed also allow to write very short code. What about those? Also, what's your definition of "unreadable"? Can you read haskell code without knowing haskell? You can't really do that either. Sep 12 '13 at 8:39
• I mean seriously: What does pythons Sep 12 '13 at 8:40
• Sorry. I pressed ENTER to early. My point is: What's unreadable anyway? If I wouldn't know python then foo[::-1] is unreadable. And perl at codegolf level is unreadable in my eyes too. Maybe you can't read Burlesque (or Flogscript, or Golfscript) code but that's only because you don't know a single command. If you knew, you'd understand code like ln)XXtp\[\[sh at ease. It's just print.concat.concat.transpose.map explode.lines in haskell terms (where explode converts a String to a list of characters). Sep 12 '13 at 8:50
• Why not create divisions? Have a winner for terse languages (APL, J, Golfscript, etc.). Then crown a winner for the non-terse languages. I occasionally golf in Python. My personally goal is to beat other Python, ruby, javascript, and perl answers. But it stinks that I can almost never win with my chosen language. Sep 20 '13 at 17:25