Why challenges exist
A challenge gives people a reason to make something on a particular weekend. In a hobby with no deadlines and no customers, a shared prompt supplies structure, an audience and a small amount of friendly pressure. Challenges also lower the barrier to entry. Deciding what to build is often the hardest step, and a prompt removes it.
This article describes the common formats in general terms. Specific events come and go, and details such as rules and dates change, so it avoids naming any.
Design jams
In a design jam, participants invent a new language under a theme or constraint, and then publish it. Typical themes include “a language with only two commands,” “a language where programs are drawn rather than typed,” or “a language that cannot loop.” The constraint pushes designers toward ideas they would not otherwise try.
Judging, when there is any, usually looks at originality, clarity of the description and whether the language can actually run programs. Many jams skip formal judging entirely and treat the shared pool of new languages as the reward.
Shortest-program tasks
The most familiar format is the golf task: solve a stated problem with the smallest possible program in a given language. The task might be to print a fixed phrase, test whether a number is prime or reverse a string. Entries are compared by length, usually counted in characters or bytes. The general idea is covered in the article on code golf, and the related theme of size limits comes up whenever the competition sets a hard cap.
Golf tasks in odd languages have a particular flavor. In a grid language, the shortest solution is often a clever path through the layout, and in a tape language it is often a trick with the cell values. The pleasure is partly in seeing how differently the same problem looks in different systems.
Implementation challenges
Here the goal is to build the tool rather than use it. Participants write an interpreter for a language in as few lines as possible, or in an unusual host language, or in a language that was never meant for the job. A related variant asks for an interpreter that is itself written in the language it interprets. These are good learning exercises, and they connect to the practical work in writing a Befunge interpreter or any other small implementation.
Obfuscation and trick tasks
Some contests reward programs that are deliberately confusing, or that look like something else. Examples of typical tasks include:
- a program whose source is also a picture or a block of text
- a program that is valid in more than one language at once, which touches on polyglot programs
- a program that prints its own source, usually called a quine
Judging for these is more subjective. Panels or voters often consider cleverness, surprise and how well the trick is hidden.
Puzzle sets
A puzzle set is a series of small problems posed for a particular language, ranging from easy to hard. Participants solve what they can and sometimes publish their approach afterward. Sets built around unusual limits are closely related to constraint puzzles, such as “no use of a particular command” or “no more than a fixed number of cells.”
Puzzle sets work well for beginners, because the early problems are small enough to finish and the later ones leave room to grow.
Marathon and collaborative formats
Not every event is a race. Some are slow and cooperative.
- Collaborative language building, where a group adds one rule at a time.
- Translation rounds, where each participant ports the same program to a different language.
- Open-ended showcases, where people post whatever they made and others comment.
These formats favor conversation over ranking. They are a good fit when the community wants to learn from each other rather than compete.
How scoring usually works
Scoring varies, but the main approaches are easy to describe.
- Objective measures, such as program length or number of steps executed.
- Peer voting, where participants rate entries for qualities like humor or elegance.
- Panel judging, where a small group chooses winners using stated criteria.
- No scoring, where the reward is simply publication.
Objective measures are clear but can be gamed. Subjective ones are flexible but invite disagreement. A well-run event states the method up front, and the more detailed discussion of fairness is in the article on scoring rules.
Running a small challenge of your own
If you want to organize one, a few habits tend to help.
- State the task precisely. Give exact inputs, exact expected outputs and what counts as a valid entry.
- Choose a measure before you start. Changing it afterward feels unfair.
- Provide a reference implementation or a link to one. People should not have to guess how the language behaves.
- Allow a reasonable time window. A week or two is common for casual events, though the right length depends on the audience.
- Publish the results and the entries. The sharing is much of the value.
Prizes, where they exist, are typically symbolic. Recognition and bragging rights are the usual currency, and outcomes depend entirely on who happens to take part.
What participants get out of it
Even people who never win tend to finish an event with something useful. They have learned an unfamiliar language more thoroughly than a casual read would teach, they have seen how others approached the same problem, and often they have a small program they are proud of. Reading other entries afterward is arguably the most valuable part, and it is the same habit as reading solutions written by other people.