企划:一本有关程序的词典——《编程语言词典》

企划:一本有关程序的词典——《编程语言词典》

在传统意义上,词典是包容、严肃、客观、权威的代名词。

我们希望取得一个折衷:鉴于编者们有限的——事实如此——名声和学识,我们无法做到全部。于是,这本我个人(自私和专断地)认为对产业界将有一定益处的词典,我期望它在行文、体例、风格上做到前两者就十分足够了:我希望我们最终达到的是在包容各种主题同时保持必要的严肃,但又鼓励与工业实践结合紧密的个人看法。

所以,这是一本有关编程语言的词典。它的上一个标题是:《当我们谈论语言时我们在谈论什么——编程语言理论(PLT)术语和译名考释》。但我最终决定撤回了这个标题,并采用了现在的这个版本:《当我们谈论程序时我们在谈论什么:编程语言词典》。

你应该注意到了 “语言” 被替换成了 “程序”,而编程语言理论一词则被从标题中彻底删去。

我之所以决定作这样的更改,和我对这本词典最终或许能够达到的作用的期许是密切相关的:总的来说,我希望基于产业实践和研究编程语言本身,特别是基于一种编程语言比照文学、将编程本身比照文学创作、将比较文学比照比较编程语言学的方法,对编程语言本身呈现的繁多特性和实现到底如何落地以及如何影响代码生产,作出现实、有益的说明。

然而,这样的类比合适么?

我想我需要先说说这个问题:首先,编程到底是不是一种艺术创作?

我认为,是的。

我这么说,一部分是因为我确实具有另一面更加艺术的双重身份。我在一门较为罕见的乐器——爵士鼓——上投入了大量、大量、大量的时间和精力,如今我充分体会到了音乐(尤其是即兴的节奏创作)的美妙。至少就爵士鼓演奏而言于我已经早已不是一种练习,而是一种享受——特别是当你身处一支乐队,能和主音吉他手疯狂地黑贝斯手共同投入到一项能够真正缔结人们的活动中时。

在一个非常有名的有关代码哲学的talk中,演讲者提出了这样的说法:他说,任何设计以及建造同时发生在同一个人身上的心智活动,都是艺术创作。

比照我个人的经历和体会,这无疑十分适用传统意义上提出的艺术创作:对于绘画,脑海中的创想将创想画出来是同时发生在画家一个人身上;对于音乐——尤其是十分重要的即兴创作(improvise),而我个人将音乐创作本身也理解(并事实上实践)为反复即兴的过程——脑海中的音符手里的演奏同时发生在演奏者身上;而对于文学创作,将脑海中的文字具象为真正出现在屏幕或纸面上的,是作家,以及一切攥写博文的程序员们。

或许你已经理解了我的意思:是的,将脑海中的设计模式、实践经验等等具体落实为一行行代码的,是同时发生在一个程序员身上的事情。而比照如上的这一系列定义,编程也是属于艺术创作的一种心智活动。

如此可能我们就更能理解为何瀑布模型总是招致各种各样的批评:如果编程是一种创造性的艺术创作活动,那么强行将设计者实践者分开,就是不合适的。

那么,我们还要问一个问题。就算编程是艺术创作,为什么就偏偏要用文学创作和编程做类比?音乐就不配吗?美术就不配吗?

对于美术我缺乏实践经历,因而无法做太多说明。然而对于音乐而言,我认为,音乐代表的心智活动的侧面与文学代表的侧面存在差异:我说过,我个人理解、并践行着的是将音乐创作理解成重复的即兴工作;比起文学创作和代码创作,音乐创作要更加依赖灵感

这是因为我个人的体会是,音乐的即兴很少出现 “卡住” 的情况。即兴能力意味着你总能找到填补空缺的办法,如果有一首曲子 playback 刚好是你熟悉的风格,只要清楚了曲子的段落划分,从头到尾的演奏并不是困难的事情。

但是改进就要困难得多:对即兴节奏的改进十分需要灵感。六连音会更好听吗?这里是应该用 swing-swing 还是 three-two son claves?重音应该怎么加?是要用 accented note 还是 rim-shot?

与其说我真正地端详、费劲地思考,不如说我其实是在等待灵感来告诉我应该怎么做——这就是为何我强调反复即兴是创作的构成,因为在反复中灵感会自然出现——我个人的体验是,和乐队一起排练时这样的灵感会更容易、更好地出现,然而我也不知道为何如此。

我个人的体会,这样在反复的连续即兴中期待灵感,与文字创作、程序编写中经常出现的冥思苦想之间存在不同。这是否是在提示,这两者本来就是映照着心智活动的不同侧面?然而,这样一种可能的、通常是我个人一厢情愿地想当然的解释是否真正有科学依据(比如,常见的研究手段:fMRI),还有待考证。

所以,使用文学研究中强调比较的思路研究编程语言,是我想要提出的课题。

我想编撰的词典,并不因为我们——编者们,审核者们,如果真正有益,我还希望有翻译者们——有多么精尖的学识能力,在学术界内多么德高望重,在工业界内多么家喻户晓;而仅仅是因为,我们想这么做。我们充分明白,有数十万、甚至是数百万的人比我们更有资格做这样的事情,比我们更有资格写这样的条目,但我们依然这么做;所以,我们鼓励个人看法:在没有长久学术背景的支撑下,是很难保持中立和全面的。

我想编撰的词典,是一本和工业界联系紧密的词典——更重要的,它必须是一本讲人话的词典。卖弄抽象概念、尤其是数学概念将不被认可。我们已经有了太多太多浅尝辄止、介绍什么是 Monad、什么是 Functor,而且通常是以一种不太精确的类比(“Everything is a Box!”)的方式——我已不止一次在 Twitter 上看到过 “XXX is REALLY NOT a Box” 的图,有一群人在倡导理解抽象的唯一方式是通过抽象本身,而不是将抽象类比成实在。然而,通过抽象理解抽象是困难的,作为曾经的丘维声读者,我十分后悔当初将时间浪费在了这样的事情上。

所以,我想编撰的词典,致力于延续德高望重的 PLT 界学者、教师 Dan Grossman 在 Programming Languages 中提出的理念:我们希望,我们在词典中收录的条目,能够帮助人们认识到这些编程语言的不同的、美丽的侧面在不同语言中是如何实现的。我们坚信,基于强调实实在在的比较——而不是抽象概念——的方法,我们最终能够达到对所有语言和所有编程工作——而不是某一门特定语言——的良好认识,籍以此,我们最终能够写出更好的程序,我们的软件,我们的软件业会更加有趣好玩

这就是我想说的,我清楚认识,这是十分艰巨的任务——我无法独立完成。初步试读版(v0.0)的条目已多达70条,而在我完成其中纲领性文字和仅仅九个条目后,字数已经达到了惊人的两万字:我想,即便试读版再往后不增添任何条目,仅仅是完成现有条目的攥写,最终也可能达到完全是出版级的10w~20w字。

我希望我最终能够完成,这是前所未有的、对我个人努力和毅力的证明。我十分盼望一些我十分熟悉和信任的朋友能够帮助我,因为这其中实在、实在有很多领域我不甚了解:比如,有关语言实现(特别是优化)、语义、元编程(特别是 quasiquote)这些方面的内容,我几乎没有任何经验和经历——我所能做的,仅仅是极其片面、狭隘地罗列名词而已。

我说过,我们这样做,完全不是因为我们多有资格,而只是因为我们想这样。词典会包含大量的个人看法,我希望读者能够充分理解这样的必要性和无奈。如果你想参阅到本词典的编辑工作中来——这是庞大的工程,我们需要撰写条目、校对条目、新增条目、完善目录、修正格式——我希望,你是我熟悉、了解、最好是信任的人,你对技术和用人话传达技术有着同等的热情。我希望编者不超过十人,或许这样我们就不至于在各种沟通协调上花费过多的时间。

这不意味着我们的词典是面向零基础的:这无法做到。你不能指望不知道什么是指针的初学者去理解 高阶型别类型 higher-kind type, HKT 的概念和意义。对于本词典的目标受众,请允许我再次引用 Dan Grossman——我将他视作技术偶像,我的偶像们还有 Martin Fowler,Mark Reinhold,Brain Goetz,Aleksey Shipilev,Venkat Subramaniam 几位——的理念:如果你已经精通几门不同范式的语言,或许本词典能够给你带来最大的收益。

这就是我希望完成的东西——我是一个三分钟热度的人,我希望这是我与这样的评价作出对抗的第一步。我希望我能够在我的热诚消退之前完成它。

这就是我们的词典。这就是《当我们谈论程序时我们在谈论什么:编程语言词典》。


最后,我们十分欢迎——事实上,我们十分恳求——任何的意见和建议。我们致力于让绝大部分人理解我们这么做的动机,以及词典的内容。我们十分热衷修正任何事实性错误并改进理解性;如果你有任何看法,请与我们联系。你可以在左侧找到编者的邮箱或直接在下方给出的 Telegram Channel 讨论区中发言,但请不要使用下部的评论区——评论区没有任何的提醒机制

目前已经有一些朋友(我没有更活跃地寻找的原因主要是,我希望这篇文章完成后再这么做)参与、或应该会尝试一些编辑工作,他们都是我十分信任和敬佩的人。你可以通过单击顶部的 “朋友们” 页明白他们有多么可爱。

他们是(如果你的名字被包含在以下名单中,然而你其实并无此意愿,请与我联系,我非常愿意修正):

  • Ray Eldath,编者
  • 千里冰冰,审校
  • 染酱,编者

以上名单仅仅截至至本文发表时。新的参与人员将在词典和 Telegram Channel 中单独列出。

如果你希望即时了解本词典的编辑动态(新增的条目、完成进度等),欢迎订阅我们的 Telegram Channel:《编程语言词典》编辑动态,我会在完成的条目数量达到一定比例时将文章发上来,在此之前词典仅能在上面提到的 channel 中读到片段;我也会定期发布 Markdown 源文件(tag 是 “#工作文档”)作为参考,如有不便,还请谅解w

这波啊,这波是 Telegram Channel workflow


附:词典现已完成的一些纲领性文字和试读版目录

开篇词(必读)

本词典旨在收录整理有关编程语言的一些有合理定义、有现实意义、有产业基础、经可靠验证、经个人思考的术语及可信译名。展开来讲,我们认为本词典收录的条目需要满足以下原则,并且,我们以同样的标准考察对条目的增减:

  • 必须是广泛适用的术语。收录的条目必须具有广泛的现实基础,能够在多个语言及其社区中找到直接的例证,局限于某一特定语言或某一语言社区的条目不予收录。如:类型投影 type projection(Scala 术语)。
  • 必须有现实意义。我们相信对这些条目的阅读和研究能够确切地帮助人们建立对类型系统、语言特性、编译原理等方面的良好认知,同时帮助人们规范术语使用。如此的终极目的在于我们相信这些条目最终能够培养人们对程序和程序设计语言的敏锐知觉,从而写出更好的代码。这要求我们收录的条目必须具有现实意义,过于 “偏科”、或是明显借用自各种与计算机产业关系并不密切的纯理科目的术语,均不予收录。如:单子 monad
  • 必须有可信的合理定义。即是说,不仅我们认为我们引用(或提出)的释义有价值,很多人同样也这么想。这并不代表我们引用(或提出,下不作特别注明)的释义是无争议的——由于计算机界术语借用的广泛存在,一个术语最为流行的场景很可能与我们认为的确切定义相去甚远。如:多态 polymorphism
  • 必须避免主观意识过强和模糊不清的术语。我们充分认识到编程领域的很多概念纯属出自市场营销、广告学等等完全脱离技术话题的需要,细究这些术语不仅困难,而且意义不大。典例:函数式编程 functional programming
  • 建议有正面和反面例证。我们希望,除了提出单薄的理论释义,还要能举出条目在流行的语言中是如何体现和表达的——正反两面均是如此。
  • 建议仅提出经个人思考的术语。这并不是说我们鼓励一家之言——我们完全理解,任何定义、任何语词、任何精妙的思想都必须、且只能出自一个人的头脑。我们希望收录的条目是确切经过个人思考和领悟的,这通常意味着长期的编程实践,并持之以恒地在代码生产中主动领悟这些概念如何落地。我们不是——亦不鼓励成为——维基百科或教科书,我们认为,只有明白、易懂、与产业实践结合密切的行文方式才能最好地服务于我们的目标。
  • 鼓励简洁扼要的风格,鼓励严格、严肃和精确的措辞。如 “序言” 中列出的那样,我们多处强调了 “有且仅有一个”“三个以内为佳” 这样的标准。我们认为过长的释义和举例会造成较大的负担,并涉及过广的知识面。但请注意,这一原则仅是 鼓励 性的。

我们希望读者充分理解我们提出这些指导原则的意义和重要性,并根据这样的共识来看待本词典的体例、编排方式、组织结构和内容。特别提醒,我们鼓励个人思考:这意味着你将看到不少个人看法。

序言(必读)

开篇词已将我们编撰本词典的意义和目的阐述完全:我们的终极目标在于,我们希望通过这些(至少我们认为是)有价值、有意义、有重要性的条目,培养人们对程序和程序设计语言的敏锐知觉,从而成为更好的程序员。这并不意味着你能够更加精通某一门或某一组特定语言,这也不是我们的目的。我们希望实现的是揭开长久以来一直笼罩在各门编程语言之上的面纱;我们坚信,通过更深地领悟在编程语言的特性、实现和结构中体现的原理、哲学和思想,我们不仅仅能够更加精通某一门或某一组特定语言,而是更加精通所有的编程语言和所有的编程工作。从这个角度上说,我们立志传承——并尽力做到——德高望重的 PLT 界学者、教师 Dan Grossman 在他的课程 Programming Languages 中表达的理念和意图。

服务于这个目的,我们如此(依顺序)安排本词典中条目的体例和格式:

  1. 主题。如词典侧边栏所暗示的,本词典将各个条目分别归类为一些不同的主题,这些主题彼此之间是有关联的。由于本词典仍在编撰初期,主题及其层次关系可能发生变动;注意,一个条目有且仅有一个顶级主题
  2. 特殊标记(若有)。我们不建议收录任何的争议性术语,但我们理解或许确实存在这样的必要。目前可用的特殊标记有且仅有:争议性说明性广泛误用持保留意见高级主题交叉术语对立术语——当你在本词典中看到它们时,我们自会解释这些特殊标记的含义和缘由。
  3. 惯用译名(若有)。我们将按照一定的原则考据译名并给出我们认为最合适的(有且仅有)一个。然而,本词典并不特别专注于词语翻译:我们并不保证提出的惯用译名是最佳的,亦不为惯用译名作任何辩解——这即是说,本词典给出的惯用译名仅供参考
  4. 英文名称缩写(若有)条目必须具有英文名称,对于可能有多个名称的条目,我们选取尽量精确、但最为简单的那一个。如果该条目有惯用缩写,我们将列举常见的缩写记法。我们将按 惯用译名、英文名称、缩写 的顺序给出名称,英文名称保持全小写,缩写的大小写和惯用法保持一致。
  5. 释义。可以并推荐在释义中包含适量的个人观点,我们对条目释义的标准是:不能对读者有任何 PLT 领域专业知识和经验的假设,为此我们将尽量避免不必要的生僻术语——但我们希望读者理解,有时候这确有必要。注意,在释义中提及条目名称时,仅用一个惯用法指称即可,优先使用译名;在(且仅在)第一次提及条目名称时使用斜体(前后各加一个空格)。
  6. 正面典例(若有)。简单列举符合释义的工业实现——简单列举 即可(三个以内为佳)。
  7. 方面典例(若有)。类比上条(三个以内为佳)。
  8. 另请参阅(若有)。在条目释义的形成过程中参考的文献或推荐的阅读材料,简单列举即可。
  9. 注释(若有)。其它需要补充的内容。

对于本文的读者而言,本词典的体例大体是不言自明的。但若读者——我们十分欢迎——希望为本词典作出贡献,则需要特别注意体会这些体例和格式标准。详细的贡献指南请见本词典末尾 “结语和致谢” 部分。

最后,我们特别强调:我们并不保证条目释义的无争议和完美。我们尽量中立、尽量客观、尽量基于上述一切原则编撰条目——但毕竟人无完人。

本词典标题出自 雷蒙德·卡佛《当我们谈论爱情时我们在谈论什么》,然而好像大家知道这个句式都不是通过这本集子……

如何使用本词典(必读)

请读者相信:我们在此列出的建议使用方法是十分有效和必要的,这些建议提炼自本词典从头至尾隐含遵守的一些基本逻辑。

  • 阅读条目时,首先阅读该条目所属顶级主题的导言。条目是按照一个树状的主题层次、基于我们的认识编排的。我们为每一个 顶级主题 编写了导言:这些导言是统领性的文字和建议,它们和每一个条目密切相关。我们强烈建议阅读条目之前务必阅读这些导言,在左侧目录树中单击顶层目录即可直接跳转。
  • 注意并仔细阅读条目的特殊标记(若有)。我们为一些条目添加了 特殊标记:请读者相信,我们仅在绝对必要的情况下才会添加如此明显的特殊标记。当遇到一个特殊标记时,我们请读者认真阅读它们:尽量理解这个特殊标记的必要性,并理解它提出的建议。
  • 以分号分隔的条目名称列出了本条目中将涉及的多个术语,当你看见一个 SYN 时,表明我们认为该术语与前一个是同义的。需要注意的是,正如谚语 “世界上没有两片完全相同的树叶”,世界上也没有两个完全相同的术语。我们列出的同义性仅是参考性的:我们认为尤其是在实践意义上可以将它们交替使用。同义关系仅描述被标注为 SYN 的术语和它的前一个术语(以分号分隔),如果需要表达多个同义词,我们会使用多个连续的 SYN 标记。
  • 善用搜索功能(Ctrl+F)。如果你是有备而来,直接调出你的浏览器的搜索面板吧。但要注意:使用尽量宽泛的关键词,优先使用中文,不要忽略本节的其它内容。
  • 按顺序阅读。如果你并无目的,按顺序阅读本词典中的每一个条目是非常好的增广知识面的方式:我们特别依照一定的逻辑顺序(例如,客观存在的步骤,后者是前者的具体实现,后者会提及前者)组织本词典中的条目,请读者尽量按顺序阅读。
  • 阅读所有标明了 “必读” 的章节。它们为何被标为必读,或许读者们在读完后就会理解了。
  • 当需要深入了解时,查阅 “另请参阅”,并善用搜索引擎。毕竟这就是这些东西被发明出来的原因。
  • 我们十分欢迎问题和指正。这是写给人看的词典:如果你在文中发现有任何不够清晰的文字或者(最为糟糕的)存在一些错误,我们十分欢迎——事实上,我们十分恳求——听到你的反馈。你可以在左侧找到编者的邮箱,但请尽量不要使用本词典下部的评论区反馈问题:因为评论区没有任何的提醒机制。详细的贡献指南请见本词典末尾 “结语和致谢” 部分。
  • 注意,所有条目中主题、特殊标记、惯用译名、英文名称和缩写、释义以外的所有文字,均仅供参考

请按如下图例解释本词典中在目录树中为条目名称添加的标注:

  • 🔜:“未完成”。该条目未完成,不应阅读这些条目。编者不对这些条目中的任何文字负任何责任。
  • 🆕:“新增!😉”。这些条目是本版本相较于上一版本新增的新完成的条目,对于后者,这意味着在上一个版本中该条目被标注为 🔜.
  • ⏬:“在此处展开”。由于左侧的目录树默认堆叠同一个母标题下的所有子标题(为了更加简洁,我们赞同这个做法),这可能使你没法很快地通过浏览目录树找到需要的条目。为解决这个问题,我们在所有顶级主题之下的主题条目处增加了这一标识,这表示:通过在左侧的目录树中单击被这一标注标记的条目从而跳转到对应位置,目录树可以在此处继续向下展开。
  • ❌:“即将撤回”。出于一些原因,我们决定撤回此条目。被标记为 “即将撤回” 的条目将在下一个版本中被移除。未来我们可能会提供一个页面用于收录所有被移除的条目。
  • 🔶:“高级主题”。这些条目涉及的内容或多或少地有悖于我们在开篇词中提到的广泛性标准。但出于一些我们认为十分合理的原因和万分谨慎的考虑之后,我们仍然决定在本词典中收录它们。我们认为深入这些条目是有一定危险性的,因为你很可能不会从事与它们有任何关联的工作。具体的建议以及我们到底基于怎样的权衡收录了这些条目,请参看这些条目的特殊标注
  • 💠:“精华条目”。我们认为该条目所表明的思想十分有价值,值得所有读者阅读。这些条目可能有一些争议性,但我们认为,相较于这些条目对思想的启迪、对术语的规范使用和思想的清晰表达起到的促进作用而言,这些争议性是微不足道的。

试读版(v0.0)目录

  • 开篇词(必读)
  • 序言(必读)
  • 如何使用本词典(必读)
  • 基本概念(必读)
    • 编程语言理论, programming language theory, PLT
    • 语法, syntax; 语法分析 parser
    • 类型, type; 类型系统, type system; 类型检查 type checking
    • 语义, semantics; 代码生成 code generation
    • 一等支持 first-class support; SYN 一等公民 first-class citizen
  • 类型和类型系统
    • 🔜 静态类型 static type
    • 🔜 动态类型 dynamic type
    • 🔜 无类型 untyped
    • 🔜 类型推导 type inference; 完全类型推导 global type inference; 显式类型标注 explicit type annotation
    • 可靠性 soundness; 未定义行为 undefined-behavior, UB; 强类型 strong type; 弱类型 weak type
    • 完备性 completeness
    • 🔜 代数数据类型 algebraic data types, ADT; 和类型 sum type; 积类型 product type
    • 🔜 顶类型 top type; 底类型 bottom type
    • ⏬ 多态 polymorphism; 特化 specialization
      • 🔜 参数化多态 parametric polymorphism
      • 🔜 类型参数 type parameter; 受限类型参数 bounded type parameter
      • 🔜 泛型 generic
      • 🔜 单态化 monomorphization
      • 🔜 上下文界限 context bound
      • 🔜 子类型多态 subtyping polymorphism; SYN 子类型化 subtyping
      • 🔜 混入 mixins
      • 🔜🔶 型别 kind; 高阶型别类型 higher-kind type, HKT
    • 🔜 形式化验证
    • 🔜🔶 Hindley–Milner 类型系统
  • 语言特性和机制
    • 🔜 编程习语 idiom
    • 接口 interface
    • 🔜⏬ 继承 inheritance
      • 🔜 多重继承 multiple inheritance; 菱形继承 diamond inheritance
    • 🔜⏬ 分发 dispatch
      • 🔜 静态分发 static dispatch
      • 🔜 动态分发 dynamic dispatch
      • 🔜 双重分发 double dispatch
    • 🔜 表达式问题 expression problem
  • 程序和程序结构
    • 🔜 标识符
    • 🔜 表达式
    • 🔜⏬ 代码反复
      • 🔜 迭代 iterate; SYN 循环 loop
      • 🔜 递归 recursive; 尾递归 tail-recursive; 尾递归优化 tailrec optimazation; 互递归 mutial recursive
    • 🔜⏬ 控制流转移
      • 🔜 调用 call; 函数 function; 方法 method
      • 🔜 异常 exception
      • 🔜🔶 代数效应 algebraic effect
    • 🔜 闭包 closure
  • 语义和语义分析
    • 🔜 指称语义 denotation semantics
    • 🔜 操作语义 operational semantics
    • 🔜⏬ 作用域 scope
      • 🔜 词法作用域 lexical scope
      • 🔜 动态作用域 dynamic scope
  • 语言实现和优化技术
    • 🔜 原生语言 unmanaged language
    • 🔜 托管语言 managed language
    • 🔜⏬ 运行时 runtime
      • 🔜 运行时库 runtime library
      • 🔜 执行引擎 execution engine
      • 🔜 高级语言虚拟机 high-level language virtual machine, VM, HLLVM
    • 🔜⏬ 内存管理技术 memory management; SYN 内存回收机制 memory reclamation
      • 🔜 垃圾收集 garbage collection, GC
      • 🔜 手工内存管理 manually memory management
      • 🔜 资源获取即初始化 resource acquisition is initialization, RAII
    • 🔜 预先编译 ahead-of-time, AOT
    • 🔜 即时编译 just-in-time, JIT
  • 🔶 元编程和宏
    • 🔜⏬ 宏 macro; SYN 宏系统 macro system
      • 🔜 预处理器 preprocessor
      • 🔜🔶 卫生宏 hygeine macro
      • 🔜🔶 quasiquote
    • 🔜 代码生成 codegen
    • 🔜 字节码织入 bytecode woven
    • 🔜⏬ 领域特定语言 domain specific language, DSL
      • 🔜 内部DSL internal DSL
      • 🔜 外部DSL external DSL
  • 🔜 参考文献
  • 🔜 结语和致谢

以上所有内容均只至本文发表时。后续任何更新将仅在 Telegram Channel(见上文)上发布,本文不再另行更新。

<全文完>

企划:一本有关程序的词典——《编程语言词典》

https://ray-eldath.me/programming/dictionary-project/

作者

Ray Eldath

发布于

2021-02-20

更新于

2021-04-11

许可协议

评论

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×