Code Bowling Index

Question

Author's note: This is a meta post tagged with discussion. The goal of this post it to create a community-wiki for Code-Bowling. Please post suggestions / concerns as answers and feel free to utilize the comments section on this post as well as on answers to discuss the topics at hand. (For extensive discussions consider using chat). This index is best used when sorting answers by active so you can see the current issues-at-hand being discussed.

---

Code Bowling

code-bowling is a challenge similar to code-golf except the objective is to solve a problem in the most bytes/characters possible (or highest complexity).

Fluffing up code to contain many bytes isn't that impressive or challenging so the fun in Code Bowling challenges typically stems from the limitations, obstacles, and penalties defined in a challenge's scoring system and/or rules. (Refer to section: Common Scoring Metrics and Challenge Styles)

Most Code Bowling challenges posted to this site are [closed] for a variety of reasons, including an obvious ability of exploitation, lack of a defined scoring system, vague rules, "too broad", and many other reasons. Due to this, Code-Bowling challenges are rarely created and if they are they are usually poorly received. (Relevant: Meta/Should we kill code-bowling?)

The goal of this index is to help create a reference for Code-Bowlers that defines what is allowed and what is not allowed (standard loopholes and more), what is encouraged and discouraged, common scoring systems that can be used (along with automated scoring tools), and various other resources that will be helpful in not only creating code bowling questions, but also in properly answering them.


This post has been broken-down and organized into 5 sections:
  Common Rules • Common Scoring Metrics • Best Practices • FAQ • Useful Tools

---

Common Rules (Rev. 1.0.0)

These are some objective rule-criterion that can be used in your challenge to limit a scope of answers and avoid being closed for too broad. Not all of these rules will be compatible with your challenge-type / scoring-system. Select a few you wish you include by copy pasting them into your challenge.

Please copy-paste the following into your Code-Bowling challenges:
*This challenge is using some rules from <a href="https://codegolf.meta.stackexchange.com/questions/11737/code-bowling-index">Code-Bowling: Common Rules, Revision 1.0.0</a>*

1. Character : Byte Ratio
   In Code-Bowling a character-count is preferred over a byte-count. The obvious reasoning for this is that multi-byte unicode characters (e.g. 🁴) can be used in place of single-byte unicode characters to fluff up byte count and will make bowling more about who renames the most variables with high-byte unicode characters rather than who most strategically creates meaningful complex code. (See Useful tools section at end for character-counting widget)

2. Variable/Function/Object Names
   All variable names (or object pointers, function names, etc) should be 1 character long. The only acceptable time to use 2-character variables names is after all possible 1-character variables have been used. The only acceptable time to use 3-character variables names is after all possible 2-character variables have been used. Etc.

3. Non-simplified Arithmetic
   All arithmetic should be in simplified form unless there is a justifiable reason for doing otherwise (e.g. circumventing penalties defined in the scoring system of the challenge (In which case you still must use the smallest possible alternative form)). Finding the simplified form of any equation (as well as a list of small alternative forms) is easy to do using Wolfram|Alpha. (See Useful tools section at end)

4. Un-used Code
   All code must be used. Meaning the program must fail to always properly complete the task if any individual character (or varying set(s) of characters) is/are removed. Naturally, a subset of the program should not be able complete the task on its own without the rest of the program.

5. Line-breaks and White-space
   Unless necessary for code function or otherwise specified by the challenge, all line-breaks and white-space should be removed from code before scoring by counting characters.

6. Comments
   Comments are not permitted towards character-count, unless somehow utilized by your program/function.

Revision History: (Utilizes archive.org)
• Revision 1.0.0 - Mar 14 2017
• Revision 0.0.2 - Mar 12 2017
• Revision 0.0.1 - Mar 11 2017

---

Common Scoring Metrics and Challenge Styles

Code-Bowling challenges that are simply just to find the largest solution to a problem are often ambiguous and broad (and therefor will get close votes for being too-broad). These also often result in uncreative ∞-byte answers.

Most code-bowling challenges can be made more challenging, fun, and narrow by applying various limitations and penalties so that the solutions will have a theoretical maximum score (typically 4-figures or less in character-count).

(For Challenge types that place limitations on source code, please include that tag restricted-source in your challenge/question.)

• Pangram Challenges
  
  A pangram is a sentence that uses every letter at least once. (The quick brown fox jumps over the lazy dog).
  
  These types of challenges have scoring systems designed where a perfect pangram would achieve the theoretical maximum score (though you are not required to use every character at least once.) Additionally, using any character more than once will start incurring a penalty.
  
  These challenges typically expand to more than just [A-Z] by including numbers and sometimes symbols in their scoring metrics.
  
  Here is an example of a simple pangram scoring system (with an online scoring tool). (See Useful tools section at end):
  
  

      1. Each character used increases your score by 1 point.
  
      2. Any repeated character decreases your score by 1 point. That is, they do not count towards character total.
  

  
  Here is another example of a more complex pangram scoring system (with an online scoring tool). (See Useful tools section at end):
  
  

      1. Each character used increases your score by 1.
  
      2. Repeated use of any alphanumeric character (a-z, A-Z, 0-9) will result in a deduction of 3 points per repeat (first use does not result in a deduction).
  
      3. Repeated use of basic punctuation ([!?.-,":';]) - including the brackets - will result in a deduction of 2 points per repeat.
  
      4. Repeated use of other ASCII characters {`~@#$%^&*_+=|\/><} - including the curly brackets - will result in a deduction of 4 points per repeat.
  
      5. Use of spaces, tabs, and newlines will result in a deduction of 1 point per use. That is, they do not count towards character total.
  
      6. Characters not mentioned above (Exotic Characters) will result in a deduction of 1 point per use. That is, they do not count towards character total.
  

  
  
• Rectangular Challenges
  
  These are challenges where the source code has to be formatted to be in the shape of a rectangle. Line breaks do count towards character count in these challenges.
  
  The dimensions (w:h) of the rectangle must be in the range of (2h:h) to (w:2w). So a rectangle of 6 lines of code, each containing 11 characters (6x11) would be valid. But a rectangle of 2 lines of code, each containing 20 characters (2x20) would not be valid. (Naturally, all lines must contain the same number of characters)
  
  Each line of code must be distinct to a certain threshold. Distinctness is typically calculated using the Levenshtein distance. The threshold may change from challenge to challenge but a typical distinctness threshold is 85%, where the Levenshtein distance between any two lines must be greater than or equal to 0.85*w, where w is the number of characters used in a line of your rectangle.
  
  Penalties may be added for failing to meet the distinctness threshold, or it may just be listed as a requirement and code that does not meet the threshold is invalid.
  
  Including a Levenshtein distance calculator in your challenge is good practice. (See Useful tools section at end)

---

Best Practices

There are many things that can be done in Code-Bowling that, while technically permitted, are frowned upon and will likely result in down-votes. There are also many good things you can do that will be smiled upon and likely result in up-votes. In this section you can find a list of practices that should, in most common cases, be avoided, as well as a list of practices that, in most cases, should be encouraged.

1. Purposefully Overly-Verbose Languages
   Languages that require a ton of characters on purpose are usually frowned upon in code-bowling. Many challenges might not even really allow these to stand a chance in competing due to the penalties and limitations defined in the challenge. Examples of Overly-Verbose Languages include (but are not limited to):
   • ArnoldC
   • SPL (Shakespeare Programming Language)
   • LOLCode
   • Any other wordy esoteric languages (likely somewhere on this list)
   

2. Code That is Too Long to Post
   If your code is too long to post, it is good practice to post it on a text sharing site and then post the link to your code. Hastebin and Pastebin are good resources for this. (See Useful tools section at end)
   
   If your code is so big that it was not hand-typed it is recommended that you also share your generating function that created the code.

3. Online IDEs
   It is good practice and courtesy to post a link to an online IDE that is running your code so that others may execute it and see for themselves, as well as tweak your code to potentially help you increase your score. (See Useful tools section at end)

4. Vague (unenforceable) Rules
   Do not add rules that have no clear measuring objective or systematic ruling system, for example a rule like "All code must be useful". Rules like this are unenforceable and likely to get your question [closed]. All rules should be defined in a way where they could theoretically be enforced with an automated algorithm; so NO SUBJECTIVE RULES.

5. Bogus Code
   Bogus code (that is added obviously just to fluff up character-count) should be avoided, unless utilizing them for good reason (e.g. to avoid penalties defined in the scoring system). Utilizing bogus code will often result in down-votes from viewers. Common examples of bogus code to avoid are as follows:

   a) Duplicating Variables
   Adding an extra variable for no reason except to increase the number of variables used. For example changing a=5; a++; to something like a=5; b=a; b++;

   b) Significant-Figures Abuse
   Adding extra degrees of accuracy to an object with no real reason to do so
   For example changing f = 3; to something like f = 3.00000000000;.

   c) Literals Abuse
   Adding extra content (typically to literal types) that is un-needed and typically immediately discarded.
   E.g. changing i = 2; to i = numberOfCharacters("abcdefghijklmnopqrstuvwxyz")-24;
   or changing s = "hello"; to s = "hellooooo"[0-4];.

---

FAQ

Frequently Asked Questions:

This section will be created as questions are asked and answered.

---

Useful Tools

1. Character Counting Widget — MotherEff.in, ETHProductions
   This is useful for determining the number of characters used in your application. In Code-Bowling a character count scoring system is favored over a byte count scoring system. (See Rule #1)

2. Arithmetic/Equation Simplifier — Wolfram|Alpha
   This is useful for simplifying your equations. Input an equation (e.g. x+x+x+x) and it will output the simplified forms (e.g. 4*x) (See Rule #3)

3. Text Sharing Sites — HasteBin, PasteBin
   These are useful tools for sharing code that is too big to post on the site. (See Best Practices #2)

4. Online IDEs — Try It Online!, JSFiddle, SE Snippets
   These are useful for allowing others to easily execute your code online and modify it. Try It Online! is useful for most programming languages. JSFiddle is useful for HTML/CSS/Javascript/etc but these can also be executed natively in StackExchange's Code Snippets (See Best Practices #3)

5. Pangram Scoring Tools — Example 1 (simple), Example 2 (complex)
   These are two automated score calculating tools for common Pangram scoring metric variations (See Common Scoring Metrics #1)

6. Levenshtein distance calculator — PlanetCalc
   This is a Levenshtein distance calculator useful for quantifying the changes made between two lines of code. (See Common Scoring Metrics #3)

Answer 1

There are a couple of problems I see:

1. Variable Name Length. This is a non-observable requirement. The post doesn't say that code-bowling challenges can't include them, but when we get to esoteric languages it can become really hard to define what a variable name is. For example, say my language doesn't have traditional variables, but rather stores everything in a massive array. What if I store it to key "longVariableName"? Or if I store it at position 10000?
2. Non-simplified Arithmetic is even harder to define in an objective way. For example, lets say, instead of typing in 1, I did X/X. Wolfram Alpha says "1 (for x != 0)". If you argue that X/X has to be simplified, what if my program had logic that depended on X/X throwing an error when X is 0?
3. Purposefully Overly-Verbose Languages. You argue that such languages are frowned upon. I disagree. To frown upon verbose languages is to frown upon golfing languages on code-golf challenges. While there are many that don't like them, the majority of our users have learned to pick the right language for the job.
4. Vague (unenforceable) Rules: Actually, "All code must be useful" is actually a pretty easy thing to enforce. You've shown how its enforced: If that code can be removed and the program still runs correctly, then its unused. You literally posted that above.
5. Bogus code: This is more non-observable stuff. Furthermore the threat of downvotes doesn't really work if its going to produce the winning submission.

Now, I'd like to take a look at your Challenge Styles section. I think your introductory sentence is revealing: "Code-Bowling challenges that are simply just to find the largest solution to a problem are often ambiguous and broad".

code-golf is about representing stuff using as little data as possible. When you think about it this way, it becomes obvious that representing something with as much data as possible isn't a challenge at all. It's rather revealing that the example challenges you posted don't pose a challenge from the bowling aspect, but from the other restrictions.

I'd personally argue that for a code-bowling challenge to work, it'd be so mangled it wouldn't be a code-bowling challenge anymore.

Answer 2

Non-simplified Arithmetic
All arithmetic should be in simplified form unless there is a justifiable reason for doing otherwise...

...

Vague (unenforceable) Rules
Do not add rules that have no clear measuring objective or systematic ruling system, for example a rule like "All code must be useful"... All rules should be defined in a way where they could theoretically be enforced with an automated algorithm; so NO SUBJECTIVE RULES.

I see a tension. There's no way to automatically enforce a test for whether a reason is justifiable or not. In particular, if I claim "doing it this way is better for number-analytic reasons" then I may be wrong. No algorithm is going to perfectly verify that, and I doubt that most users of the site can either.

I also don't think there's a way to automatically check whether arithmetic is in simplified form - a single expression can be fed into Wolfram Alpha and rejected if it claims a different simplification, but an expression can also be broken up and mangled to be nearly unrecognisable. Undecidability also rears its head: see Rice's theorem.

Answer 3

Ok, I don't think I was clear with my last answer, so I hope to make a post to make this clear:

Code bowling (conceptually) doesn't work.

Are you familiar with Sudoku? You know, that awesome puzzle where you try to fill in as many squares as possible?

Let's say I made a challenge where your code had to be arranged like a Sudoku puzzle:

1. It has to fit in a 9x9 grid
2. You could only use 9 different characters
3. Each row and column can't have the same character twice.
4. An empty spot (a space) counts as 0 characters.
5. Scored by total number of characters, maximum wins.

This could actually be an interesting challenge. I'd also put a code-bowling tag on it.

The problem is that this really isn't a code-bowling challenge. It's a source-layout challenge that happens to be scored by maximum number of characters. We simply have the code-bowling tag to make "scored by maximum number of characters" easy to communicate.

code-golf is about transmitting as much information in as little space as possible

This is a problem that people everywhere are solving. It's why we gzip our html, or why downloads come in a tar file. This is why general-purpose golfing languages are interesting. They are trying to ensure that it can do as many tasks as possible with as little code as possible.

Transmitting as much information in as much space as possible doesn't make sense

Of course you can do it. This is why code-bowling challenges are littered with loophole-patches. These "patches" become the real challenge in a similar way that my sudoku-board was the real challenge.

Therefore, don't try and take a code-bowling challenge and modify it to make it interesting. Simply come up with interesting concepts, and if it happens to be naturally scored by maximum characters, put that tag on it.

Answer 4

Preventing infinite-character Answers

Sometimes a challenge can be very well crafted to require some very skillful bowling, but there are a few languages that can easily solve the problem in near-infinite bytes with no real effort, it is hard to exclude these from the challenge in a systematic way.

---

For example, in my bowling challenge: Rearrangeable Code Bowling you can end up with some really creative solutions that utilize great bowling skill like the following:

MATL: Score 6 — Luis Mendo
CJAM: Score 15 — Martin Ender♦

But then some languages can just as easily post not-so-creative solutions that require no real bowling skill and get a near-infinite score, for example:

Lenguage: Score 1,112,064 — Nathan Merrill
√åı¥®ÏØ¿: Score ∞ — Valyrio Account

While these answers are certainly valid, they don't really go with the spirit of the competition.

---

Please comment on this answer with any methods, suggestions, or tips you have on creating systematic and concrete rules that can be added to challenges to keep these answers out (if an OP desires to not have answers like that on their challenge, which is reasonable imho)

If some good enough methods are proposed I may edit this into the original post under a new Tips section, or something similar.

---

Potential Methods:

Will update soon after enough input has been received.

Answer 5

For pure length comparing, if you can remove some chars make it still work, it's not allowed

x+x+x+x allowed
x+x-x   not allowed as x work
var a,aa,aaa,aaaa
        allowed in this rule, but there may be other ones
numberOfCharacters("abcdefghijklmnopqrstuvwxyz")-24
        not allowed as 2 or numberOfCharacters("ab") work