We are currently working on new rules for what content should and shouldn't be allowed on this website, and are looking for feedback! See Esolang:2026 topicality proposal to view and give feedback on the current draft.
Esolang:2026 topicality proposal
Moderating this wiki has become hard recently due to the guidelines about what is on-topic and off-topic being unclear. Likewise, the wiki has gradually become less useful as a result of a large number of similar pages making it hard to find the interesting or unique ones, with no clear guidance on how to resolve the issue.
This page contains proposals for rules going forwards about what is and isn't permitted on the wiki (which might not necessarily match historical practice).
This is not enforced policy yet – whether or not it becomes policy will depend on community feedback. You can help shape the policy in two ways – by editing it directly, or by discussing it on the talk page. Note that edits to this page should ideally edit it so that any changed rules are explained, and not just stated (both so that people understand why you want the rule and so that, if it becomes policy, future users will understand why the rule exists). Changes to this page are quite likely to be reverted by people who disagree with them; this doesn't mean that the original change was disallowed or rule-breaking, just that someone disagrees with the change (and if changes are disputed in this way, it would make sense for the changer and reverter to discuss the disagreement on the talk page).
Pages about esoteric programming languages
The original and primary goal of this wiki is to document esoteric programming languages ("esolangs"). That means that we would like to have content describing each such language that exists – ideally full details about the language, but if only partial information is available, we list what is known. This is not just a language specification, but also information about implementations of the language, computational properties of the language, programs written in the language, techniques for thinking about / writing in / analysing the language, etc. (as well as links to related languages).
Information about a language can be presented in three ways – either literally on the page, via a description sufficient to reconstruct the information (e.g. "The hello world program for this language consists of 142,209,095,870,573,693,396,245,504,627,320,468,349,603,549,841,832,242,891,887,476,756 0 characters"), or via a link to an externally hosted web page or reference to externally known content. In most cases, one of the first two options is preferable because it reduces the chance of information about a language being lost due to an external webhost going offline. The third option is preferable in cases where the information is copyrighted (thus not legally allowed to be hosted here) and would be destroyed by being paraphrased, where it consists of large amounts of code (this is better hosted using The Esoteric File Archive than written on the wiki), or is offtopic (it is not unknown for esolangs to depend on external data files which are not themselves esolang-related). For example, it is preferable to describe the behaviour of a command as "prints the lyrics to Rick Astley's 'Never Gonna Give You Up'" than it would be to actually copy the lyrics in question onto the page (both because they are copyrighted, and because they are not an esolang). Likewise, if an image used as a language's logo was not created specifically for the language or embeds substantial amounts of content from existing images, it should not be uploaded to the wiki (but instead should be described or linked externally).
However, there are some caveats when it comes to describing esoteric programming languages:
- It is not uncommon for essentially the same language to be discovered multiple times, and if there isn't an interesting distinction between two languages (either in terms of the language's behaviour or in terms of consequences of the language's choice of syntax), it makes sense to describe both languages on the same page (in order to avoid needing to write the same information on every page, and in order to help visitors find distinct languages rather than finding lots of copies of the same language). It likewise also makes sense to put variants of a language on the same page as the language itself (or onto a page for variants of that language). For example, Unary, Lenguage, and Ellipsis are all essentially the same language (even though Ellipsis is three times as long, and Lenguage does terminal I/O rather than standard-stream I/O), so it makes sense to discuss them all on the same page – but they are listed on a different page from brainfuck because length-based syntax is a topic that's worthy of discussion in its own right and would not be applicable to the brainfuck article. When merging pages, redirects are used so that people searching for information about the language will find the appropriate page.
- There is a distinction between a language and a language specification: usefully documenting a language requires writing what is known about the language rather than just copying what the specification says. For example, the first widely publicised source for Kvikkalkul claimed that it was created in Sweden in 1950, but this statement is historically unlikely and generally considered to have been a deliberate lie in the specification (in order to construct a fake history for the language). As such, the page about it mentions the statement about the date but does not take it as fact, and instead lists other known information about the date (for example, that the language was first published in 1994). Likewise, Malbolge's specification and reference implementation disagree about which way round the input and output commands go (which is more likely to have been a mistake than a deliberate error) – the discrepancy is listed in the article rather than just copying the specification. A corollary of this is that pages here do not need to follow the same writing style as the original specification; using the same terminology can be useful in order to help clarify other sources, but generally speaking the article should be written in whatever way is most useful to the typical reader.
- The aim of an article about a language is to describe the language, not to define the language; in particular, changing an article about a language doesn't change the language (although it may reflect a change made by the language's creator / community, in which case the article would ideally explain what change was made and when in order to help understand the meaning of programs that predate it). As such, edits to a page that don't match how the language is in practice being specified and used are just vandalism, because they cause the page to become inaccurate. A special case of this is pages that are intended to describe a language that has not yet been created and is meant to be collaboratively created by editors; these are not considered to be pages describing languages due to the language not existing, and are disallowed because successfully creating a language this way requires a strong vision shared by the participants, which doesn't exist when the page is left open to anyone.
- LLM-generated descriptions of languages are usually wrong (and have questionable copyright status). This is true even if the language itself was designed with LLM assistance. As such, using an LLM to write language specifications for the wiki is not allowed:
- If the language exists only in the form of a specification generated by an LLM, the only actually interesting content is the original ideas that were fed into the LLM when asking it to create a language; everything else is LLM-expanded content with no useful information density. As such, these pages are considered to be language ideas rather than actual languages (especially as the details of such languages are usually insufficiently or contradictorily specified by the LLM), and should be listed only in terms of the core ideas, on a page dedicated to listing ideas (e.g. the list of ideas or a page about LLM-generated languages).
- If the LLM generated an implementation, then this can serve as a concrete way to determine what the language is (by reverse-engineering all the relevant information from the implementation). Articles about such languages are allowed, but should be written by a human based on the implementation, rather than assuming the details in any specification (which may not match) are correct.
- Some programming languages are not esoteric, but can be viewed from the point of view of esoteric programming. It has historically been a point of contention, but nowadays is generally accepted as long as the article restricts itself to discussing the esoteric or unusual aspects of the language. For example, Python is generally not considered esoteric, since it is one of the most popular languages worldwide, but we document it from the esoteric perspective.
- Pages about esolangs are generally not deleted just because the author of the esolang abandoned it or decided that it was uninteresting – if an esolang is abandoned, that tends to make information about it disappear all the more quickly, so preserving it here becomes even more important. If the esolang is uninteresting, the page about it should be merged with pages about other similar languages.
If a page would otherwise be too large, it can be split into separate pages (within reason) while remaining ontopic; for example, some languages have separate examples subpages in Category:Examples.
Pages about art that resembles a description of a programming language
Some esoteric programming languages are created primarily for artistic purposes. A related phenomenon is that of media that resemble descriptions of programming languages, but are created for artistic or humorous purposes without any actual programming language existing; these have a long history in the esoteric programming language community. Good examples of this sort of thing include xkcd 1537 and TURKEY BOMB, both of which purport to describe a real programming language but where it is unlikely or impossible that the language actually exists.
People often try to post this sort of art directly to this wiki (e.g. Vague). However, there are a number of reasons why this ends up working badly in practice:
- The purpose of a wiki is to allow anyone to improve the content by editing it – but allowing arbitrary edits to this sort of artwork generally ends up ruining it, and so editors are generally very constrained in what they can do to avoid ruining the page. As such, a wiki makes a bad choice of host for it.
- The humor value of this sort of work is often derived from pretending that a programming language exists when it in fact doesn't, and writing about it as though it were a real language. Doing that on a website like this one that's meant to be useful as a reference work effectively means that we are hosting misinformation and lying to users; the purpose of this site would generally best be served by explaining the joke (as that the information that a person who was looking for information about the language would need), but that can't be done from within the work itself.
- Such pages are usually impossible to categorise well, e.g. they are typically placed in categories intended for languages despite no language existing (e.g. Category:Unimplemented is intended to be useful for people looking for languages to implement, but this sort of artistic work is often impossible to implement). Sometimes categories are used to further the joke, but even if it enhances the page as art, it makes the category less useful by causing it to contain irrelevant pages.
As such, the correct way to handle this sort of art is to write pages that link to it and describe it, rather than hosting it directly on a wiki page. (In cases where it was originally posted to this wiki, it is probably easiest to use a permanent link and treat the old revision of the page as though it were an external link.) These pages should not be categorised as though they were languages (historically these were categorised in Category:Joke languages, but doing so should be avoided because that category is also used for intentionally unusable languages that nonetheless have concrete and well-specified semantics, like Unnecessary and Text). This proposal does not commit to any specific exceptions where a piece of art would stay on the wiki as a page. However, even in such a case, the page should begin with a prominent banner describing it as an artwork, so that readers are not mislead that the description represents a real language.
In some cases, e.g. SLOBOL, a description of a (nonexistent) language was created first for artistic reasons, and then later on, someone else designed a language based on the description. The two should be considered separately (and documented as being different entities), although depending on the circumstances it may make sense to write a single page that talks about both (as long as it maintains the distinction).
Pages about esolang-adjacent topics
Articles can be written here that contain information that is useful for understanding esoteric programming, or designing/analysing/programming in esoteric programming languages. This includes concepts like queue or Turing complete, articles about people who design or work in esolangs in cases where a separate article would be helpful, and proofs that support (ontopic) claims made in articles. As with pages describing the esolangs themselves, these should be actual articles about concepts/people/proofs and not joke content that merely resembles them.
Articles can also be written about notable implementations of esolangs (e.g. awib) or programs written in esolangs (e.g. Lost Kingdom).
Pages about the wiki itself
Some number of pages about the categorisation system (Category:) and about the wiki itself (Esolang:, Help:) exist, but it is generally rare that new such pages are needed. In particular, creating a new category requires a lot of thought (would it be useful for navigation? what should the name be? what exact rules should be used to determine what is included?) and is only allowed after discussion at Esolang talk:Categorization leads to a consensus. New Help: pages are hardly ever needed because better documentation on how to use MediaWiki is available at many other sites (e.g. wikipedia:Help:Contents, mediawikiwiki:Help:Contents) – they could only usefully contain information about how editing at Esolang is different from other wikis, but there are almost no differences. Likewise, new Esolang: pages are hardly ever needed because this wiki generally tries to avoid a lot of formal process (it is small enough that normally issues can be sorted out simply by people acting reasonably or by discussion on a relevant talk page, which is visible via Special:RecentChanges). There have been successful examples of such pages being created, but users should generally be cautious about doing so.
New templates should likewise usually be avoided: the purpose of a template is to be able to use it on a large number of similar pages, but there is little reason to do that on this wiki (where similar pages should normally be merged), and newly created templates are typically unlikely to catch on. (A good way to think about it: on Wikipedia templates can be useful because they can be used on all the articles in a particular subject area, with the editors in that area learning that it exists; but this wiki only covers a single subject, so any useful templates are likely to have been created already.)
Pages used for discussion
It is important that Esolang is not used as a social media site. This is partly because it is not set up to work well as one (a wiki doesn't make a great basis for social media), and partly because many countries are placing restrictions on social media sites that would be ruinous to this website (e.g. by forcing social media sites to limit who can access them).
As such, any discussion that happens directly on this site (on Talk: pages or the like) should be in relation to content that already exists on the site (e.g. posting on the Talk: page for an esolang in order to discuss that esolang or the article about it); likewise, messages posted on a User talk: page should be about actions that that user has performed on the wiki.
Excessively long or complex signatures are discouraged, because they generally just make talk pages harder to read without contributing to discussion – discussions should primarily focus on what is being said rather than who is saying it, and eye-catching signatures focus on the wrong thing.
User subpages should be used only for things that would be on-topic as an article (except that they can be used in cases where the page, or the language it describes, is unfinished). User pages should generally have similar content to that which an article about the user in question would have (but are written from a different point of view, by the user themself rather than by others writing about them).
Mass deletions
It is almost certain that following the accepting of this new policy, some form of mass-deletion will occur. As it is possible that this could lead to confusion or controversy within the community, if such a mass deletion is to occur, administrators are to give a grace period of 7 days for anyone interested in the soon-to-be-deleted pages to move them off-site. Following the grace period, the pages will be deleted. During this period, an announcement will be created as a banner shown at the top of pages showing which pages/categories of pages will be deleted, and how much time is left.