Y |- | Fibonacci || Ytmndsorrowlnz |- | Accommodate || Yosorrowlnz |- | All || Ysorrowlnzso |- | any else || yyysorrowlnzerious? |- | delete all || ynonsorrowln? < >


PASTEBIN paste Search... LOGIN SIGN UP Guest User Untitled A GUEST MAY 10TH, 2026 16 0 NEVER ADD COMMENT Not a member of Pastebin yet? Sign Up, it unlocks many cool features! 12.84 KB | None | 由于近期关于哪些内容属于话题范围内和范围外的指南不明确，维护本Wiki变得困难。同样，由于大量相似页面导致难以找到有趣或独特的页面，且缺乏解决问题的明确指导，本Wiki逐渐变得不那么有用。 本页面提出了关于未来Wiki允许和不允许内容的规则提案（这些规则可能与历史实践不完全一致）。 '''这还不是强制实施的政策：它是否成为政策将取决于社区反馈。''' 您可以通过两种方式帮助塑造政策——直接编辑本页面，或在 [[Esolang talk:2026 topicality proposal]] 上讨论。请注意，对本页面的编辑理想情况下应解释任何更改的规则，而不仅仅是陈述规则（这样既能让人们理解您为何想要该规则，也能在规则成为政策后，让未来用户理解该规则存在的原因）。对本页面的更改很可能会被不同意的人回退；这并不意味着原始更改被禁止或违反规则，只是有人不同意该更改（如果更改以这种方式受到争议，更改者和回退者应在讨论页上讨论分歧）。 == 关于深奥编程语言的页面 == 本Wiki最初且主要的目标是记录[[esoteric programming languages]]（深奥编程语言）。这意味着我们希望包含描述每种存在语言的内容——理想情况下是语言的完整细节，但如果只有部分信息可用，我们列出已知内容。这不仅包括语言规范，还包括语言实现、计算特性、用该语言编写的程序、思考/编写/分析该语言的技术等信息（以及相关语言的链接）。 关于语言的信息可以通过三种方式呈现——直接写在页面上、通过足以重建信息的描述（例如：“该语言的Hello World程序由142,209,095,870,573,693,396,245,504,627,320,468,349,603,549,841,832,242,891,887,476,756个0字符组成”）、或者通过链接到外部托管网页或引用外部已知内容。在大多数情况下，前两种方式更可取，因为它们减少了因外部网站下线而导致语言信息丢失的可能性。第三种方式适用于以下情况：信息受版权保护（因此法律上不允许托管在此处）且无法通过转述保留原意；信息包含大量代码（最好托管在[[The Esoteric File Archive]]而非写在Wiki上）；或者信息属于话题外（并不罕见的是，深奥语言依赖于本身与深奥语言无关的外部数据文件）。例如，描述一个命令的行为为“打印瑞克·阿斯特利的《Never Gonna Give You Up》的歌词”比实际将歌词复制到页面上更可取（既因为歌词受版权保护，也因为它们不是深奥语言）。同样，如果用作语言标志的图片不是专门为该语言创建的，或者嵌入了现有图片的大量内容，则不应上传到Wiki（而应通过描述或外部链接引用）。 然而，在描述深奥编程语言时有一些注意事项： 同一种语言被多次发现的情况并不少见，如果两种语言之间没有有趣的区分（无论是在语言行为方面还是在语言语法选择的结果方面），将两种语言描述在同一页面上是有意义的（以避免在每页上重复相同的信息，并帮助访问者找到不同的语言，而不是找到大量相同语言的副本）。同样，将语言的变体放在语言本身所在的页面（或放在该语言变体的页面）上也是有意义的。例如，[[Unary]]、[[Lenguage]]和[[Ellipsis]]本质上是相同的语言（尽管Ellipsis长度是其三倍，且Lenguage使用终端I/O而非标准流I/O），因此将它们放在同一页面上讨论是合理的——但它们与[[brainfuck]]分开列出，因为基于长度的语法本身是一个值得讨论的话题，且不适用于[[brainfuck]]条目。合并页面时，使用重定向以便搜索该语言信息的人能找到合适的页面。 语言和语言规范之间存在区别：有效地记录语言需要写出关于该语言已知的信息，而不仅仅是复制规范的内容。例如，[[Kvikkalkul]]第一个广泛公开的来源声称它于1950年在瑞典创建，但这一说法在历史上不太可能，通常被认为是有意编造的谎言（为了构建该语言的虚假历史）。因此，关于它的页面提到了这一日期说法，但并未将其视为事实，而是列出了其他已知的日期信息（例如，该语言首次发布于1994年）。同样，[[Malbolge]]的规范与参考实现在输入和输出命令的顺序上存在分歧（这更可能是错误而非有意为之）——条目中列出了这一差异，而不仅仅是复制规范。由此推论，这里的页面不必遵循原始规范的写作风格；使用相同的术语有助于澄清其他来源，但一般而言，条目应以对典型读者最有用的方式撰写。 关于语言的条目旨在描述语言，而非定义语言；特别是，更改关于语言的条目不会改变语言（尽管它可能反映语言创建者/社区所做的更改，在这种情况下，条目最好解释更改内容和时间，以帮助理解早于该更改的程序的含义）。因此，与语言实际指定和使用方式不符的页面编辑只是破坏行为，因为它们导致页面不准确。一个特殊情况是旨在描述尚未创建且应由编辑者协作创建的语言的页面；这些不被视为描述语言的页面，因为语言不存在，且被禁止，因为通过这种方式成功创建语言需要参与者共享的强烈愿景，而页面开放给所有人时这种愿景不存在。 LLM生成的语言描述通常是错误的（且版权状况存疑）。即使语言本身是在LLM辅助下设计的，情况也是如此。因此，不允许使用LLM为Wiki编写语言规范： ** 如果语言仅以LLM生成的规范形式存在，那么唯一真正有趣的内容是在要求LLM创建语言时输入到LLM中的原始想法；其他一切都是由LLM扩展的内容，没有有用的信息密度。因此，这些页面被视为语言想法而非实际语言（尤其是因为LLM对这些语言细节的指定通常不充分或矛盾），应仅以核心想法的形式列在专门列出想法的页面上（例如[[list of ideas]]或关于LLM生成语言的页面）。 ** 如果LLM生成了一个实现，那么这可以作为一种具体方式来确定语言是什么（通过从实现中逆向工程所有相关信息）。关于此类语言的条目是允许的，但应由人类基于实现来编写，而不是假设任何规范（可能不匹配）中的细节是正确的。 某些编程语言并非深奥语言，但可以从深奥编程的角度来看待。这历来是一个争议点，但现在通常被接受，只要条目仅限于讨论该语言的深奥或不寻常方面。 关于深奥语言的页面通常''不会''仅仅因为该深奥语言的作者放弃它或认为它无趣而被删除——如果深奥语言被放弃，相关信息往往会更快消失，因此在此处保存它变得更加重要。如果该深奥语言无趣，则应将其页面与其他类似语言的页面合并。 == 关于类似编程语言描述的艺术作品的页面 == 一些深奥编程语言主要是为艺术目的而创建的。一个相关现象是类似编程语言描述的媒体，但为艺术或幽默目的而创建，并不存在实际的编程语言；这在深奥编程语言社区中有悠久的历史。此类事物的好例子包括[[xkcd 1537]]和[[TURKEY BOMB]]，两者都声称描述了一种真实的编程语言，但该语言实际存在是不可能的或不太可能的。 人们经常尝试直接将此类艺术作品发布到本Wiki（例如[[Vague]]）。然而，有许多原因导致这在实际中效果不佳： Wiki的目的是允许任何人通过编辑来改进内容——但允许对此类艺术作品进行任意编辑通常会破坏它，因此编辑者通常受到很大限制以不破坏页面。因此，Wiki不是托管它的好选择。 此类作品的幽默价值通常源于假装存在一种实际上不存在的编程语言，并像对待真实语言一样撰写关于它的内容。在一个旨在作为有用参考作品的网站（如本网站）上这样做，实际上意味着我们在托管错误信息并对用户撒谎；本网站的目的通常最好通过解释这个笑话来服务（因为寻找语言信息的人需要的信息），但这不能在作品本身内部完成。 此类页面通常难以归类，例如它们通常被放置在设计用于语言的类别中，尽管没有语言存在（例如，[[:Category:Unimplemented]]旨在帮助寻找要实现的语言的人，但此类艺术作品通常无法实现）。有时类别被用于推进笑话，但即使它增强了页面的艺术性，也会使类别包含不相关的页面，从而降低其有用性。 因此，处理此类艺术作品的正确方式是编写链接到它并描述它的页面，而不是直接将其托管在Wiki页面上。（如果它最初发布在本Wiki，最简单的做法是使用永久链接并将旧版本页面视为外部链接。）这些页面不应像语言一样归类（历史上这些被归类在[[:Category:Joke languages]]中，但应避免这样做，因为该类别也用于故意不可用但具有具体且明确语义的语言，如[[Unnecessary]]和[[Text]]）。 在某些情况下，例如[[SLOBOL]]，先出于艺术原因创建了对（不存在的）语言的描述，然后后来其他人基于该描述设计了一种语言。这两者应分开考虑（并作为不同实体记录），尽管根据情况，可能有必要编写一个同时讨论两者的页面（只要保持区分）。 == 关于深奥语言相关话题的页面 == 这里可以编写包含有助于理解深奥编程、设计/分析/编程深奥编程语言的信息的条目。这包括[[:category:concepts|概念]]如[[queue]]或[[Turing complete]]、关于[[:category:people|人]]（设计或从事深奥语言工作且单独条目会有帮助的情况）的条目，以及支持条目中（主题内）主张的[[:category:proofs|证明]]。与描述深奥语言本身的页面一样，这些应为关于概念/人/证明的实际条目，而非仅仅看起来像它们的笑话内容。 还可以编写关于深奥语言的重要实现（例如[[awib]]）或深奥语言程序（例如[[Lost Kingdom]]）的条目。 == 关于Wiki本身的页面 == 存在一些关于分类系统（Category:）和Wiki本身（Esolang:, Help:）的页面，但通常很少需要新的此类页面。特别是，创建新类别需要深思熟虑（它是否对导航有用？该叫什么名字？应使用哪些确切规则来确定包含什么？），并且只有在[[Esolang talk:Categorization]]上的讨论达成共识后才允许创建。新的Help:页面几乎从来不需要，因为关于如何使用MediaWiki的更好文档可在许多其他站点找到（例如[[wikipedia:Help:Contents]]、[[mediawikiwiki:Help:Contents]]）——它们只能包含关于Esolang的编辑与其他Wiki有何不同的信息，但几乎没有差异。同样，新的Esolang:页面几乎从来不需要，因为本Wiki通常避免大量正式流程（它足够小，通常通过人们的合理行为或相关讨论页上的讨论即可解决问题，这些讨论可通过[[Special:RecentChanges]]查看）。确实有成功创建此类页面的例子，但用户通常应谨慎行事。 新模板通常也应避免：模板的目的是能够在大量类似页面上使用它，但在此Wiki上几乎没有理由这样做（类似页面通常应合并），且新创建的模板通常不太可能被采用。（一个好的思考方式：在Wikipedia上模板可能有用，因为它们可以在特定主题领域的所有条目上使用，该领域的编辑者知道它的存在；但本Wiki只涵盖单一主题，因此任何有用的模板很可能已经创建了。） == 用于讨论的页面 == 重要的是，Esolang不能作为社交媒体网站使用。部分原因是它没有为此设置好（Wiki不适合作为社交媒体的基础），部分原因是许多国家正在对社交媒体网站施加限制，这些限制可能会对本站造成毁灭性打击（例如强迫社交媒体网站限制谁可以访问它们）。 因此，直接在本站上进行的任何讨论（在Talk:页面或类似页面）应涉及网站上已有的内容（例如，在深奥语言的Talk:页面上发帖以讨论该深奥语言或关于它的条目）；同样，在用户讨论页上发布的消息应涉及该用户在Wiki上执行的操作。 不鼓励使用过长或过于复杂的签名，因为它们通常只会使讨论页更难阅读，而对讨论无益——讨论应主要关注所说内容而非谁在说，而引人注目的签名关注了错误的东西。 用户子页面应仅用于原本可以成为条目的话题（除非页面或其描述的语言未完成）。用户页面通常应包含与关于该用户的条目相似的内容（但从不同的角度撰写，由用户本人而非其他人撰写）。 Add Comment Please, Sign In to add comment create new paste / syntax languages / archive / faq / tools / night mode / api / scraping api / news / pro privacy statement / cookies policy / terms of service / security disclosure / dmca / report abuse / contact We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand Not a member of Pastebin yet? Sign Up, it unlocks many cool features!