程序员和软件开发者在命名上偏离了正轨

我们的领域不该充斥着伪装成专业术语的动物园式随机名词。清晰并非乏味，而是对用户时间与认知资源的尊重。

 💬 519 条评论 |  命名/变量命名/函数命名 | 

2022年12月，我在EmacsConf大会上观看了理查德·斯托曼的演讲，题为《我希望在Emacs中看到的功能》。斯托曼先生在演讲中提出一个有趣观点：“令人难忘的名称”，“我认为每个软件包[…]都应拥有能让人记住其功能的名称[…]。我们总倾向于为软件包取纯粹玩文字游戏或毫无明显意义的名字”。斯托曼在2022年仍需强调这一点，足以说明我们退步到何种地步——即便在以描述性命名著称的Emacs生态圈内(如dired代表目录编辑器，eshell代表Emacs shell)。

元素周期表

现代软件开发存在一种怪现象：我们集体默许用随机名词、神话生物或虚构角色命名已成为专业惯例。这种做法在其他技术领域几乎等同于职业自杀。

最近当朋友描述其基础设施状况时，我因难以理解其命名体系而想起斯托曼的评论。她这样说道：“我们用Viper进行配置管理，数据通过Cobra传输到命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有任务都通过Asynq队列调度。” 或许只有最后一个软件名暗示了实际功能，我却花了数分钟试图理解她提到的名称，甚至搜索了部分术语。搜索过程中我突然意识到：在其他领域交流时从未遇到这种情况——金门大桥会明确告诉你它横跨金门海峡。胡佛水坝就是水坝，以下令建造它的总统命名，而非“雷霆瀑布计划”或“水力守卫”。钢制工字梁因形似字母I而得名。即便工程师发挥创意，命名也遵循逻辑：蝶形阀确实酷似蝴蝶翅膀。你能清晰辨识名称与实际功能的关联，也能记住这些名称。若你编写过百款命令行界面，绝不会用眼镜蛇作为反驳。

化学工程等领域同样如此，其命名规范更为严苛。IUPAC命名法确保“2,2,4-三甲基戊烷”精确指代特定分子。绝无化学家会因“Steve”这个名字有趣就将其命名为“Steve”，试图让论文更平易近人。

历史并非始终如此(我认为)

我研读过大量软件发展史，实在难以断言曾存在过命名艺术的黄金时代(即便是资深工程师也曾犯下某些极其 荒谬的命名 命名))，但至少80年代存在某种理性的命名潮流：grep(全局正则表达式打印)、awk(Aho、Weinberger、Kernighan； 开发者姓名首字母缩写)、sed(流编辑器)、cat(连接)、diff(差异比较)。即便缩写形式，这些名称也或为功能描述，或为系统推导。没人会把复制命令命名为“闪光”，移动命令叫作“低语”。

早期编程语言遵循类似逻辑：FORTRAN(公式翻译)、COBOL(通用商业导向语言)、BASIC(初学者通用符号指令代码)、SQL(结构化查询语言)，据我所知Lisp代表列表处理。模式清晰可见：名称传递功能或渊源。大约在2010年代，某种模因病毒侵染了软件工程领域。或许起初只是无心之举——开发者厌倦了枯燥的企业命名规范，渴望在开源项目中注入个性？也可能吧。少数奇特的命名确实别具魅力。用动物命名数据库？当然可以，MongoDB(源自“humongous”)至少在词源上与功能相关，即便“Mongo”后来成了通用简称。

但我们并未止步于此。我们愈演愈烈。如今我们深陷无意义名称的动物园，名称与功能的关联已被彻底割裂。这种模式或许随着GitHub和初创文化兴起而加速。人人都想成为下一个谷歌——这个毫无意义的名字却因市场统治力成为标志。谷歌能耗费数十亿广告费打造品牌认知，甚至让品牌名成为动词；但你那个获得MIT许可证、仅有45颗GitHub星的文件解析器可做不到。

认知税

每个晦涩的名字，都是向每个遇到它的开发者征收的交易成本。当你看到“libsodium”时，必须从解决问题的模式切换到侦探模式：”这东西是干什么用的？让我查查README。啊，原来是加密库。为何取名sodium？是化学元素？还是指NaCl？倒也机智。”现在想象现代项目中数十个依赖库的叠加效应。每个依赖都索要贡品：几秒钟的思维解码时间。这些秒数累积成分钟与精力，最终堆砌成贯穿职业生涯的认知消耗之山。

试想你要向新工程师解释代码库结构、项目整体架构，梳理用于分派特定任务的依赖项，并阐明它们如何协同运作。不如再复述我朋友的话：“我们用Viper管理配置，通过Cobra提供命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有任务都通过Asynq的任务队列执行。”

现在请暂停并消化这句话：一条蛇，另一条蛇，音乐，一个神秘专有名词，还有…带q的async？你一半的脑容量都耗费在将这些任意符号与实际功能匹配上，而非聚焦于讨论的架构决策。这相当于心脏病专家说“我们将在您的耳内植入蝴蝶装置以改善雷鸣心律”，而非“我们将在动脉放置支架以提升心输出量”。试想阅读材料科学论文时的体验。当你遇到“高熵合金”或“形状记忆聚合物”时，名称本身就传递了信息。在阅读任何描述前，你就能根据专业知识推测其特性与应用场景。

常见辩解

此前我在分享命名顾虑时，曾听到以下辩解，现逐条回应：

  • “但易记名称有助于营销！”没错，如果你在开发消费级产品。但你的HTTP客户端、命令行工具或任何库都不是消费级产品。真正关心它的人只想知道它能做什么。
  • “描述性名称很无趣！”没错，外科手术器械也很无趣。当清晰度至关重要时，无趣也无妨。这可不是创意写作课。
  • “这只是为了好玩！”你的乐趣会产生外部成本。每个接触你“有趣”名称的人都要付出微小代价。在整个行业中，这些代价累积起来就是巨大的浪费。没错，我知道这并非我们当前最关切的问题，也不是行业面临的最大困境，但抱歉我必须提出来。
  • “所有好用的描述性名称都被占用了！”我们本可以像其他工程领域数百年来的做法那样，使用命名空间、前缀或复合术语。技术手段我们具备。即便做不到这些，至少让名称与产品相关联——加个“DB”后缀，或像“magit”那样玩些文字游戏。若无法做到清晰，至少要让人产生联想。

前进之路

这并非恶意所致——而是文化使然。当编程从企业主机转向社区开发者(这是好事)，社会规范也随之改变。

因此我们需要文化矫正。不是通过监管——开源依赖自由生存——而是借助社会压力和教育复兴专业标准。

库名应体现功能本质，采用复合术语，必要时容忍冗长。当开发者凌晨两点排查生产故障时，http-request-validator远比“zephyr”更具可读性。

若执意要用可爱吉祥物或文化梗，请将其设为项目吉祥物而非项目名。PostgreSQL有象宝宝Slonik，但项目本身仍叫PostgreSQL——象宝宝从未取代语义核心。

创意命名请留给注重品牌形象的终端产品。对于基础设施、工具和库，永远选择清晰明确。

下次当你想用最爱的动漫角色命名项目时，请停下来自问：“土木工程师会这样给桥梁支撑系统命名吗？”若答案是否定的，请另择良名。

我们的领域不该充斥着伪装成专业术语的动物园式随机名词。清晰并非乏味，而是对用户时间与认知资源的尊重。

本文文字及图片出自 Programmers and software developers lost the plot on naming their tools

共有 519 条讨论

  1. GNU版本的Yacc被称为Bison。Pine Is Not Elm(尽管这从未成为官方缩写)。UNIX最初是UNICS，这是对MULTICS的双关戏仿。我实在说不清dd代表什么。nano是pico的复刻版，而pico本意是“松树编辑器”。Postfix这个词完全是“邮件”的后缀与“漏洞修复”的混搭。C++是“C语言增强版”，C语言继承自B语言，而B语言又源自BCPL。

    开发者并非“迷失方向”，而是我们从一开始就从未真正掌握过方向。

    反观Clang、LLDB、jq、fzf、loc等现代项目，则完全契合作者对优秀命名的理念。“mise-en-place”这个词完美诠释了mise工具的功能本质。

    回复

    1. > 我实在想不出dd代表什么缩写。

      数据集定义。但这个名称在此语境下毫无意义——既不符合工具特性(它几乎不“定义”任何内容)，也不符合UNIX体系(UNIX中不存在“数据集”)。

      实际上，它特指IBM早期主机操作系统中作业控制语言(JCL)里的DD语句(具体是哪几个系统就不深究了，那又是另一堆复杂问题)。

      即便如此，DD语句与UNIX中dd命令的关联也相当微妙。简而言之，JCL中的DD类似于“打开文件”，更准确地说，是“向系统描述一个待后续打开的文件”。而UNIX工具dd的设计初衷，是为与大型机交换文件/数据集提供便利。当然，这完全不是它如今的用途，甚至在当时可能也并非如此。

      这也解释了dd命令奇特的语法结构——采用“键=值”或“键=标志1,标志2,…”参数形式。这种写法在UNIX中完全不存在，却是DD及其他特定类型JCL语句的运作方式。

      回复

      1. 我只记得它叫“Da Disk”——2000年代新金属乐歌词风格的称呼，因为它对磁盘干的事太疯狂了，懂吗？

        回复

        1. 最贴切的回溯缩写解释恐怕仍是“磁盘破坏者”

          回复

      2. 我记得是“转换与复制”，但cc已被C编译器占用，所以他们把字母后移了一位。这可能是个传说。

        回复

        1. 我也这么认为。但似乎还记得有人声称这并非事实…

          回复

          1. 我记得学的是“数据复制器”之类的解释…看来也是伪造的。

            回复

      3. 作为DOS用户(也可能是诺顿工具的用户)，我一直认为它更像是DiskDupe(磁盘复制)。

        有趣的是我们从未验证过那些“看似合理”的假设。

        回复

        1. “磁盘转储”也是常见(但错误)的猜测。

          回复

          1. 我总把它读作“[磁盘|数据]摧毁者”，因为操作失误时它确实会这么干。

            回复

            1. 确实如此。这些年读过无数篇“切勿使用dd，改用这个替代”的文章。但老兄，我就是爱dd啊。

              回复

              1. dd就像是把台锯的分刀片拆掉。

                不过话说回来，每当编写需要递归删除任意文件的程序时，我都会变得极度紧张。只要混入一条错误字符串，那绝对是灾难性的一天。

                回复

            1. 这让我想起IBM到HAL的命名，只是方向相反

              回复

      5. 哈，过去三十年我一直坚信它是磁盘直接访问。

        回复

    2. 必须指出C++采用的是C语言的“后递增”机制——即读取值与C相同，但读取后会递增C的值。这个比喻堪称完美。

      回复

      1. 同理，C♯中的升号由两个加号组合而成，象征着比C高半音。此外，小二度是西方音乐中最不和谐的音程之一，这恰恰完美隐喻了C♯与C的契合度。

        回复

    3. 连GNU都是递归缩写，Emacs更是复杂的递归缩写… Perl、Python、Java…这些又如何？还记得JavaScript命名由来吗？更别提Go(Go语言)或Pascal了…有人用过Git、Mercurial、CVS吗？

      我认为这纯属小题大做。

      回复

      1. 不过“并发版本/版本控制系统”这个解释倒相当合理。

        回复

        1. 那么Gimp也是个绝妙的名称，对吧？GNU-is-not-Unix图像处理程序：只要知道这个缩写代表什么，其功能就一目了然。

          Gtk同样如此：Gnu-is-not-Unix图像处理程序ToolKit(后来改为指代Gnome而非Gimp，我记得)。

          回复

          1. 而gdk则妙趣横生地被称为“非Unix图像处理程序工具包绘图工具”

            回复

      2. Java很简单——取自他们常喝的咖啡豆名称…

        CVS(注意到已有评论提及)只是个缩写。

        Python——嗯，蒙提·派森

        回复

        1. Java最初名为Oak，因其创造者办公室外可见橡树，但Sun的营销人员认为Java更具吸引力。没错，它确实以咖啡豆命名，但与语言本身或开发过程毫无关联，纯粹是营销名称。

          回复

          1. 完全能理解90年代的决策逻辑——当时咖啡馆热潮刚席卷美国，啜饮浓缩咖啡和拿铁简直是时髦至极的潮流。

            回复

          2. 想象个平行世界：Java叫Oak，且从诞生之初就优秀，而非历经数十年才变得出色。

            回复

        2. 没错，我只是想强调程序员从未坚持使用描述性命名…好吧，从来没有(这恰恰印证了GP的观点)。

          楼主整个论点根本站不住脚。

          回复

      3. 就传统命名体系而言，Pascal可能是最合理的命名。它以数学家布莱兹·帕斯卡命名，这位机械计算器双发明者之一。这种关联与致敬相当恰当。

        Git这个名字时刻提醒着我们：在企业利益主导之前，非主流程序员曾对主流思想怀有叛逆精神(我已尽量委婉表达)。但建议你亲自查证这段历史。

        回复

        1. >Git

          这蠢货内容追踪器。

          至今仍是我的最爱之一。

          回复

      4. 2000年代的Plan9社区宣称“Gnu is Not Useful”才是正确扩展。

        回复

        1. 若说我自1998年起就没把GNU/Linux当日常系统用就太可笑了：Plan9确实很有意思，相比GNU/Hurd，它的状态显然更成熟。

          (就连Solaris、*BSD系统都已开始集成GNU工具和编译器…)

          回复

      5. Perl的缩写全称是“实用提取与报告语言”

        回复

        1. 还有“病态杂糅垃圾列表器”这个说法。

          回复

    4. 这篇文章竟把AWK说成是作者名字的首字母缩写，还宣称这很“合理”？

      命名实属不易，尤其当“百万”新项目每日涌现之际。若立志“称霸世界”(即便在基础设施这类细分领域)，首先得抢注.com域名，选择自然有限。

      更何况名称还得足够独特才能通过谷歌检索。

      回复

    5. > 我死都猜不出dd代表什么

      传统说法？“Delete disk”(删除磁盘)或“destroy data”(销毁数据)。(因其常用于写入原始磁盘块。)

      回复

      1. 我一直以为“数据毁灭者”的传说部分源于人们误将if/of调换导致数据损毁的经历 🙂

        回复

        1. 我认为dd更常见的错误是写入错误磁盘(尤其当使用/dev/sdc这类命名而非/dev/disk/by-id/whatever命名时)。而混淆源目标导致数据覆盖的问题，我更常联想到tar命令。

          回复

    7. 同理，我记得曾读到X窗口系统之所以命名为X，是因为它是字母W之后的字母——W原本是首选(因“window”一词以W开头)，但该名称已被占用，故最终采用X。

      回复

      1. 看来X是刻意选定以表示对W的延续，而非与其冲突：

            名称X源于该系统的传承脉络。在斯坦福大学，保罗·阿森特与布莱恩·里德曾着手开发W窗口系统[3]，作为V系统[5]的替代方案——该系统最初由VGS[13, 221]衍生而来。[...] 我们为VSlOO系统获取了基于UNIX的W版本(由阿森特与克里斯·肯特在数字设备公司西部研究所开发，采用TCP[24]实现同步通信)。[...]显然，尽管同步通信在V系统中尚可接受(得益于极快的网络原语)，但在多数其他操作环境中却完全不够用。X正是我们对W的'回应'。"

        — https://dl.acm.org/doi/pdf/10.1145/22949.24053

        回复

        1. 我表达的意思其实差不多，只是措辞可能不够清晰。本质上，W早已存在，而他们正在创造新事物，所以选择了X。

          回复

        2. 哇。看来Wayland真该考虑用“Y”才对！

          回复

    9. Bison命名时代与当今唯一的区别在于项目泛滥。开源世界里那些可爱的名字背后藏着更多垃圾。当年一个人就能把C语言和Unix相关的一切可爱名称都记在脑子里。

      回复

      1. >Bison命名时代与当今唯一的区别在于泛滥。开源世界里那些可爱的名字背后的垃圾项目多得惊人。

        我个人认为现在用更严谨的名字取代可爱名字是个好主意。

        回复

    10. 命名是编程的重要环节，理应为软件赋予描述性强的名称。

      回复

      1. 当两个事物表面功能相似却实现方式不同时，如何在避免命名冗长的前提下区分它们？若修改软件或其部分功能使其焕然一新，该保留原名还是添加新称谓？若撤销该非 trivial 功能并新增另一项非 trivial 功能，此时该如何命名？

        我希望作者重读以下描述时能意识到核心矛盾：“我们用Viper进行配置管理，数据输入Cobra实现命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有操作都通过Asynq任务队列完成”——因为真正的名称，是工具所扮演的角色。具体实现名称本就偶然且模糊，因为软件可被大幅改动，使其名称除了作为项目标签外几乎毫无实用价值。项目标签必然具有不透明性，这与软件本身具有透明性的原因相同。理想比细节更重要。它们是利益与计划的交汇点，而非市场标签。若市场标签与功能固定绑定，世界将因实用性和市场性的明显原因而变得更糟。讽刺的是，斯托曼对PostgreSQL却毫无异议——姑且说它在语义上与项目相邻。这个名称仅描述项目的小部分(合成SQL语法)，而非项目本身。

        回复

      2. 我认为这涉及“代码即艺术”与“代码即工具”两种理念的交汇。我也喜欢用些俏皮名称给API方法命名…

        回复

        1. 记得写过个函数把字符串从蛇形命名法转驼峰式，命名为`humpify`。还有个函数能定位同名常量，叫`constantinople`。

          不过话说回来，这是Ruby嘛，向来以命名奇特著称。况且这两个函数都有实用/平淡的别名，且仅供内部使用。

          回复

      3. > 你总希望软件能有个好听的描述性名字吧

        比如微软Word？

        回复

      4. “计算机科学里只有两件难事：缓存失效和命名。”

        回复

      5. 嗯，到2025年SEO(无论LLM的术语是什么)会同样重要甚至更重要，这样才能搜索到文档和问题等

        回复

    11. 我同意我们从一开始就没有过，而且这最终意义不大。这似乎只是熟悉度问题。

      凌晨两点排查故障时，我才不管数据库查询是用Zapatos还是PG-ORM写的——即便后者更清晰。只要你用得熟，知道工具功能就行。

      回复

    12. 计算机科学有两大难题：缓存机制、命名规范和偏移量错误。

      回复

    13. 这点加上它比药品命名更通俗易懂，和市面上其他随机产品差不多。

      这并非说整个市场充斥着好名字——显然并非如此。但我认为它在任何时候都不算差。

      回复

    14. > UNIX 原本是 UNICS，这是对 MULTICS 的双关戏谑。

      虽非官方说法，但据我所知 Unix 这个名字源于“Multics 减去几位”的谐音。

      > 我实在说不清 dd 到底代表什么。

      我一直以为是“数据转储”之类的含义。

      回复

    15. 所以关键或许不在于“我们偏离了方向”与“我们从未掌握方向”的对比，而在于这种张力始终存在

      回复

    16. GNU代表“GNU’s Not Unix”(GNU并非Unix)。

      Yacc代表“Yet Another C Compiler”(又一个C编译器)。

      Nano最初名为TIP，意为“TIP Isn’t Pico”，后为避免与Unix工具tip冲突而改名[0]。推测nano是选取比pico稍大的计量前缀。

      个人而言，我更倾向于为命令行工具随机选择3-8个字母的字符串命名。至少这比使用通用名称(如Keep、Bamboo、Chef、Salt)要好得多，后者会导致各种命名冲突。

      文章节选：

      > 在其他技术领域，这几乎等同于职业自杀。

      这个市值8.8万亿美元(供给侧)的软件产业——规模超过谷歌、微软和苹果总和——竟以卡通企鹅作为吉祥物[1]。

      “从一开始就不存在”的评价完全正确。

      [0] https://en.wikipedia.org/wiki/GNU_nano

      [1] https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-…

      回复

      1. Yacc是“又一个编译器编译器”(Yet Another Compiler Compiler)，而非“又一个C编译器”(Yet Another C Compiler)。它适用于编写编译器，而非编译C语言。

        回复

        1. 尤其值得一提的是，据我所知，它实际上比C语言更早诞生。

          回复

        2. 没错，是我搞错了！这样解释确实更合理。

          回复

      2. “从一开始就不存在”这个说法完全正确。

        需要澄清的是：我并非暗示这是坏事。

        GNU’s Not Unix、Pine Is Not Elm、TIP Isn’t Pico都具有一个重要特征——它们的受众被默认了解Unix、Elm、Pico是什么，而“X不是Y”的表述暗示着“X是刻意模仿Y风格的替代品”。

        若你了解GNU和YACC，“Bison”作为GNU版YACC的命名无需赘述——双关语使其瞬间令人难忘。

        我个人最欣赏的是Ubuntu的版本命名方案。这种“头韵动物名”形式极具记忆点，且提供两个可记忆的词汇——任取其一都能唯一标识版本。字母排序特性更便于判断新旧版本(字母冲突周期为13年，极少引发混淆)。

        回复

        1. > 用户理应了解Unix、Elm、Pico等术语

          当然，这些典故都植根于90年代的时代背景。若有人在公元2025年初次接触Bison，恐怕连YACC是什么都毫无头绪…

          回复

    17. > Yacc现在叫Bison

      而他们给“又一个编译器编译器”取名时，总觉得没当真。

      回复

  2. > grep(全局正则表达式打印)，awk(Aho、Weinberger、Kernighan；创作者首字母缩写)，sed(流编辑器)，cat(连接)，diff(差异比较)。即便缩写后，这些名称要么是功能描述，要么是系统推导。

    若询问不熟悉Unix工具者这些命令的功能，唯有diff可能被勉强猜中。抱怨“libsodium”却将“awk”奉为“好名字”实属荒谬。

    回复

    1. 没错，这绝对属于“用惯了就觉得自然”的范畴，这些命名本身并无特别之处。

      根本问题在于，如今每天要接触海量命名对象(工具、库、程序等)，它们都必须通过某种方式区分。显然不能把所有加密库都命名为`libcrypto`。

      回复

      1. 行吧。那就叫sodium-crypto.a或sodium.crypto.a之类的。作者的抱怨确实有道理。

        回复

        1. 当然可以，但这样会导致名称冗长。而我们通常更青睐简短易输入的名称(尤其对命令行程序而言)。既然要这么较真，那为什么不把Unix工具命名为concatenate、difference、stream-editor之类的呢？这些名字在说明功能方面确实更胜一筹，但从可用性角度看，它们简直糟糕透顶。

          库和程序也常会逐渐改变其核心功能和用途。此时更改名称通常并不合理，因此你最终仍会得到与实际功能不完全匹配的长名称。试想如果我们需要输入tape-archive来创建tar包——这个名称虽符合历史准确性，却无法揭示当今人们的实际使用方式。名称得以保留，纯粹因为tar本身过于通用，且更名阻力太大。坦白说cat也是同样情况——我极少见到有人用它连接多个文件，更多是将其作为单文件输出标准输出的工具。

          作者忽略了关键事实：诸如libsodium这类库的命名逻辑，其实与他列举的其他案例并无二致。倘若他常使用libsodium，或许也会因其与盐值的关联性而赞其命名得当，转而抱怨其他不熟悉或少用的库名。我理解他的恼怒，但关键在于这根本不是新鲜事，只是他现在才注意到罢了。

          回复

          1. 短名源于电传打字机时代反复输入的困扰。至少三十年来这种情况已不复存在。绝大多数优秀的shell+终端组合都支持自动补全功能，即便是冗长的Powershell，借助shell历史记录和自动补全(顺带一提，它在这方面表现出色)也变得相当易用。

            若你仍在反复输入库名，说明你的工作流程存在问题。

            尼古拉斯·维特通过Oberon文本/命令界面为我们指明了摆脱电传打字机时代的道路，后来Plan 9笨拙地模仿了这种设计，但我们似乎仍深陷电传打字机时代——主要归咎于Un*x系统。

            回复

            1. `eay` 仅是原作者姓名首字母缩写，本质上与 `awk` 无异。

              回复

        2. > 作者的抱怨确有道理。

          讽刺的是，这恰似钠元素本身——作者似乎体内钠含量过高。

          回复

        3. 未经查证，此处“sodium”是否指代“盐”？其与实际用途的关联性(盐+哈希本是加密领域常见组合)与根目录评论中其他命名别名相差无几。

          回复

      1. Ruby的“rubygems”库曾有别名“ubygems”，这样调用ruby时使用-r选项(加载库)就能写成“ruby -rubygems”。可惜这个别名库似乎在Ruby 2.4左右被移除了。

        回复

          1. 哇，我之前不知道un.rb的存在。看起来挺酷的。

            回复

      2. 有位朋友创建了一个名为library的库，算是它的反向操作(必须用-lrary参数链接)。这玩意儿逗乐了三十秒，之后就纯粹烦人了。

        回复

    3. cat一词可追溯至catenate，这是比concatenate更精炼的表达。默认情况下，未修饰的catenation表示连接(字面意为“形成链条”)，始终具有“结合/共存”的含义，因此con前缀实属冗余。若需表示分离的catenate衍生词，可创造discatenate，此时dis前缀便发挥关键作用。

      另外，人们聚集时为何用“gregarious”而非“congregarious”？为何不直接用“gregate”？拉丁语中明明存在不带“con”前缀的同源动词。

      回复

      1. > 为何不直接用“gregate”？

        因为拉丁语介词体系不允许这样操作。例如“Marcus ex casa exit”(‘马库斯走出房屋’)必须同时使用介词“ex”和动词前缀“ex-”。即便在现代英语中仍存在类似现象：“they gathered together”(他们聚集在一起)这句话就包含两个“gather”。

        回复

    4. 这似乎也不合理？libsodium在简介页就解释了命名逻辑：它是NaCL(钠盐化学式)的分支，而NaCL本身是“网络与密码学库”的纯缩写。谷歌似乎也不是好例子。这名称不正是暗喻超大数“古戈尔普勒克斯”吗？正如谷歌存在的意义是驾驭网络上难以估量的信息量。作者或许不喜欢这些名称，但它们和grep、awk一样自有其逻辑。

      回复

      1. 事实上，这种关联更为直接。

        “Google”源自“Googol”，后者指10的100次方。显然，“Google”这个公司名称是该数字的偶然拼写错误。

        该数字(googol)并无特殊数学属性，其名称由1920年代一名9岁儿童创造。

        古戈尔倍克斯(Googolplex)即10的古戈尔次方，也就是10(10100)。

        而谷歌大厦(Googleplex)则是谷歌位于蒙特雷湾的园区。

        回复

      2. 本该命名为氯(chlorine)，因为“NaCL”中的“Cl”代表密码学库。

        回复

    5. 我不确定是否喜欢awk、sed或cat，这些名称只是习惯使然，其实并不理想。diff还算可以。

      grep几乎具有拟声词特性…听起来就像从文件中抓取或撕扯出模式，对吧？

      回复

      1. >我不确定是否喜欢awk、sed或cat

        sed并非如上所述的“流编辑器”，而是“流ed”——其中ed是另一个早已存在的必备程序，人人皆知。其名称源于“editor”的缩写。

        sed命令本质就是ed命令。因此几乎不可能说“我不喜欢这个名字”——它承载着深厚的传统，是ed的流式版本。(ed命令的核心逻辑与vi命令高度相似。)可惜Unix群体从未真正理解teco，因为teco本就是源自非流式传统的可编程流编辑器。它比ed早诞生十年，本可完美契合Unix世界。或许它当时已过于庞大？我确信Unix开发者必然知晓其存在。Emacs确实承袭了teco的传统。

        grep的命名源于在ed编辑器中输入“grep”命令时的显示效果。

        awk不应被视为工具，它本质是编程语言，与ada、pascal、haskell等同等拥有命名权。

        彼时文件名必须简短，禁止使用长名和空格，且人们偏好输入简短命令。concatenate缩写即… 而cat这个名称同样恰如其分。当时“控制台”(console)一词常用于指代直接连接计算机的终端设备(通常已登录)，或许con当时已被占用——它在DEC操作系统机器上确有既定含义，此含义被微软机器继承下来：CON:至今仍指控制台，而贝尔实验室当时正使用DEC机器。

        顺带一提，某些系统存在“dog”命令。它类似“cat”命令，但从文件末尾开始读取并显示新增内容。因此若需监控日志文件的增量内容，可对文件执行“dog”操作(此功能在VMS Windows系统强制二进制化后完全失效)。英语动词“to dog”本意为“紧随其后”，故此命名既是“cat”的俏皮变体，又精准体现功能特性，类似“less is more”的设计哲学。在less中，可通过“F”命令实现类似“dog”的功能(带更多上下文的“狗”)。这些文字游戏虽不构成完整体系，但随着新功能的诞生，它们既增添趣味又助你记忆新命令，直至熟练掌握。

        回复

        1. > ed命令本质上与vi命令高度相似

          vi正是基于ed构建而成。

          Ed作为Unix行编辑器，其所有冒号后命令均采用“起始行,目标行”格式，例如“1,$p”可将文件所有行输出至终端/点阵打印机。

          1,$s/findexp/replace/g 将替换第1行至文件末尾所有findexp的实例(“g”表示全局替换)

          回复

          1. 这些设计都源自计算机尚未普及玻璃显示屏的年代。终端不过是键盘与打印机组合而成，或是打字机一分为二的产物。纸张。没有光标。没有方向键。大多依赖穿孔卡片，且处于晶体管时代之前。而这不过是几十年前的事，至今仍有亲历者健在。

            有趣的是，这些至今仍是最高效强大的界面形式。

            回复

            1. 拜托，我没那么老。今年61岁。

              1977年入学时，我们用的是16K内存的PDP-11，配三台ASR-33终端通过20毫安电流环连接。还有台VT-52显示器。全系统110波特运行。没有电子管，全是晶体管和集成电路。那套系统当时就已过时。

              穿孔/标记感应卡仍在使用。

              两年后我们有了PET、Apple-II和TRS-80。

              电传打字机自1940年代就已存在。

              网上和别处都能轻易查证，别再编造虚假历史了。

              回复

        2. > 别把sed说成“流编辑器”，它明明是“流编辑”

          根据手册页，它确实是“流编辑器”：

          https://man.cat-v.org/unix_8th/1/sed

          我早就知道它与’ed’的关系(毕竟在远古时代还真用过’ed’)。但这并不改变它确实代表“流编辑器”的事实。

          读完你的帖子后，我心想“这似乎不对，我记得它明确被称为’流编辑器’”，于是去查证。

          回复

      2. 这些名字之所以优秀，在于它们简短且易于识别。

        回复

          1. 是啊。这些家伙大概35年前就抢先占用了。可能更早。先到先得嘛。

            回复

    6. 不过一旦知道sed代表流编辑器，就永远不会忘记。libsodium倒是容易遗忘。

      回复

      1. > 不过一旦知道sed代表流编辑器，就永远不会忘记。

        感觉这是我第三次学到这个了。

        回复

        1. 我用Linux近二十年，其中大量时间都在用sed。肯定听过这个缩写，绝对听过，但看到楼主写出来时我恍然大悟：“啊，原来如此”。

          回复

          1. 我用Linux三十年了，更早之前就知晓sed的功能和名称，至今未忘。

            回复

            1. 我当然记得它的功能，每周至少用一次，多数时候每天都在用。但若问我“sed”的缩写含义，恐怕想不起来。或许会猜猜看，因为有“ex”编辑器的关联，勉强能联想到“扩展”之类的词，除此之外就没头绪了。

              回复

      2. 别忘了这需要英语基础才能用。我敢说多数Unix用户根本不会英语(绝大多数计算机用户肯定不会)。我接触过的人除了“你好”“再见”外几乎不懂其他词汇，对他们来说“sed”就是个毫无意义的乱码组合。就像Excel之类的随机符号，根本不代表任何含义。

        当然，sed只是个例子，作者的观点对全球多数(甚至绝大多数？)用户而言并不成立。

        回复

      3. 哈哈不。Unix工具和命令多达上百种，其中90%我根本搞不懂。sed的缩写含义我绝对说不出来。就算明天再问我，我依然答不上来。

        C语言程序员很棒。我热爱C语言，希望所有东西都有纯粹优美的C语言API。但C程序员必须被严禁命名事物——他们的命名特权已被永久剥夺。

        回复

          1. 引用bash.org(或qdb.us？)的说法，你必须用德语口音和tar对话：

                tar xzf file.tgz

            其中xzf代表“extrakt ze feil”

            回复

            1. 正确发音是`xaf`，因为现代世界过于复杂，简单的日耳曼语法规则根本无法解决。

              但GNU tar从来不是问题所在。它几乎完全直截了当，唯一的问题是人们常将tar文件与目标目录混淆。若你用过某些UNIX tar版本，就会明白为何人人都讨厌它。

              回复

          2. 周五酒局时有人向我发起挑战，我用“tar –help”成功破解。挑战者徒劳辩称此法无效，但全场一致认定退出状态码为零即为有效解法。

            回复
            1.   $ tar --help
  tar: 未知选项 -- -
  用法: tar {crtux}[014578beFfHhjLmNOoPpqsvwXZz]
             [压缩因子 | 格式 | 归档文件 | 重复字符串]
             [-C 目录] [-I 文件] [文件 ...]
         tar {-crtux} [-014578eHhjLmNOoPpqvwXZz] [-b 阻塞因子]
             [-C 目录] [-F 格式] [-f 归档文件] [-I 文件]
             [-s 重复字符串] [文件 ...]
  $ echo $?
  1
              回复

              1. 这不是 GNU tar 的输出。建议确认您的安装是否正常。

                编辑：或许我没看懂这个梗？

                回复

                1. 一群醉汉在 GNU 形状的回音壁里认定世界是 GNU 形状的。就算真有梗，这也不算什么笑话。诸如“unix即linux”、‘用户空间必须是gnu’、“bash已安装”等当下流行的公理，都能通过违反这些假设的unix系统证明其推理基础薄弱。XCDD漫画未定义unix系统的本质更令人担忧——不同定义可能将linux和OpenBSD都排除在外。

                  回复

                2. > 或许我没看懂笑点？

                  炸弹只标注了“Unix”，所以不能默认是GNU(啊哈，GNU并非Unix)

                  回复

            2. 这在GNU版tar上可行，但其他Unix系统的tar可能不行。

              “tar cf /tmp/a.tar $HOME” 应该能在所有 POSIX 系统上运行。

              回复

            3. 我记得90年代用过“tar xvf filename.tar”，试试看。要是搞错了，等发现时我早死了。总比死于癌症或阿尔茨海默症强。

              回复

              1. 我至今每周至少执行一次。还会用“tar xzpvf”或更复杂的命令，比如：

                    tar cvf - -C /foo/bar baz | zstd > foo.tar.zstd
                回复
              2.     tar zxvf

                这行命令早已刻进我的脑海。我最早接触Linux命令行的经历，就是解压压缩过的tar包。

                所以从这个角度说，那张xkcd漫画对我而言“一点都不好笑”。当然除了手册页，我几乎说不出其他用法。

                回复

                1. z 表示需要使用 gzip 压缩，这很可能是 GNU 的扩展功能(据我记忆，bzip2 对应的是 j)。另外，f 参数必须放在最后，因为它是参数化操作，后面必须跟文件名。

                  因此我始终选择c(创建)而非x(解压)，因为后者要求存在tar文件(无论是zx、xz还是gzip压缩的tar文件；不确定它是否能智能区分压缩的.Z文件和.gz文件)：使用创建模式时，在xkcd场景中更可能幸存。

                  回复

                  1. 如我所言，当时处理的是大量压缩tar包。不确定你回复的内容具体指什么。

                    另一位评论者已指出，xkcd漫画仅标注“有效”而非返回0(公平地说，原始非xkcd版本要求返回0，所以混淆也情有可原)

                    回复
                  2.     tar xvzf file.name

                    无论文件是否存在，这始终是合法命令。当文件不存在时，tar会以状态码’2’退出，但这并不影响命令本身的有效性。

                    对比以下两段日志：

                        $ tar xvzf read.me
    tar (子进程): read.me: 无法打开：没有这样的文件或目录
    tar (子进程): 错误不可恢复：现在退出
    tar: 子进程返回状态 2
    tar: 错误不可恢复：现在退出

    $ tar extract read.me
    tar: 无效选项 -- ‘e’
    请使用 ‘tar --help’ 或 ‘tar --usage’ 获取更多信息。

                    你真的不明白“你让我做的事我做不到”和“你只是在胡言乱语”的区别吗？

                    回复

                    1. GGP将基准设定为“返回退出代码0”(针对“–help”)，即便XKCD使用的术语是“有效命令”，也存在双重解释空间。

                      你其余的轻蔑言论纯属多余，但选择刻薄是你的自由。

      4. Libsodium并非普通用户会随意使用的工具或程序。任何在项目中实际用过它的人，哪怕只用过一次也会铭记于心。

        你多久会忘记Firefox或Gnome是什么？

        回复

      5. 我认为这正是关键所在。重点不在于能否一眼猜出函数功能。关键在于当你理解命名由来后，功能与名称能相互成为记忆的助记符。

        回复

        1. 那么文章的论点是否就显得不那么有力了？

          文中声称grep是“命名精妙”的，因为尽管初看不明显，但它实为“全局正则表达式打印”的缩写，因而令人难忘。但同样的论点是否也适用于libsodium？若读者熟悉NaCl(如同前文假设读者熟悉正则表达式)，那么这个加密库的命名同样具有记忆价值。

          命名时必须考量其预期使用场景与实际应用环境。文章提及工程命名与“ibeam”，但工程领域本身也存在专属术语。多数人不知“4130管材”为何物，但自行车车架或防滚架制造者心知肚明——若无需区分4130与4145，他们更可能使用笼统的“铬钼钢”。

          在我看来“libsodium”的命名逻辑类似——若你连它(及NaCl)的含义都不了解，就绝对不该接触代码库的这部分。

          回复

          1. 命名争议存在一个连续谱。sodium并非完全随机，因其在加密领域有“盐”的特定含义。这如同说libsodium属于加密库的一部分。awk则更具随机性。

            当项目创建者看似随意命名时，这种争议更具说服力。

            回复

          2. grep(及其他命令行工具)还面临额外挑战：名称本身是日常交互体验的核心。它需要简短、易读、易输入。而库文件中封装的API则承担着类似功能。

            回复

        2. “libsodium” → “盐” → ‘加盐是与密码学相关联的概念’，作为记忆法远胜于“awk代表作者姓名首字母”。

          回复

      6. grep亦然——前提是 我猜这需要你了解正则表达式的含义，对于70/80年代接触Unix系统命令行的群体这或许合理，但对30岁以下成长于Windows环境、可能在6周或26周“速成班”里连这类历史基础都来不及学的新生代开发者，这个前提还成立吗？

        回复

        1. 正则表达式更偏向计算机科学领域(归属于正则语言)，不过“re”和“regex”这些常用缩写，我在计算机科学正式教育前后都只在实际工作中见过。

          回复

          1. 没错，我完全有理由期待计算机科学毕业生、老派Unix系统管理员和Perl黑客精通正则表达式。但对于速成班的前端网页开发“毕业生”、自学触屏游戏开发者，或者(不确定？)那些职业生涯都在微软开发环境中度过的工程师，我可不敢这么想。

            回复

    7. > 抱怨“libsodium”又把“awk”奉为良名，实在荒谬。

      awk简短易读，不易混淆，堪称近乎完美的命名典范。

      > 若让不懂Unix工具的人猜测这些命令功能，diff是唯一可能被猜中的。

      你似乎混淆了“名称”与“描述”的概念。命名的核心意义正在于其非描述性。

      https://en.wikipedia.org/wiki/Arbitrariness#Linguistics

      回复

      1. > 名称的本质在于其非描述性

        我其实认同这点，但这恰恰与原文论点背道而驰。

        回复

    8. 如今鲜少有人使用物理磁带，但“磁带归档”(tar)却依然无处不在。

      并非全无道理：“awk”是个好名字，因为只需输入三个字符；“rg”比“grep”更优，因少输入两个字符。

      回复

      1. Unix基础文件命令采用ls、cp、mv、rm自有其道理。

        这些在终端上输入便捷。

        grep源自ed命令“g/re/p”：g(全局搜索，即“1,$”的缩写)/re/待搜索的正则表达式，p表示打印行。

        在vi中依然有效。

        回复

      2. 要不是磁带和磁带驱动器贵得离谱(笑)，我早就这么干了。

        回复

    9. “抱怨’libsodium’却把’awk’奉为良名，实在荒谬。”

      我始终不明白NaCl库究竟“问题”何在，竟需要另起炉灶推出不含“nacl”字样的版本

      我还记得谷歌在NaCl库发布后，把某个大力推广的非加密项目也命名为“NaCl”，导致搜索“NaCl”时结果都被谷歌软件刷屏

      我至今仍在用原始NaCl库，比如CurveDNS、tinysshd、dq和dqcache都用它，不用libsodium

      回复

    10. 没必要深究文章内容。只需记住——emacs。当然我知道它是什么，不过我得谷歌搜索才查到全称是EditorMACroS

      回复

    11. 这在任何行业都是行话。这些术语看似无意义，但花一分钟学会后就成了你的词汇库。

      至少这类缩写曾有过实用价值——当年键盘空间珍贵，每天手动输入命令耗时数小时。输入cat和concat的效率差距就是数小时的生产力。

      回复

    12. 关键在于它们并非随意组合。它们背后存在约定、传承或规则。现代项目却常直接跳过这步，连基础管道都直接冠上品牌名。

      回复

    13. 当前命名法的问题在于滥用“咖啡”这类通用词，导致难以检索或理解。至少老Unix命名法还算独特，有时还暗含深意。不像如今这般。

      回复

      1. 没错。cat、find、git、date、gimp、gnu——这些名称都极具辨识度且便于检索

        回复

    14. 挑刺：若我理解有误请指正，cat应是catenate而非concatenate

      依我之见，最优秀的命名当属最易输入的名称。我读过不少作者因这个原因选择名称的案例

      我偶尔会重命名他人的可执行文件(参见库文件)，不是传统UNIX用户空间里的那些，而是那些名字怪异1的。我会改成更易输入、更不惹人烦的名称。若认为原名可能需要2，我会创建符号链接保留原名

      对于自有软件，我给每个程序编号：源文件按编号命名，可执行文件则以短前缀加编号命名。所有名称长度统一。若忘记功能，可查阅描述文本文件

      我在每个源文件开头添加注释作为标题，这样就能执行：

         head src/???.l

      即可获取所有说明列表

      1. 毋庸置疑，Arthur Whitney的软件不会被重命名。没必要，他自己就够用了

      2. 若参数解析和“usage:”输出令我烦躁，我也会重写这些功能

      判断程序功能的最佳方式是阅读源代码。这正是我偏好从源代码编译程序而非使用“二进制包”的原因之一

      我也觉得所谓“科技”公司取的名字通常相当愚蠢，不过这又是另一个话题了

      回复

    15. >开发者们在给工具命名时完全偏离了正轨

      作为完全的外行人，我总觉得他们压根就没找到过正轨可循……

      回复

    16. 我觉得你误解了重点。像awk、sed、grep这类工具名确实与功能相关，但文件浏览器取名“zephrus”就和实际功能毫无关联。

      回复

    17. awk是awkward(笨拙)的缩写，就像awkword(笨拙词)一样，用于笨拙地处理文字(文本)。

      回复

  3. > 在其他任何技术领域，这都等同于职业自杀。

    这篇文章肯定会反对你的观点：

    https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Def…

    > 金门大桥的名字就说明它横跨金门海峡。

    这种区分有意义吗？有人会想“天哪，我真想穿越金门海峡”吗？还是都想着“我要去纳帕谷”？

    > 胡佛水坝是一座水坝，以下令建造它的总统命名，而非“雷霆瀑布计划”或“水力控制工程”。

    其实建造期间它叫“博尔德峡谷工程”，竣工时虽在罗斯福执政时期仍被称为“胡佛水坝”，官方名称为“博尔德水坝”，后来才正式更名为“胡佛水坝”。

    赫伯特·胡佛启动该项目的事实，对理解其本质毫无意义。难道“Reitzlib”比“请求”更适合作为项目名称？

    > 即便编写过100个命令行界面，你也永远无法用眼镜蛇反制它。

    但在现实世界中，你可能遇到谢尔比眼镜蛇跑车、贝尔AH-1眼镜蛇直升机、美国海军眼镜蛇号巡逻艇(SP-626)、柯尔特眼镜蛇手枪等。

    > 没有化学家会突然决定把化合物命名为“史蒂夫”，只因“史蒂夫”是个有趣的名字，就以为这样能让论文更平易近人。

    打开药柜时，你会寻找标注“乙酰水杨酸”、“2-丙基戊酸”或“N-乙酰-对氨基苯酚”的药瓶吗？大概不会。

    当文章中所有例子都与作者观点不符时，这绝非好兆头。

    回复

    1. > > 没有化学家会突然决定把某种物质命名为“史蒂夫”，只因这个名字有趣就能让论文更平易近人。

      作者的观点完全错误。化学领域充斥着各种俏皮名称，既是作者的自娱自乐，也是为了让算法在业内更易记忆。

      随手列举：

      – SHAKE和RATTLE：键约束算法
      – CHARMm：分子动力学软件包，但从名字完全猜不到
      – Amber：另一款分子动力学软件包，同样无法从名称联想到功能
      – NMR领域的缩写更是数不胜数：COSY、TOCSY、NOESY
      此类例子不胜枚举，几乎渗透到所有子领域。

      若想找真正可爱的名字，分子生物学才是宝藏。

      回复

      1. > – 核磁共振领域缩写层出不穷：COSY、TOCSY、NOESY

        我最爱的是MAS——魔角旋转。毕竟每篇论文都需要点魔法元素。

        若想找讨厌傻气名称的人群，科学家绝对是最不合适的选项。这类名称遍地开花，正因我们不排斥趣味性——这确实能让人过目不忘。我们还热衷用人名命名事物，这种做法堪称最不具描述性的命名方式。

        回复

        1. 另见物理学领域：“夸克”、‘奇’、“魅”

          回复

      2. 物理学有“奇异性”和“魅夸克”

        我所在的材料工程领域则有：

        “硬度”、‘韧性’、“弹性”等描述不同特性的术语

        “铁磁性”与“反铁磁性”——请务必相信它们截然不同

        回复

      4. 镅、锷、不可得元素也说明化学命名并非如某些人认为的那般刻板。

        回复

        2. 不可得铀是电影《阿凡达》的虚构元素哈哈

          顺带一提，这段台词的铺陈堪称灾难级(“这就是不可得铀！我们此行的目标就在这里！”)。

          回复

            1. 我高中物理老师在课堂上用过“不可得金属”这个词，据我所知他是最早使用这个词的人。那时候《阿凡达》和《核心》都还没问世。看了你提供的维基链接，这个词完美契合“无摩擦、无质量滑轮”的定义。

              有趣的是，我平时总爱在闲聊中引用电影梗，但这次用词显然是个例外。

              回复

          2. 《阿凡达》对这个古老术语的误用堪称经典——它本指“已绝迹之物”。

            回复

          3. “不可得金属”在《阿凡达》之前就已是虚构作品中的常见元素。

            回复

        3. “美洲”之名源于某位作家笔下的“新世界”。有时人们错误地将“美洲”仅指代其中某个州而非整个大陆。

          爱因斯坦这个名字对我毫无启发，不像穆勒(miller)和施密德(Schmiede=锻造)那样直观

          回复

      5. 没有化学家会突然决定把新元素命名为“史蒂夫”，只因觉得这个名字有趣就能让论文更平易近人。

        镅元素已加入讨论。

        回复

        2. 题外话：加州利弗莫尔这座以葡萄园和奥特莱斯闻名的沉寂小镇，竟能在元素周期表中永垂不朽，而非纽约或芝加哥这类大都市，总让我忍俊不禁。

          芝加哥甚至拥有世界首座核反应堆，却未能入选。

          回复

          1. 瑞典伊特比镇仅有6000居民，本属无足轻重之地，却有四种元素以它命名：钇、铽、镱和铒。

            回复

      6. 你举的例子大多是软件！

        而且SHAKE和RATTLE描述的是算法中的运动模拟。

        首字母缩写词是具有实际含义名称的缩写。

        回复

        1. > 你列举的大多是软件名称！

          我的例子主要来自计算化学领域——这确实涉及软件，但(从历史角度看)是由化学家编写的。

          作为该领域从业者(至少在我当前工作之前)，我认为自己有资格评论本领域是否总是严肃命名事物。

          但若你留意观察，会发现趣味术语在化学及相关领域比比皆是。例如PALM和STORM(源自荧光显微镜技术)的命名，几乎可以肯定是因为它们易于记忆。

          > 此外SHAKE和RATTLE描述了算法中的运动模拟。

          并非如此。SHAKE和RATTLE是键约束算法，用于避免模拟溶剂中快速自由度的运动。

          在分子动力学中，时间步长实质由最快自由度决定(此处涉及奈奎斯特定理)，因此模拟大型体系时冻结水分子O-H键振动颇具价值。SHAKE和RATTLE能在保持一定松弛度的同时，有效冻结键长与键角在平衡附近的距离。

          其余自由度通常采用适合模拟体系的方法(如Verlet积分器、朗之万积分器等)以较大时间步长进行积分。

          > 缩略语是具有实际含义名称的简写。

          诸如XPS、EPR、NMR等缩写正是如此：简洁、干练且富有内涵。

          但许多缩写实则源于命名者的趣味偏好或便于记忆的考量。即便在技术领域，营销策略同样至关重要。

          回复

        2. > 缩写词是具有实际含义名称的简写形式。

          我认为常会添加词汇以形成易记名称，例如crispr

          > 当莫希卡与詹森展开通信时，他们开始为这些模式构思朗朗上口的名称，最终在2001年11月21日确定为CRISPR——即成簇规律间隔短回文重复序列的缩写。

          https://nautil.us/the-unbearable-weirdness-of-crispr-236685/

          回复

    3. > 没有化学家会突然决定把某种物质命名为“史蒂夫”，因为史蒂夫是个好笑的名字，他们觉得这样能让论文更平易近人。

      但气象学家可能会这么做：

      https://en.wikipedia.org/wiki/STEVE

      回复

    4. 你如此简洁地指出逻辑矛盾之处，做得很好。那篇文章不过是又一个“为解决虚构问题而生”的案例。

      回复

    5. 我认为作者刻意区分了消费品与基础设施/工程产品。谢尔比眼镜蛇跑车名字虽怪，但其引擎却是令人难忘的V8。胡佛水坝就是水坝，金门大桥就是桥梁。

      关于命名空间污染和过长名称的争议可以展开讨论，但作者的观点确实有道理。观察其他行业的术语时，我从未感受到像程序员那样“捕捉宝可梦”的狂热。

      当然拉丁语和希腊语命名的术语除外，但旧习难改，这些命名也未必以通俗易懂为荣。

      回复

      1. 作者还忽略了元素、物种和天体命名方式——它们往往取自随机地名、人名、游戏角色、虚构人物等。

        名称终究只是名称。若能保持独特性且避免冲突固然理想。

        回复

      2. >作者似乎刻意区分消费级产品与基础设施/工程类产品。

        考虑到他还在讨论emacs，这区分方式实在耐人寻味。

        回复

      3. >胡佛水坝是水坝，金门大桥是桥梁。

        作者完全可以使用“Libsodium加密库”和“Zephyr实时操作系统”。

        回复

      4. >但其引擎是那个令人难忘的V8。

        你记错了。是“温莎V8”。更准确地说，是“4.8升温莎福特V8”。

        回复

        1. 谢谢，我对汽车不精通。我查了维基百科，显然连该查哪里都搞不清楚。

          回复

          1. 没错，V8指的是发动机结构——八个气缸呈两排排列，以锐角错开(即V形)。同理，V6虽与直列6缸缸数相同，但性能差异显著。发动机结构种类繁多——我尤其钟爱早期飞机使用的转子发动机。传统上发动机命名仅包含年份、制造商和排量(如1965年福特352)。若上下文无需说明，常省略年份甚至制造商。

            福特351发动机较为特殊，因同期福特曾生产两款排量相同的发动机，故在型号后附加生产城市(温莎或克利夫兰)。

            回复

    7. > 但现实世界中，你可能遇到谢尔比眼镜蛇跑车、贝尔AH-1眼镜蛇直升机、USS眼镜蛇号巡逻艇(SP-626)、柯尔特眼镜蛇手枪等。

      在这个例子中，你添加了“直升机”、“巡逻艇”和“手枪”来消除歧义。否则上下文不足以实现区分，我认为这更符合作者的观点。

      若你正与熟悉多种机型的专家讨论直升机，仅说“眼镜蛇”或许足够。但在软件领域，大量晦涩的新工具若无上下文便难以辨识。而上下文恰恰总是涵盖所有相关事物。一个俏皮的名字可能指代任何相关事物。

      > 当文章里所有例子都与作者观点不符时，这本身就是个坏征兆。

      我觉得你只是因为不同意才刻意挑刺。更好的例子是：

      > “我们用Viper做配置管理，数据输入Cobra实现命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有操作都通过Asynq进行任务队列处理。”

      若真要挑剔，你的评论里也有：

      > 当你打开药柜时

      你用了“药柜”这个词，它不仅描述准确，更没有品牌化或术语化。这是标准表述，无需创新。这种常用表达不该被某人过度自恋地用自创词取代。你没有称其为Wapsooie(对WPSU的“俏皮”变体)、MMC(药材柜)，或是其他各种可爱的名字，甚至缩写——若整天讨论药柜设计或制造，你终究会用上这些。

      我基本赞同作者观点。软件工具总自以为妙趣横生。比如Virgil编译器内部命名为“埃涅阿斯”，可命令行界面却叫“v3c”——Virgil III编译器。

      回复

      1. 我的评论多半是讽刺，但我认为作者对自己偏见和错误毫无察觉。他们甚至说：

        > 我研读过大量软件史料，虽不能断言存在过命名辉煌的时代(即便是资深工程师也曾犯过荒唐命名)，但至少80年代存在过某种命名规范的尝试：grep(全局正则表达式打印)、awk(Aho、Weinberger、Kernighan； 开发者姓名首字母缩写)、sed(流编辑器)、cat(连接)、diff(差异)。

        “diff”确实是个好名字。但“awk”这个名称完全无法传达工具功能的实质意义，“grep”在知道缩写含义前更是完全晦涩难懂——名称本身毫无信息量。“cat”更具误导性——它确实是个单词，但工具与猫科动物毫无关联。

        作者仅因熟悉这些名称而偏爱它们，并非因其命名优秀。

        > 你使用“药柜”一词，该术语不仅描述准确，且非品牌专属或行话。这是标准表述，无需另创词汇。

        当然。那是因为我家里只有一个药柜。

        如果我上homedepot.com搜索药柜，醒目显示的都是“冰川湾”、‘顶峰’、“科勒”这类品牌名。

        这篇文章令人沮丧之处在于，作者甚至没意识到为何软件包要取这些古怪的名字。假设我想开发一个解析命令行参数的JavaScript包。显然“argparse”是绝佳命名——已被占用。试“cliparse”？已占用。“args”、“cli”、“options”、‘argparser’、“cli_argparser”？全被占用了。

        软件包需要唯一名称，以便包管理器和导入操作能明确识别。虽然可用作者姓名命名命名空间，但当两人同时提及“args”时，其中一人指的是“@some_rando/args”而另一人指的是“@weird_startup/args”，这种情况反而更容易造成混淆。

        所以人们干脆取些可爱的名字。名称是标识符而非描述符。

        这其实没什么问题，作者只是在发牢骚。

        回复

    8. 军事代号则不同：它们是刻意随机生成的词汇，旨在防止他人通过名称推测项目性质。

      (企业有时也会对内部项目采用这种做法。)

      回复

  4. 我强烈认同以下反驳观点：

    https://medium.com/better-programming/software-component-nam…

    简要总结：外部标识符难以变更，因此项目随时间演进后往往无法准确描述其功能。

    (该文未深入探讨：在复杂或去中心化的生态系统中，常会同时出现大量“X管理器”/“X服务”/‘X状态管理器’/“X工作流服务”等命名，此时必须依赖大量上下文才能区分它们)

    回复

    1. 我在多个岗位上多次被评价擅长命名，尤其钟爱奇思妙想的名称。我内化的几条准则包括：

      – 若命名困难，往往表明该事物尚未清晰界定使用场景或职责范围

      – 最理想的命名效果是初次接触时显得古怪奇特，当他人解释名称的含义/背景故事时，便会揭示更深层的意义/历史，令人过目难忘且牢牢铭刻于心

      – 我遇见过最棒的技术命名(并非我首创)是Spotify的A/B测试团队将自己命名为“ABBA”

      回复

      1. > 多份工作中都有人称赞我擅长命名，尤其钟爱奇思妙想的名称。

        前提是为产品功能命名，而非变量命名。

        回复

        1. 没错，变量命名最好专攻晦涩的Unicode字符。

          回复

    2. 天啊这篇文章比原帖强一万倍。这段太棒了：

      > 名称不应描述你当下认为该事物的作用。试想给新生儿取名“医生”或“养老伴侣”。可怜的孩子。

      回复

    3. 我完全赞同，还要补充奇思妙想的命名还有助于发现性。如果你的项目叫plugin-update-checker，而我想查找相关文档，很可能被淹没在大量无关的插件更新检查器搜索结果里。但如果它叫SocketToMe，我就能获得更精准的搜索结果。

      回复

    4. 这取决于你的目标，但这种范围限制有时反而是好事。

      专注一件事，做好它，同时用你所做的事来称呼自己，这样你就会记得这正是你该做的事。对Unix来说有点啰嗦，但你明白意思。

      回复

  5. > 在其他技术领域，这几乎等同于职业自杀。

    认知负荷不可避免，而在那些充斥着高度技术化名称的行业里，这种负担甚至更为沉重。

    职业生涯中，我曾任职于某大型汽车制造商担任发动机调校工程师。我们的术语库包含物理行业术语(BMEP、BTDC、VVT等)，一套庞大的软件包里每个变量、表格和函数都是缩写(约7.5万个可调参数，每个都有专属缩写)，还有大型企业常见的内部行话与缩略语。但每个名称都尽显技术性和功能性。

    入职首月我精疲力竭。午后会议时常打盹，车进车道便昏睡在车里。向资深同事倾诉后，他洞见道：我的大脑正加班加点学习另一门语言。他完全说对了！持续的精神负荷是真实可感的重担。他分享过蜜月南美之旅的轶事：尽管夫妻俩都学过四年高中/大学西班牙语，但日常交流所需的脑力消耗，导致他们因疲惫取消了半数行程安排——这正是我当时的状态。

    所谓“更技术化、更具体化的名称能减轻精神负担”的说法，与我的经历完全不符。复杂性是本质而非偶然，我认为这与具体名称选择关系不大。

    回复

    1. 在移动通信领域，新人入职时首先被告诫的是：“别费心去揣摩所有缩写词的含义，那毫无帮助”。你只能吞下这碗字母汤。更糟的是它们还会相互嵌套。有些缩写里每个字母都代表另一个缩写。写千字文不用一个名词易如反掌。当然所有短词都含义多重。AP是应用处理器还是接入点？取决于对话者来自哪个子领域。

      但它们是必要的恶，毕竟MSISDN比“移动台国际用户号码”更简洁。

      回复

    2. 我认为这完美诠释了“某些事物天生难以在大脑中建模”：

      https://www.youtube.com/watch?v=6ZwWG1nK2fY

      研究发现，参加伦敦著名出租车资格考试的人群大脑存在结构差异。

      记得看过视频提到，备考“知识考试”的人普遍反映极度疲惫。

      回复

    3. 这篇文章的批评(我理解的)更在于额外认知负荷：那些迫使你频繁切换认知模式才能辨别事物类别的命名方式

      回复

  6. > “但好记的名字有助于营销啊！”

    > 没错，如果你在开发消费级产品。但你的HTTP客户端、命令行工具辅助程序、任何库都不是消费级产品。真正关心这些工具的人只想知道它们的功能。

    ——

    听起来作者并未将自己视为这种关系中的消费者，认为自己不受营销影响，且其主张并非又一种营销手段。我不确定这些观点是否成立。

    我观察到采用功能性命名法描述事物的领域，最终往往陷入缩写词的海洋(功能性名称实在太拗口！)，反而陷入更糟的境地(你说的是ABDC还是ADBC？这两者完全不同)。

    回复

    1. 深表认同。我曾任职于反对“可爱化命名”的机构，结果常陷入CoreMainHttp与MainHttpCore这类命名抉择困境。更糟的是，两个完全同名的组件却拥有不同API，项目有时甚至同时依赖两者。甚至还有将组织架构中早已废弃的部分硬编码进依赖名称的情况，比如“DataOrgUtils”——这个“数据组织”早在数次重组前就消失了，那时现任副总裁还是实习生，其他员工甚至还没加入公司。

      然而若缺乏集中化的命名管控，即便是“可爱”的命名也终将趋同于少数几类：凤凰(及柏拉图洞穴等古典典故)、钥匙管理员/MCP(及80年代儿童电影梗)、辛普森角色、星际{迷航/大战}元素。这些名称都具有吸引力，能吸引那些倾向于从事IT/软件工程的人群——即便实际命名空间(所有可通过ASCII表达的词汇)远比这丰富得多。

      回复

    2. 确实如此——作者似乎认为这些工具在软件生态中是凭空诞生的，而非历经多年与其他平庸工具的竞争才得以存续。任何工具要达到如今的地位，都需要多年耕耘、运气加持，当然还有营销助力。而一个令人难忘的名字，绝对能决定一个工具是获得支持还是被遗忘。

      回复

  7. 有时我对Reddit首页的推荐内容感到困惑，这提醒我们：投票者与评论者之间的重叠度远低于预期。我理解人们追求更具描述性的名称，但一边举着“awk”这类例子，一边声称我们“偏离正轨”，这种说法至少是自相矛盾的。听起来更像是这位作者对可爱的名字怀有个人偏见，而非针对那些毫无描述意义的名字。在我看来，这篇帖子开篇的论述方式具有误导性。

    ——本评论由Firefox浏览器呈现，其名称显然表明这是一款网页浏览器。

    回复

    1. > 但一边举着“awk”这类名称的例子，一边声称我们“偏离正轨”，充其量只能说是自相矛盾

      我的观点是：即便像awk这样的名称，对当年使用该软件的人群而言也更具关联性。当然这并非最佳命名方式，但至少蕴含着某种意义。不同于现代软件，awk等工具开发时并未考虑广泛用户群体。至于是否“偏离正轨”，我认为确实如此——正如前文所述，80年代曾有批人坚持传统命名法，直至2010年代，这些名称即便经过文字游戏或与可爱名组合，仍保留着某种合理性。

      > 这更像是此人对可爱名称怀有个人偏见，而非针对名称毫无描述性的问题。

      并非如此，我认为这很有趣，只是不够专业。

      —

      通过msmtp(轻量级SMTP客户端，与Firefox不同，它不是消费类产品，其名称与功能相关)回复自动RSS邮件发送。

      回复

      1. > 我的观点是，即便像awk这样的命名对当年使用者也更具关联性——当然并非最佳命名方式，但至少蕴含实际意义。不同于现代软件，awk等工具开发时并未考虑广泛用户群体。至于是否“偏离正轨”，我认为确实如此。正如前文所述，80年代曾有批人坚持传统命名法，直至2010年代，即便采用文字游戏或搭配可爱名称，软件命名仍保留着某种理性逻辑。

        我个人不太理解。描述性名称的实用性我能认同，但像awk这样的名称，除非你恰好知道其含义，否则毫无用处——这在我看来有些荒谬。相关性？或许吧…但究竟有何意义？

        > 完全不是，我觉得很有趣，只是不够专业。

        你为何认为“不专业”？这似乎是文化差异问题。比如在日本，专业场合出现可爱插画并不罕见。我怀疑所谓专业性的标准根本不存在普世性。

        暂且不论这个，好吧：假设用无关事物命名软件确实不专业。那我们又该在乎什么？

        软件开发者至少过去几十年都在逆潮流而行。我们穿着卡其裤和T恤去白领办公室上班，笔记本电脑贴满贴纸。我并非说所有开发者都如此，但这确实构成了行业文化中相当显著的特征。

        在我看来，专业性是描述性的而非规定性的。若专业软件工程师惯用可爱的无意义名称命名事物，那么这就是我们行业的专业标准。

        我理解描述性名称的实用性，因其能实现特定目的。但那些仅凭某种关联性命名却毫无实际意义的名称，与无意义名称同样无用，而用“专业性”来区分二者显得颇为奇怪。

        > 通过msmtp(轻量级SMTP客户端，与Firefox不同，它并非消费类产品，其名称与功能直接相关)回复自动RSS邮件发送。

        请注意，这同样有力地反驳了使用描述性名称的观点。RSS？msmtp？如今我们正被各种缩写和首字母缩略词淹没。我并非特别反对这些名称(毕竟我自己就用msmtp，这个名字确实不困扰我)，但RSS这个名称的实用性相当有限，绝大多数人可能根本不知道它代表什么(据我记忆是“真正简单的聚合”，但这定义根本帮不了我理解它的实际用途)。

        但你确实触及了一个有趣的点，这或许能部分解释当前现象：即便对于小型命令行工具，开源程序员如今也常会费心进行软件的营销和部署。在我年轻时，开源生态仍较为分散，许多程序员只是定期发布tar包，而Linux发行版(及其他平台)负责将软件以可用形式交付给用户。打造完整产品的一部分，就是拥有令人难忘的名字。

        msmtp或许并非作为产品开发，但实际上几乎所有软件都“类似”产品。总有人是它的“消费者”(即使该人同时也是生产者)。人们会被它“吸引”。(即便软件是免费的。)推广方式固然取决于开发者理念与目标受众，但我认为几乎所有软件都存在某种形式的“营销”——即使是非商业项目，即使未打包成产品形态。(即便像GNU核心工具包的登陆页面这类事物，也堪称极简的营销手段)

        实际情况是：投入更多营销精力的软件往往更显专业。在我看来，“相关性”命名不过是表面功夫，而能精准触达目标用户群体的简洁营销话术，以及为用户提供优质资源的能力，才是真正体现专业水准的关键。同样地，许多产品化交付的软件确实拥有高度相关的命名！例如KeePass和SyncThing便立刻浮现脑海。

        因此，下一款卓越邮件服务器套件究竟命名为“SMTPMailSuite”还是“Stalwart”其实无关紧要，但我并不意外那些注重营销的开发者会选择令人难忘的名称。(显然Stalwart背后有公司支撑，优质营销对他们而言绝对是最佳选择。)

        描述性名称的另一弊端在于：软件会随时间演进，过于具体的名称终将失去关联性。虽然一时想不出具体案例，但此类演变现象在软件界屡见不鲜。(Linux桌面领域的一个例子是KWin：在Wayland过渡期间，它从X11窗口管理器演变为完整的显示服务器合成器；但这个名称显然依然适用。)

        回复

        1. 用你最喜欢的橄榄球运动员命名，功能性名称将在前三轮评审中被强制执行。

          回复

    2. 我认为核心论点并非针对奇思妙想的偏执

      回复

      1. 好吧，那么我的批评转向：文章应更清晰地阐述论点及其重要性。

        开篇是rms抱怨emacs生态中的命名不够描述性。理解。但作者(在评论中)辩称其论点并非反对非描述性命名，而是主张名称应当具有相关性，理由在于这更符合专业规范。

        我在此进行转述，或许未能准确理解论点，但这完全无法强化该主张。这反而引发了新的疑问：为什么？(况且我不确定rms本人是否认同这种观点，毕竟他出身黑客文化，似乎乐于打破社会常规。在我看来，rms并非传统意义上的“专业人士”——此处绝非贬义。)

        回复

  8. >“描述性名称太无趣了！”

    >>没错，外科器械也同样无趣。

    我敢断言此人从未清醒地踏足过手术室——因为所有器械都以人名命名。

    那些数以亿计的小钳子都带着荒诞的名字：Adson、Allis、Babcock、Kocher等等——除非你认得它们，否则这些名字毫无意义。当医生要Metzenbaum剪刀时，可别拿Mayo剪刀给他们。医学院时我们有套闪卡，一面是器械图片，另一面写着名称。

    说到底，作者观点虽有道理，阐述却不够到位。用awk作例实在牵强，diff才算恰当！

    回复

  9. 现代软件开发中存在一种奇怪的倾向：我们集体认定用随机名词、神话生物或虚构角色命名是某种可接受的专业惯例。这种做法在其他技术领域几乎等同于职业自杀。

    这句华丽的表述中缺乏真实性的特质令我着迷——至少对我而言是如此。

    回复

  10. > 我们的领域不该沦为伪装成专业术语的随机名词动物园。清晰并非乏味，而是对用户时间与认知资源的尊重。

    起初我有些愧疚——我维护的项目名为Wimsey(其实是数据测试库，但你绝对猜不到)，而团队在工作中也常沉迷于有趣/荒诞的命名。

    试图为自己辩护时，我构思了诸多反驳本文的逻辑：非描述性名称不会因项目目标偏移而失效；描述性名称会导致重复；诸如此类。

    但坦白说，我纯粹喜欢软件名称能传递一丝趣味感，哪怕微乎其微。

    日常使用的软件如Cron(源自希腊时间之神)、Python(取自喜剧团体名)和Zellij(源自马赛克工艺名)，这些充满趣味的名字都传递着开发者当初倾注的热爱与用心。

    反正我总要深入学习这些工具，而非仅停留在“X属于Y类工具”的认知层面，所以乐于记住这些名字。比起使用“unix-scheduler”、“面向对象脚本语言”或“终端显示管理器”这类名称，这让软件工程增添了几分趣味。

    我热爱这个充满匠人热忱的领域。严苛的专业主义，绝非我愿用热情交换之物。

    为心爱之物命名是人类的天性，这正是宠物通常叫“饼干”而非“棕色狗2号”的原因。

    回复

    1. 将库命名为“数据测试库”确实实用…直到出现第二个同名库，具体名称便彻底失去意义。

      回复

      1. 典型案例：@testing-library(React/Vue等框架的JS测试库)

        更何况这类过度泛化的命名会增加检索难度，对我而言比花哨名称更令人困扰。

        回复

        1. 它们还让讨论变得困难。当你在日常对话中提及“测试库”时，若没有@符号和连字符，人们无法分辨你指的是测试库的概念还是某个具体库。

          回复

          1. 前几天我试图告诉某人使用具体程序prettier，对方却以为我在谈论代码格式化工具的泛指概念

            回复

    2. 我总被.NET命名结构Project.Parser.Pcapng困住，它很适合项目命名，但对独立命名完全没用

      回复

    3. 有些人追求专业性，指的是精通且熟练地做事。可爱元素本质上会分散对工艺核心价值的注意力，因此显得格格不入。追求可爱元素的行为，往往暗示着创作者未能从工艺本身获得足够的愉悦感。换言之，这反映出对实际工作缺乏热忱与满足感，才需要额外添加“趣味”元素来弥补。

      回复

      1. 但这种观点显然站不住脚。完全可以两者兼得：既能专注专业地完成工作，又能在可能时保持轻松有趣。

        想想这个帖子里那些经典软件的搞笑名称，甚至楼主本身就是明证。

        回复

        1. 这其实是种低调的炫耀。看啊，我既是技术高手又能保持幽默感！

          回复

  11. 行吧兄弟，给我点时间，我得注射每周减肥针剂：L-组氨酰-2-甲基丙酰胺基-L-α-谷氨酰甘氨酰-L-苏氨酰-L-苯丙酰胺基-L-苏氨酰-L-丝酰胺基-L-α-天冬酰胺基-L-缬酰胺基-L-丝酰胺基-L-丝酰胺基 -L-酪氨酰-L-亮氨酰-L-α-谷氨酰甘氨酰-L-谷氨酰胺酰-L-丙酰酰-L-丙酰酰-N6-(N-(17-羧基-1-氧代十七烷基)-L-γ-谷氨酰-2-(2-(2-氨基乙氧基)乙氧基)乙酰基-2 -(2-(2-氨基乙氧基)乙氧基)乙酰基)-L-赖氨酰-L-α-谷氨酰胺酰-L-苯丙氨酰-L-异亮氨酰-L-丙氨酰-L-色氨酰-L-亮氨酰-L-缬氨酰-L-精氨酰甘氨酰-L-精氨酰甘氨酸

    回复

    1. 1 代表金钱 2 代表绿色 3,4-亚甲二氧甲基安非他明

      回复

  12. 描述性名称的问题在于，它们最初具有描述性，但后来却变成了专有名词。在我曾供职于某家非软件行业的《财富》100强企业时，所有事物最初都采用描述性名称，后来逐渐演变成首字母缩写。而随着每个项目和工具不可避免地发展出自身独特特性，这些描述性名称很快便无法再提供任何有用的项目信息。

    知道某物的名称，却对它的本质知之甚少，这是无可避免的现实。句子正是为此而生。

    回复

    1. 知道MySQL是数据库而非套筒扳手略有裨益，但更重要的是它是否支持枚举类型。

      回复

    2. 军方总爱起个酷炫名字，随即编造个首字母缩写词来解释其含义。

      回复

  13. 若社区遵循作者建议，我们将看到诸如“通用LLM封装器690”(若遵循早期编程语言惯例则为“GLW690”)或“理念不同的Github克隆版11”这类命名

    回复

    1. 完全不是。命名不应基于类别，而应基于功能或方法。PostgreSQL并非“通用SQL数据库47号”，而是Ingres的继任者(Post-Ingres-SQL)。若你的“LLM封装器”毫无特色可言，或许不该发布。但若它专门处理流式数据，就该命名为“llm-stream-client”；若专注提示词模板化，则可称作“prompt-template-engine”。名称应体现核心价值主张。

      我在帖子中已提及，但容我重申：只要命名与工具实际功能相关，采用趣味化命名完全可行(可通过玩转词尾实现，如Mongo“DB”、Open“SSL”、Ma“git”等优秀案例，远胜于“大象”‘狗’“海狸”这类命名)。

      回复

      1. > PostgreSQL并非“通用SQL数据库47号”，而是Ingres的继任者(Post-Ingres-SQL)。

        确实如此。这让我明确自己使用的数据库比Ingres更现代化。我选择不使用Oracle或SQL Server，正是因为它们可能早于Ingres诞生。

        但有个疑问：Ingres是什么？我为何要关心它？当然，我确实不必关心，这使得Postgres这个名称和“fluffnutz”或“hooxup”一样毫无意义。不过随着时间推移，我逐渐喜欢上了Postgres这个名字。

        回复

        1. 项目初期，名称有时具有重要价值。此例精准阐明了项目本质及其发展方向…但产品命名这类营销决策往往难以经受时间考验。

          回复

        2. 你无需了解Ingres是什么。“PostgreSQL”至少表明它与SQL相关，这比“fluffnutz”传递的信息要丰富得多。一旦知晓这是数据库，这个名称将永远强化你的认知。试想半年后还能记得“fluffnutz”的功能吗？

          回复

          1. 这真是绝妙的记忆法。真希望我生活在另一个宇宙里，Postgres被称为PostgreSQL以便更容易记住。或许我们开始使用这个名称后，它会像Go项目被称为Golang那样普及开来。

            回复

            1. 谷歌推出Go语言时，你根本无法用谷歌搜索相关资料。所以社区立刻改口称它为golang 😉

              (至少我记得是这样——当时就纳闷“明明知道会搜不到，为什么给语言起这种名字”)

              回复

              1. 我明白。

                我的意思是，几乎所有人都称它为Postgres，因为他们并不真正重视“PostgreSQL”的描述性。

                回复

                1. > 几乎所有人都称它为Postgres，因为他们并不真正重视“PostgreSQL”的描述性。

                  还有一个原因是最初的名称就是“Postgres”，采用POSTGRES的样式。

                  PostgreSQL是个糟糕的新词(好吧它确实存在多年了)，我真心以为他们已决定回归原始名称——显然更优雅的原始名称。:) 记得几年前讨论过此事，没想到最终没能实现。

                  回复

                2. 我一直以为是因为“postgres”比“PostgreSQL”更容易发音。

                  回复

      2. 没错，但市面上到底有多少LLM流式客户端？

        命名空间确实有必要。但“我们用gh:someguy/openai/llm-streaming-client对接后端”(架构讨论中类似冗长名称还有50个)真的比“我们采用Pegasus作为LLM流式客户端”更优吗？

        回复

        1. 没人会在对话中说“gh:someguy/openai/llm-streaming-client”。你会像说“Pegasus”那样自然地称其为“流式客户端”或“llm-stream”。但当新人加入或阅读代码时，“llm-stream”本身就是最佳注释。“Pegasus”则需要每次都查阅文档，直到你记住这套任意映射关系。

          回复

          1. 这简直糟透了，现在你看到文档或注释提到 llm-stream 却未标注完整命名空间时，根本无法分辨对方指的是50种 llm-stream 工具中的哪一种，更别说无法在线搜索相关信息了。

            回复

          2. > 你说“流式客户端”

            哪个项目？！GitHub上有七个同名热门项目，每个都超过10万颗星；你具体用的是哪个？

            回复

          3. 我向你保证，项目名绝非自文档化。至少在实质意义上绝非如此。

            这正是经典案例之一：已学知识总被视为“显而易见且直观”，而新事物却“晦涩难辨”。

            具体例子可以举一整天：cat、ls、grep等命令的含义众所周知难以理解；PowerShell试图用自解释名称命名所有功能，结果却令人难以记忆。“llm-stream”在脱离上下文时毫无意义，即便有上下文，“pegasus”同样令人费解。

            回复

      3. > PostgreSQL并非“通用SQL数据库47号”，而是Ingres的继任者(Post-Ingres-SQL)

        他们怎么会错过“IngresSequel”这个名字？

        回复

    2. 或许吧，我绝对更倾向这种做法而非随意拼凑通用词。Laravel里有个“illuminate”组件，但我记不清具体功能，只记得“这根本不是名词；他们只是为某个破子系统随便挑了个听起来悦耳的词”，这种做法更让我恼火。

      回复

  14. > 编程领域从企业大型机转向社区开发者 > 这很好

    但接着：

    > 我们的行业不该沦为伪装成专业术语的随机名词动物园

    好吧？那这到底算专业术语还是社区开发者的产物？

    我认为：编程理应普及，不该成为精英职业，无需迁就忙碌的专业人士——企业用户在工作中念我那蠢包名也无妨。

    > 你的玩乐会产生外部成本。每个接触你“有趣”名称的人都要付出微小代价。全行业累积起来，这些代价将形成巨大浪费

    谁给这家伙弄个水烟筒抽抽？

    回复

    1. 玩乐总有尽头，直到你不得不喊出“喷火龙删了我们的数据库备份”

      回复

      1. 要是他们用Coq就不会出这种事了！

        回复

  15. 非描述性命名未必错误或阻碍发展。作者提到科学领域，但STEM学科本身就充斥着非描述性名称：我们用“毕达哥拉斯定理”代替“直角三角形边长定理”，用“牛顿法”代替“迭代切线求根法”，用“λ演算”代替“抽象-应用求值法”。这些术语虽非随意，却让初学者毫无头绪。

    回复

    1. 啊，STEM命名法……数学领域尤甚。如何区分“集合”与“群”、“流形”与“范畴”？更令人困惑的是那些看似无关却都冠以“空间”之名的概念(它们本质上都是拓扑空间，但研究向量空间时可能尚未接触过拓扑学)。“域”在物理学和代数中是两个完全无关的概念，有时这两个领域甚至会发生交叉！线性规划与计算机编程毫无实际关联，“编程”一词原本意指“优化”。用发现者命名或许不够描述性，但给出既误导性又描述性，还存在概念冲突的名称更糟糕——然而从事相关工作的人们却能游刃有余。

      回复

  16. >http-request-validator远胜于“zephyr”

    当真如此？当GitHub上出现十种不同版本的http-request-validator仓库时，你如何区分？我认为两者各有弊端，但采用过度泛化的名称恐怕更糟。我讨厌zephyr这类名称的原因在于它们纯粹是营销驱动；人们最终选择zephyr而非http-request-validator，仅仅因为前者听起来“酷炫”，尽管后者可能是更优秀的库。至于那些用随机日语词命名项目的家伙… 这就像泰国人用的昵称——随便取些英文单词当名字，比如“冰淇淋”或“谢谢”。

    或许折中方案如你所说，取个能暗示功能的名称，比如Actix(演员模型)。但说实话，你还是得查资料才能明白它做什么，光看名字根本猜不到。不过或许后期能帮助回忆项目用途。

    回复

    1. > 别提那些给项目取随机日语词的人了

      但词汇本身能帮助我们学习。多少次你会发现童年某个词汇与成年后概念或地点的关联？这些词汇并非随意，人们选择时往往暗藏诸多缘由，真正随机的案例实属罕见。

      我们许多人都钟情于词汇背后的故事——正如这里众多评论所展现的，大家都在追溯工具名称背后的文化渊源。

      回复

  17. 现代软件开发中存在一种奇怪的倾向：我们集体认定用随机名词、神话生物或虚构角色命名是某种可接受的专业做法。这种做法在其他技术领域几乎等同于职业自杀。

    我在金融行业工作时，我们给模型取昵称以示亲近。最让我印象深刻的是同事给模型命名为“牛肉锤”。

    回复

  18. 我认为项目名称若能轻松被谷歌检索到，便是好名字。若日志里出现“通用工具名失败”的错误，却因搜索结果充斥无关信息而无法立即定位问题根源，那便是糟糕的命名。这种情况在描述性名称和可爱型名称中都可能发生。

    回复

  19. 确实，这有点相对论。用用微软近十年推出的工具/产品(尤其是云服务/Office套件)，你就知道其他命名模式有多好了。

    我个人认为工具命名应该充满异域风情、张扬独特且狂野不羁。把公司名(或旗舰产品名)当前缀塞进所有命名里只会让人困惑，最终害了自己。

    回复

  20. 有趣的是早期编程语言竟被视为拥有恰当名称。60年代我们经历了从BCPL到B再到C的演变。B和C完全不具描述性，难道不该命名为“操作系统语言”或“可移植Unix语言”吗？根据这些标准，AWK也算不上命名得当的工具——开发者姓名首字母缩写完全无法说明其功能本质。

    回复

  21. 我强烈反对这种观点：将提供webhook的服务命名为“webhooks”或“webhook-service”，在仓库列表中看似简洁美观，却给组织内所有人立即增加了认知负担——现在每次讨论时，必须区分“webhooks”作为特定服务的正式名称，与“webhooks”作为特定模式的名称。将这种情况放大到现代软件生态的各个组件，你就会把公司基础设施一点一点变成私有语言。更糟的是，这种私有语言会被外部人员和新人误以为自己理解，导致他们往往需要更长时间才能弄清实际服务是什么。

    回复

  22. 我曾亲身经历这种困境。早期在个人电脑上开发项目时，我总给每个项目取些奇思妙想的名字——通常是电视剧台词或歌词的双关梗。几个月后当我需要重启项目时，只能花五分钟翻阅那些晦涩的词组和残缺的句子，试图回忆当初创作时的奇思妙想。如今我只用三个月后最可能记住的词命名。虽然觉得这样会失去些许创意和色彩，但或许哪天我会设计个标签/影子标题系统，这样就不需要直接描述性的名称了。

    回复

  23. > “我们用Viper做配置管理，数据流向Cobra实现命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有任务队列都通过Asynq处理。”

    但在这些傻名字出现前，每家公司都用专属的三字母缩写称呼工具，其实也好不到哪去。虽然名称本身描述性强，但仅用缩写同样无济于事，还需全公司共享词典。比如“我们用CMT2做配置管理，通过CCM提供命令行界面，再由WSM处理WebSocket连接，PM管理权限，所有任务队列都通过AJQ处理”。

    回复

  24. 那辉煌的一天，当我向老板解释维基是什么并建议内部建立时，他直接把“viki”扔进谷歌搜索，凭着娴熟的肌肉记忆点开首条结果…结果满屏都是色情内容。

    回复

    1. 至少你没遇到那种撞墙的经历——试图集成名为Testacular的测试库时，简直像在撞墙。

      回复

      1. 大学时我们有个分析示波器数据的老程序叫ANAL。

        回复

        1. 我研究生读过分析组合学，必须小心别缩写成“anal comb”。

          回复

        2. 学校里我们把语法分析模块叫“analsyn”。好时光啊。

          回复

      1. 有个叫upskirt的Markdown库，作者被迫改名。他们改成Misaka——因为这是个在裙子下穿短裤的动漫角色。

        回复

    3. 几年前我曾要求某机构安装LaTeX。谷歌搜索结果令人大开眼界。

      回复

      1. 90年代我在教LaTeX课程时，有个学生穿着印着“我痴迷于乳胶”的T恤。

        回复

        1. 说实话，我实在分不清哪种解读更令人不安。

          回复

    4. 第一个搜索结果是什么？我看到的是乐天Viki——一个专注亚洲剧集的流媒体平台，和你说的不太一样。

      回复

      1. 那是2000年代的事了。谷歌后来被严格限制为安全搜索环境。

        回复

    1. 通过Krazam发布的视频，你真能追踪到他的职业发展轨迹

      回复

    2. 你永远无法理解银河吞噬者的痛苦

      回复

  26. 如果你还不清楚，你觉得名为“emacs”的工具能做什么？

    回复

    1. 根据这些年看到的新闻标题，我觉得emacs用户除了知道它能说“yes”之外，根本不清楚它到底做什么

      回复

    2. 或许是当年那台Geekbench测试机。在远古时代它被传说般地称为“八兆内存持续交换”。不过现在看来这性能差距怕是要扩大几个数量级了。

      回复

    3. 这仍印证了他的观点：

      > 即便工程师发挥创意，命名也遵循逻辑：蝶形阀的外形确实酷似蝴蝶翅膀。你能看出名称与实际定义的关联性，以及这种命名如何令人过目不忘。

      Editor MACroS(编辑器宏)同样存在逻辑，并非随意堆砌。

      回复

      1. 蝶形阀属于特定类别。对应Emacs的词应是“编辑器”——这完全是描述性命名：编辑器用于编辑。

        随机从网络搜索中挑选一款特定蝶形阀，我发现名为FNW FNWHPA1LSTG24的产品。

        产品类型和类别通常采用通用名称，具体产品却常有怪异命名。几乎所有领域都如此。

        回复

        1. 总有人最先将自己的阀门称为蝶形阀。

          Emacs同样可视为编辑器类别。存在多种基于emacs衍生出的编辑器。

          回复

    4. 看到这个词我仍会想起短命的产品Apple eMac。

      回复

      1. 同感！学生时代用过eMac，非常喜欢，那是我第一次接触到“emac”这个字符组合。

        回复

      2. 有趣的是他们居然把这种产品卖到2006年，还配着CRT显示器

        回复

        1. 因为RDF技术最初就是基于CRT开发的，他们不得不这么做。

          回复

          1. eMac中的RDF指什么？我查了资料，结果全是“资源描述框架”或“现实扭曲力场”。

            回复

      1. “Emacs让任何电脑变慢”——这句老梗我也记得。

        回复

      1. “通过邮件操作Mac OS”这个想法突然闪现。完全不明白这怎么实现。

        回复

    8. 如果你不知道，你觉得叫“Combine”的工具是做什么的？

      合并东西？错。它的目的恰恰是分离事物…

      这不仅限于软件行业。

      回复

      1. 更关键的是，约翰迪尔S7 600、310 G-Tier或Z515E ZTrak各自做什么？Emacs是编辑器——这部分恰恰说明了功能：编辑器用于编辑。产品名称本就不该描述产品本质，产品类别名称才承担这个功能。

        回复

        1. > 产品名称本就不该描述产品本质。

          虽有例外，但农机行业在命名实用性方面已相当成熟，各品牌间保持合理一致性。以S7 600为例：600表明这是6级联合收割机，该数值代表收割机容量，是农民理解的价值指标。以拖拉机为例，约翰迪尔8R 230中的8代表大型行作物框架，230则表示230马力发动机。纽荷兰T7.180同样遵循此逻辑——中型行作物框架搭配180马力发动机。

          对局外人而言这些数字或许毫无意义，但一旦掌握解读方法，其中便蕴含着大量实用信息。

          回复

          1. 若已掌握基础知识则颇具价值。我的观点是：若对产品毫无了解，仅凭“S7 600”本身无法传递任何信息。其作为联合收割机的属性属于独立认知范畴。同理，若不了解“emacs”，该词本身毫无意义，但通用术语“编辑器”则具有描述性。

            软件通常不会像230代表230马力那样将产品属性编码到名称中，因为软件本身就不具备这类可用于命名的属性。大多数软件没有此类特定型号，而存在型号区分的软件也几乎总是通过功能集而非数字来区分。

            回复

            1. 软件常在名称中标注版本号。这与上述联合收割机的S7型号命名逻辑相同——S7只是重新设计的S7x0系列收割机，该系列是S6x0系列的后续产品。

              这并非完美体系。在S6x0之前是9x70STS系列，之后是9x60STS系列和9x50STS系列。其中虽存在版本号，但并非完全递增。不过这种情况并不新鲜：Windows从3.1升级到3.11、95、98；iOS从17升级到26。你懂的。

              回复

      2. 据我所知，严格来说它属于“联合收割机”，这个称呼更符合直觉。不过实际使用中大家都简称为“联合收割机”。

        回复

        1. 严格来说确实是“联合收割机”。最初它被称为“联合收割脱粒机”，这或许就是你想到的名称，但很快就被简化为“联合收割机”并沿用至今。

          后来某些需要上下文解释“联合收割机”含义的场合才出现“联合收割机”的表述，但似乎仅限于此类语境。“联合收割脱粒机”实属多余冗余。

          回复

      3. 我感到矛盾，因为你并非完全错误(它并非仅存在于软件行业)，但这个名称的由来正是因为联合收割机整合了曾经独立的工序。

        其实这个命名并不糟糕。

        回复

        1. > 我很纠结

          正因如此我才特意选这个例子！若你无需思考，还有什么趣味可言？

          回复

    9. > 若你尚未知晓，猜猜名为“emacs”的工具能做什么？

      嗯，这看似无意义的词汇，但有时单词倒写后确实像无意义字——或许是“scame”？

      回复

  27. 我宁可死在那个谚语的小山丘上也要坚持：最糟糕的案例永远是GIMP，它本可以在多年前就吃掉Adobe的午餐。

    它曾经是、或许至今仍是Photoshop的强劲对手，但任何不熟悉它的成年人，完全有理由永远永远永远不会信任这种名字的软件来处理重要工作。

    回复

    1. 我接触GIMP比Photoshop更早。我的体验恰恰相反。这说明两者界面不同，但客观上没有优劣之分，关键在于你的预期——而预期取决于你先接触的软件。

      至于CMYK支持：设计师为何需要这个？诚然，不同RGB标准存在差异，sRGB成为行业标准也历经漫长过程，但CMYK同样如此——每台打印机都有专属配置文件。我曾有过糟糕的经历：某家只接受CMYK文件的“专业”印刷公司，竟连自家打印机的配置文件都不清楚。理想做法是发送包含屏幕显示配置文件的RGB文件，由印刷厂自行转换为所需CMYK模式。

      当然印刷时可能需要RGB/CMYK之外的特殊颜色或效果，那又是另一回事了。

      回复

    2. GIMP的用户体验糟糕透顶，根本不可能取代Adobe的任何产品。开源软件界向来存在这样的传统：坚持宣称“我们不是X，我们与X不同”。

      使用我们应用时感到的不适、挫败和反直觉？那纯粹是你的问题！

      不，这绝非设计缺陷或用户体验问题！纯粹因为我们与众不同！我们不是X(Photoshop)，我们只是采用不同方式做事！"

      GIMP正是这种理念的典型代表。

      回复

      1. 值得一提的是，我们正积极鼓励设计师和用户提供更多反馈以优化GIMP。我们设有专门讨论用户体验/界面的公开仓库：https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues

        在达成共识后，我们已将问题帖中的多项建议付诸实施，期待更多人参与其中，共同推动GIMP的进步。

        回复

      2. 能否举例说明近期GIMP版本中存在哪些糟糕的用户体验设计？这些问题是否仅因“缺乏改进时间”(毕竟仍是志愿者主导项目)所致？

        我认为GIMP永远无法进入专业领域，因为其内部架构过度依赖单一色彩模型(RGB)。

        许多专业领域使用的工具都存在极差的UI/UX设计。

        回复

    3. 我同意GIMP这个名字很糟糕，但它真的能成为Photoshop的“强劲”竞争对手吗？我的印象是它在功能上从未接近过竞争水平。不过我两者都只简单用过，可能完全搞错了。

      回复

      1. 据我所知，要让Gimp支持专业图像编辑所需的非RGB色彩空间成本过高。

        我时不时会用它，它对我来说表现出色，大部分用户体验清晰直观(只是缺少高DPI支持)。不过自从90年代(或者说被Adobe收购前的Aldus PhotoStyler)之后我就没再用过Photoshop了。

        回复

      2. 我认为它本可以成为——换言之，更早采用更佳命名或许能吸引更多贡献者等等。网络效应之类的因素。

        回复

    4. > 这或许早在多年前就能撼动Adobe的地位。

      那个“或许”在句中承担了太多推测。GIMP至今从未成为Adobe专业产品的真正对手，若仅凭更佳命名就能登顶之说实属可笑。

      回复

      1. 小心点。语言警察已经废除了“master”这个词。他们曾觊觎GIMP准备接管或改名，但估计没推进多少。或许他们把精力都耗在从Git里清除奴隶制痕迹上了。

        回复

        1. 抱歉，我必须在此强调“触碰草坪”。

          这无关“我个人是否受冒犯”。

          这是专业性问题。存在权衡取舍。我理解移除“master”等术语的双面性，但GIMP早已超越这个层面。即便你辩称它不具冒犯性，这个名称本身仍强烈暗示“这玩意儿肯定不靠谱”。

          回复

      2. 若我必须“等待了解”，那岂非本末倒置？

        回复

  28. "看过新剧吗？它在Tubu播。确实在Heebee播。Poodee有广告版。Dippy也有播。你大概能在Weeno找到。哥们它在Gumpy。这是Pheebo原创。它在Poob。你可以在Poob看。去Poob就能看。马上登录Poob。去Poob。潜入Poob。你可以Poob它。它在Poob。Poob为你准备好了。Poob为你准备好了。"

    — <https://knowyourmeme.com/memes/poob-has-it-for-you>

    回复

  29. 我认为作者混淆了品牌命名与其他几类概念的区别，比如技术术语及其通用名称。

    活动扳手本身命名直白，但多数英语使用者称其为猴扳手。某些欧洲语言将其译为“法国扳手”或“法国人扳手”(意指法国人)，另一些语言则称作“英国扳手”——尽管这两者最初都只是活动扳手的变体。

    关键在于，这些古怪名称本质上是品牌标识——它们可能持久流传也可能昙花一现，而描述其功能的术语则更具说明性。

    我最喜欢的例子是BlueJeans视频会议平台。为何如此命名？真相或许永不可知，但很可能是为了突出差异。不过品牌名与功能描述术语之间存在明确界限。

    技术软件命名的问题在于：要么冗长无意义，要么在底层工具迭代时死不了(说你呢Angular)，更糟的是，重要到不该浪费在低质量项目上(说你呢React Router)。

    我们公司有个工具，技术名称长达四个单词，认知负荷堪比任何技术术语。

    我对该项目最大的贡献就是为它命名。我赋予它一个与技术或软件毫无关联的简洁名称。

    于是项目经理、主管和用户们突然都能正确发音、准确输入，当然也能毫无差错地记住它。

    因此至少根据我的经验，拥有简短易读的名称比技术性名称更重要。

    当然，兼具所有特质的名称固然理想，但世上项目众多，完美名称本就稀缺。许多绝佳名称(比如Vue.js)要么已被占用，要么超出我的命名能力范围。

    回复

  30. 遗憾的是，本文忽略了命名中最严重的缺陷：名称冲突。

    回复

    1. 确实，若遵循此建议，每门语言都会出现四个同名http-client包。

      回复

      1. 诚然，但需指出以元素或工艺命名的做法(如Sodium)在特定场景下会导致命名缺乏独特性。例如在涉及该元素或工艺的实验室工作时，可能引发同事间的混淆。

        回复

  31. > 下次你想用最爱的动漫角色命名项目时，请先停下来自问：“土木工程师会这样命名桥梁支撑系统吗？”若答案是否定的，请另择更佳名称。

    我正在用shell开发一个将点文件传输到远程SSH会话的工具。最初想命名为“sship”，但该名称已被占用。类似“ssh-dotfiles-carrier”的名称作为命令行太冗长，而缩写为“sdc”又会丧失原意。

    所以最终， 最终命名为“shitt-p”(《杀手再临》角色名！)，因为我想与“sh”建立关联…

    回复

  32. 坦白说，作者提到的awk作为命名并不理想。它只是作者姓名的首字母缩写，完全无法体现工具功能，反而增加了认知负担。

    更进一步说，Linux等系统中极度缩短的名称同样存在问题——毕竟如今多数终端都支持Tab键补全功能。

    回复

  33. 我曾任职的Canva在这方面做得相当出色，我正将这种理念带入现任职公司的文化中。

    Krazam对程序员这种不严肃的命名癖好进行了精彩的戏仿[1]：“瞧，宾果记得每个人的名字-O。所以我们直接从那里获取用户ID。”浣熊、副驾驶、EKS(熵混沌服务)、RGS、芭比娃娃、Ringo-2。

    1. https://youtu.be/y8OnoxKotPQ?si=QkI-TPStI9I4RtAB&t=33

    回复

  34. 描述性名称固然出色，但当你构建的事物开始演变，其功能超出或不足于描述时，就会比使用通用名称更令人困惑——比如我最爱的“顺从海狸”。团队命名亦然。神话生物名称既有趣又能让团队随使命与职责演变，还可能缓解康威定律的影响。

    回复

  35. 为何Go是愚蠢的名字，而Python、C、Rust等编程语言名称却不是？

    回复

  36. 文章提到2010年前一切正常，之后开发者集体疯了。2010年究竟有何特殊？

    那时万物都需要网站域名，而所有域名都被域名抢注者囤积殆尽。同时人们为SEO和营销热衷创造新词，追求极致简短的音节。

    回复

  37. 不得不佩服“wget”这个名字——为从网络抓取内容的程序取名实在精妙。

    回复

  38. >> 早期编程语言遵循类似逻辑：FORTRAN(公式翻译)、COBOL(通用商业导向语言)、BASIC(初学者通用符号指令代码)、SQL(结构化查询语言)，据我所知Lisp代表列表处理。模式很明确：名称传达功能或渊源。

    “名称传达功能或渊源”：并非如此。若用作者举例的对话场景：对从未接触过BASIC的人来说，说“BASIC”而非“Cobra”根本无法更清晰地说明含义。

    我编程十五年有余，因年龄原因从未接触过BASIC，直到今天才知道它代表“初学者通用符号指令代码”。

    为什么？因为我无需知道，这并不影响BASIC的使用。

    回复

    1. 刺猬索尼克在此案例中是个糟糕的例子。研究人员不得不向家长解释孩子携带的是“刺猬索尼克基因”突变。科学界早已意识到这个问题，这已成为广为人知的争议案例，在医学伦理讨论中常被列为命名失败的典型。

      “大卫·阿滕伯勒号”？官员们否决了投票结果，坚持以大卫·阿滕伯勒命名。实际服役的科研潜艇反而保留了这个玩笑名称。这再次印证了我的观点。

      “胖加里”本是内部芯片代号，本无需公开。完全合理。

      若效率不是问题，“命名仅为区分标识”的论调便站不住脚。既然成本相同，为何要使用更差的标识？

      回复

  40. 我们都该向Haskell社区学习。与其为列表函数随意取名“append”，不如借助对单元的深刻直觉，采用更直观的“<>”。

    回复

  41. 对奇思妙想的热爱确实是原因之一，我并不否认。但更深层的原因在于，经过一两代人的发展，许多直白名称已被占用。

    (此外，我认为awk甚至grep并非好例子——正如原帖所承认的，它们显然是出于奇思妙想而命名，即便不是真正的回溯缩写词，也属于为奇思妙想设计的缩写词)。

    还有一个原因是，如今许多人怀揣着将产品商业化的梦想，因此需要一个“品牌”名称。(我敢保证，那些工具的命名者当初根本没打算将grep或awk商业化)。(对此我虽不甚认同，但这就是现实)。

    我认同楼主所言，这确实影响了可访问性。尚未熟记这群奇异名称的新手需要费心理解；不同人的大脑运作方式不同，有些人天生更容易记住这些任意命名的术语，有些人则不然；我猜对非英语母语者来说尤其困难，不过对他们而言这些名称可能本就是天书(哈哈！)。

    不过当我尝试用简单名称命名时，也常遇到困难——既要清晰易懂，又要相对简短(尤其当它将出现在命名空间或其他标识符中需要频繁输入时)，同时还要避开大众认知中已有的名称或所需包管理器的命名冲突等等，往往很难找到合适的！

    回复

  42. 归根结底，要么你懂其含义，要么不懂。我认同描述性名称确实有益，但不可避免的是，你终究得学习那些不显而易见的术语。纯粹功利性的命名只会不断引发冲突。

    我认为他们还高估了其他领域术语的独特性。就拿他们举例的工字梁来说，根据对话对象不同，它也被称为H型梁或RSJ梁。我完全能想象机械师用制造商名称来称呼专业工具的情景。

    无论如何，这场战役开打前就已注定失败。计算机领域从未建立过良好的描述性命名规范，根本谈不上什么失败阴谋。

    回复

  43. 这已成为Elm包命名的铁律。命名模式如elm-csv、elm-json-decode-pipeline、elm-iso8601-date-strings。社区强烈倾向于用功能精确命名包，必要时通过作者命名空间区分——例如核心库coreygirard/elm-nonempty-list、mgold/elm-nonempty-list和v-nys/elm-nonempty-list可根据需求选择。

    记得在 Ruby 项目中遇到环境配置工具问题时，反复遭遇“无法找到 nokogiri”(或类似错误)，看着这个毫无描述性的可爱名字却始终无法运行网站，当时真是气不打一处来。

    —

    诚然，我列举的所有包名都暗含专业知识：JSON代表什么？CSV又代表什么？ISO是什么？8601又是什么？我想设计初衷是描述性止步于语言边界——包名字段太短，无法解释JavaScript对象表示法、逗号分隔值，或是国际标准化组织(其实“isos”源自“相同”的日期格式)。

    回复

    1. 你提到Ruby真是太好了，它完全颠覆了你对elm的评价。每个该死的gem都带着蠢萌的傻名。这大概就是企业界所有成熟Rails项目都直接依赖五六个不同HTTP客户端封装库的原因之一。新手开发者翻开Gemfile，发现没有“http”相关的模块，就会去谷歌搜索“ruby gem http client”。由于这类库种类繁多，最终开发者往往会把所有相关库都加进去。

      我期待人工智能能改变这种状况——AI代理应该能轻松识别出你已安装了Faraday这类库，从而避免引入新手磁铁般的httparty。

      回复

  44. > 早期编程语言遵循类似逻辑：FORTRAN(公式翻译)、COBOL(通用商业导向语言)、BASIC(初学者通用符号指令代码)、SQL(结构化查询语言)，据我所知Lisp代表列表处理。模式很明确：名称传达功能或渊源。

    是也不是。海军曾大量使用JOVIAL编程语言——即朱尔斯自创的国际算法语言版本。而SNOBOL的历史更悠久。

    回复

  45. 干脆都叫凤凰吧。

    (此处梗点：查查有多少重大软件项目曾命名为凤凰，数量惊人。)

    回复

    1. 是的。如果有人抱怨，直接改名叫火鸟就行。

      回复

    2. “双子座”似乎成了现代的凤凰

      回复

  46. 没错。刚给Fedora 43重装系统，某些shell脚本里冒出’ptyxis’的报错。啥玩意儿(擦桌擦键盘)？

    哦，原来是图形终端程序(替代’gnome-terminal’)。嗯…好吧。

    不过经过深入探究(毕竟这事让我耿耿于怀)，我承认确实存在“必须选择唯一名称”的问题(暂且不论商标争议)。我已做好心理准备(算是认命了)应对后续可能出现的残留问题。

    我向来喜欢嘲讽那些注定失败的企业取的’*ly.com’域名，但至少这个名字还没被占用。

    回复

    1. pty是伪电传打字机(即终端模拟器)的缩写，这个词已有50年历史。

      ptyxis 基于 ‘pty’ 词根衍生而来，因为它并非唯一的 pty 程序。

      这个近乎独一无二的名称，对于“揭示其本质”的任务非常有利。

      回复

    2. 这是款可靠的终端，但他们真能选出更糟的名字吗？

      回复

      1. 另有评论指出谷歌搜索几乎不会出现误判(免责声明：本人未亲自验证)。因此最初的“WTF”反应逐渐转化为“嗯，明白了，我懂你们想做什么”。

        回复

  47. 四十年前我用过一款叫Brief的工具，是UnderWare的产品。当时还有位叫Marian的图书管理员。

    回复

  48. > IUPAC命名法确保2,2,4-三甲基戊烷精确指代唯一分子。没有化学家会突然决定把它命名为“史蒂夫”——只因史蒂夫是个有趣的名字，就以为这样能让论文更平易近人。

    不过若在药企工作，他们会说“这款药命名为燃素素，但上市时用Zyphyrax这个商品名，这样医生和患者就能用不同名称指代同一药物”。

    回复

  50. >现代软件开发存在一种奇怪的倾向： 我们集体认定用随机名词、神话生物或虚构角色命名是可接受的专业实践。这种做法在其他技术领域几乎等同于职业自杀。

    奇怪？现代？我2005年入行时所有东西都有傻气名字。DNS服务器叫“雅典娜”而非c302r5s1之类的楼层/房间/机架/岗位名称。我曾重启过一台运行了12年的服务器——它自1993年就持续运转着…名字确实很荒诞。所有设备都有荒诞的名字，通常按类别设置主题。

    >化工等领域同样如此，那里的人们甚至保持着更严格的命名规范。IUPAC命名法确保“2,2,4-三甲基戊烷”精确指代唯一分子。没有化学家会突然决定把它命名为“史蒂夫”——只因“史蒂夫”是个有趣的名字，就想让论文更平易近人。

    食人鱼呢？王水呢？上夸克/下夸克/奇夸克/魅夸克呢？胶子呢？还有三分之一的元素是以人名或地名命名的。

    锔、爱因斯坦锕、费米锕、门捷列锕、锘锕、镅锕、镨锕、锇锕、钅锕、钅锕、钅锕、钅锕、钅锕、钅锕、钅锕——这些人物显然都不叫史蒂夫，但你明白我的意思。

    这种命名倾向由来已久且无处不在。IUPAC命名法不过是数据序列化的便捷方式罢了。

    回复

  51. 精彩的观点！我认为这种现象同样存在于机器学习命名领域，尽管程度没那么严重。或许一切始于亚当。当我说“我用亚当做优化”时，其实是在说用某个随机且不透明的东西做优化。但若改口“我用了基于自适应矩估计的优化器”，就清晰多了。使用人名或随机名词已成为潮流：Lora、Sora、Dora、Bert、Bart、Robert、Roberta、Dall-e、Dino、Sam…每个字母大小写各异。连Transformer都令人费解——它究竟转换什么？更糟的是，以下架构可能取代Transformer[0]： Linformer、Longformer、Reformer、Performer、Griffin、BigBird、Mamba、Jamba……这究竟是怎么回事？

    [0]https://huggingface.co/blog/ProCreations/transformers-are-ge…

    回复

  52. 虽然有点跑题，但我原本打算就命名问题写篇关于“文件名”的帖子

    下载文件时，我经常遇到文件名与内容毫无关联，或是缩写过于简略的情况。这导致查找文件时费尽周折，甚至遇到这类文件时完全不知其中内容。

    回复

  53. 软件包命名的难题之一在于命名冲突。开源软件乃至整个软件界的优势在于，开发者能从其他同类项目中汲取灵感。就我个人而言，曾面临选择哪个类型转换库的困扰：

    – runtypes – https://github.com/runtypes/runtypes

    – zod – https://zod.dev/
    – ajv – https://ajv.js.org/

    AJV和runtypes采用文章建议的命名规范，其名称源于使用场景。而zod的命名则显得突兀。

    我曾开发过名为“ShallowCaster”的简单转换器，随着需求复杂化才转向库方案。但随着竞争加剧，“通用型”命名越来越难找到合适选项。

    或许可考虑在每个包名中添加作者标识，例如“谷歌的json转换器”或“@google/json-casting”，这样既能保持描述性命名又避免冲突。

    回复

  54. 我们公司也讨论过这个问题，最终决定禁止使用“随机”的服务名称。

    最终我们采用“认证服务”而非“加拉图斯”这类命名。问题在于“认证服务”在单仓库中无法检索，查找或讨论该服务信息简直是噩梦。试想若Docker被命名为“容器管理器”，搜索时如何从海量结果中辨别？

    名称的价值不在于自明性，而在于成为伪唯一标识符。记忆它所需的微小认知成本，恰恰构成了人与人之间的共享书签——无论是讨论Docker、Linux还是他人时，都能借此建立指向性对话。

    回复

    1. 当服务被取代时尤其有趣。猜猜哪个服务负责MAC地址分配与存储：macaddr_db还是atom-util？

      回复

      1. “有个仓库叫Beyonder。这绝对是Galactus之后的新物种。”

        回复

  55. 更糟的是Git界面——那些看似在源代码管理语境中意义明确的英文词汇，实际功能可能完全出乎意料，或是同时实现五种不同操作，又或是将多个命令包装成简写形式(如“pull”)。

    与其用错误名称，我宁愿采用幻想名称。

    回复

  56. 作者根本没在做同类比较。

    “蝶形阀”是某类部件的通用名称。

    现实中存在大量“蝶形阀”实例，其中不乏奇特的品牌名称。

    正如众多“Web框架”各具奇特而精彩的名称(“Django”、‘Rails’、“Spring”等)

    其实我们没什么不同。

    回复

  57. > 化学工程等领域同样如此[…]。没有化学家会突然决定把化合物命名为“Steve”，只因“Steve”是个有趣的名字，就觉得这样能让论文更平易近人。

    我明白这并非化学领域，但难道没有15种元素以人名命名(锔、爱因斯坦锕等)，还有若干以地名命名(镅、田纳西锕等)？

    此外，许多元素还以北欧和希腊神话命名，如钍、钛、钚。

    文章还提到胡佛水坝，但政府同样难逃此类命名惯例。最近的“曲速行动”计划名称就完全无法体现其实质内容。

    回复

  58. > 当凌晨两点排查生产环境故障时，http-request-validator的依赖扫描能力远胜于“zephyr”。

    我所知的“Zephyr”是麻省理工学院雅典娜项目开发的局域网工作站集群通知系统。在该系统发布消息后，信息会如清风般在网络中传播。参见：https://en.wikipedia.org/wiki/Zephyr_(protocol)

    我记得80年代有项实验研究(作者是Hartwell、Landauer和Gigliotti，记忆无误的话)表明命名问题并不重要。当时同样的争论就已存在。该研究驳斥了唐·诺曼《Unix真相》论文的观点——该论文声称Unix命令(如“rm”、“mv”等)过于难以记忆。

    回复

  59. 作者严重高估了那些他们熟悉且习惯的事物普遍具备的可读性与亲和力。

    枯燥的名字本质上也过于泛泛，因此往往更难记忆。尤其当存在十款类似工具时——究竟是 sql-validator、sql-schema-validator、schema-validate、db-validator，还是天知道什么其他名称？

    编辑：我更倾向于采用更优质的“副标题”/描述性别名等命名方式。同时支持创意与描述性相结合的命名方式，SQLAlchemy就是典范。

    为何没有名为“whatisthis”的命令行工具？它可通过标准协议让工具简要说明自身功能。

    该方案还能扩展到包管理器，例如“pip whatisthis foo_baz”。

    该死，我们真该开发这个…

    回复

    1. 真正的诀窍在于让名称既能传递足够信息，又能保持独特性。SQLAlchemy就是绝佳范例。

      我把zsh书签工具命名为tutu，初衷是让名称听起来像它的功能。

      – 它助你“前往”目标位置 – 主命令tu因简短、“to”的同音词且未被占用而选用 – 附加命令tutu(执行pushd而非cd)和untu(popd的封装)同样具备简短、易记、可发音的特性。

      所有命名决策都基于人体工学考量。

      是否成功？我个人很满意。已有其他用户采用并给予好评。

      若说成功之处，我认为在于名称既具深意又保持独特性。

      https://github.com/daotoad/tutu

      回复

    2. > 为什么没有名为“whatisthis”的命令行工具？它本可通过标准协议让工具简述自身功能。

      调皮点？用man手册？

      回复

      1. 哈，说得对。或许v1版本直接提取man手册的前几行内容？

        回复

    3. 这可能不是你所说的“whatisthis”命令行工具，但我用了几年cheat.sh和下面这个模式，效果超赞！

      curl cheat.sh/grep # 获取简明grep速查表

      回复

  60. 我也不确定支持字母汤命名法有多好。至少语义化版本控制最终落地了，因为最初它也只是营销和创意的产物。完全不理解他为何在文章里指责谷歌。他甚至忘了提出自己认为谷歌该叫什么——搜索引擎？AWCSS？更荒谬的是，他声称只要Viper和Cobra能自成缩写就接受它们，这暴露了整篇文章的可笑之处。最令我惊叹的是，他竟能写出这么多文字而不自知立场荒谬。

    回复

  61. 我的过往项目：

        'pedes
    Glook
    Fitznik
    Plops
    Gyralight
    我想做款新塔防游戏：于是就做了

    哦对了还有https://lerc.itch.io/namesarehardpart5

    文中举例的现实事物——金门大桥和胡佛水坝——都是具体实例。它们所属的类别历史悠久，“水坝”和“桥梁”早已不是新词。

    若创造新事物就需新命名。软件本质上是新事物——计算机普及不过数十年。软件实例通常连专属名称都没有，仅用编号加项目名或昵称标识。我敢打赌金门大桥和胡佛水坝当初都有项目代号或绰号。

    回复

  62. 我想要的那个词是哈利路亚！

    命名文化已无可救药。当命名逻辑从“我们创造新词来命名事物”演变为“我们将早餐松饼配猫咪图片的网络梗概念，与开源工具的既有应用融合，以此更精准地命名抽象事物——所以它叫7Mermaids”时，就彻底越界了。

    记得当年雅虎耗巨资投放广告问“你用雅虎吗？”如今这门商业老课竟被彻底遗忘。

    回复

  63. 我认同这种观点，不过论证可以更严谨些。关键不在于好名字是否描述性强，也不在于是否便于记忆。现代命名风格的问题在于，常无端堆砌随机英文词汇——要么为追求可爱(我认为这算不上正当理由)，要么试图唤起与产品无关的联想。问题在于，某个词汇可能引发与软件截然不同的联想，导致概念冲突。反之，若需频繁使用该软件，它又会侵蚀你原本对该词的语义认知。我希望软件及其名称能保持独立性，谢谢。

    回复

  64. 同样的情况也适用于其他领域，比如化学工程领域，那里的从业者保持着更为严格的规范。IUPAC命名法确保2,2,4-三甲基戊烷精确指代唯一分子。没有化学家会突然决定把它命名为“史蒂夫”，仅仅因为史蒂夫是个有趣的名字，就觉得这样能让论文更平易近人。

    这点其实无关紧要，但至少在化学领域绝非如此。许多分子名称并非基于IUPAC规则，而是采用该领域通用的前缀/后缀命名(药理化学领域尤甚，但不限于此！)

    回复

    2. 同分异构体不共享名称吗？同位素名称也不变，对吧？

      回复

  65. 我最初注意到企业命名现象，不过至少能理解：无意义名称便于业务转型。

    若公司名为“数据库公司”，后来转向区块链再转投人工智能，原名可能成为障碍。

    但若最初就叫“Gworp”，就不会有这种困扰。

    (不过“Mt Gox”即“万智牌在线交易所”算正反例还不好说)

    回复

    1. Mt. Gox是事后更名的案例，本质上只是重新诠释了原初字母缩写。

      回复

  66. <题外话>

    最近不少博客为何禁用常规右键操作？可能与此相关的是，滚动体验也糟糕透顶。

    这个博客就是一例，只要我在工作用的高性能Macbook上滚动时发现不流畅，立刻就退出。

    回复

    1. [OP] 请重新确认一下？正常情况下右键和滚动功能不应受影响，若你遇到此问题，很可能是你端的问题。

      回复

      1. 你说得对，抱歉。当时在公司使用，那里装了各种监控软件，可能是那个原因。在家用电脑一切正常，感谢确认。

        回复

    2. 更让我恼火的是浏览器竟允许此类操作，比如某些剪贴板功能的篡改。

      回复

  67. 你们给产品命名吗？

    我们有内部代号和正式产品名。内部代号最初描述项目/仓库/工具属性，但18个月后就失去意义，于是改成随机名称——州名、湖名、总统名、山名等，纯属占位符。

    面向公众的产品名称是市场营销、商标注册和CEO审批的折中方案。在创业圈里，连公司名称都可能变更。绝非玩笑：隔壁那家初创公司就因名称过于阳刚而被迫更名，他们发现目标市场半数以上用户竟是女性。

    回复

    1. 这就是命名之道：用与软件毫无关联的随机词汇命名，避免未来功能扩展或变更时造成混淆。

      最初我们仅支持邮件通知功能，故命名为EmailServ。但随着发展，它已演变为功能强大的通用队列服务，如今承担着所有后台任务处理。发送邮件实际由EmailWorker处理，但EmailServ仍保留原始API接口——若你习惯旧方式，它现在仍会在后台调用EmailWorker。

      回复

  68. > 我们采用Viper进行配置管理，其数据流向Cobra实现命令行界面，Melody处理WebSocket连接，Casbin管理权限，所有任务均通过Asynq队列执行

    是否改写为以下形式更佳：

    > 我们采用ConfigurationManager进行配置管理，其数据流向CLI实现命令行功能，WebSocketHandler处理WebSocket连接，PermissionManager管理权限，所有操作均通过JobQueue实现任务队列

    (我认为作者表达了与本意相反的观点)

    回复

  69. 正如物理学所言：色子与魅子或许变幻无常，但上下子永远不变。

    回复

  70. 当项目数量庞大时，代号是绝佳的标识符。如今的软件项目数量已创历史之最。

    我欢迎Splorg、Chizzel、Rapunzel、Brap、Titoid和Chungus——只要效果出色，名称无所谓。

    回复

  71. 认知负荷确实是个问题。使用随机可爱的名称时，行为边界变得模糊不清。身份验证该归入SnufBux模块？还是Farfrumstable服务？谁知道呢？缺乏明确的语言线索来处理新概念时，任何新功能都会在这些内部边界间四处散落。反正这些名称本就毫无语义意义！草率的命名只会助长草率的编程。

    回复

    1. 你已经洞悉了为何正常、常规、简单、自然、真实的数学难以让人一眼领会。

      回复

  72. 这就是我欣赏Julia软件包生态系统的一点。通用注册库(用于存储软件包元数据并注册新软件包)建议使用完整名称而非简写缩写。例如，DifferentialEquations.jl是Julia中处理微分方程的软件包(通过.jl后缀可识别)。那么Garlic.jl做什么？没错，就是大蒜(蔬菜)建模。

    回复

    1. Julia注册库是否设有活跃的审核机制？否则我预计会看到99种不同的DifferentialEquations.jl变体。

      回复

      1. 是的，但审核机制较为宽松。新注册的首个包需通过自动检测，若全部通过则进入为期3天的社区反馈期，期间可提出异议。若3天内无人阻止，该包即完成注册。

        其中一项自动检查是名称相似性检测，若名称与现有名称过于相似，则该包将被阻止自动合并。此时将由人工审核，并就名称是否合理展开讨论。多数情况下，系统会判定为“误报”并放行包注册。有时则会展开名称可接受性讨论，并给出替代方案建议。

        _______________

        近期发生过这样一桩小插曲：有人试图注册与现有包同名的包，仅在名称末尾添加两个字母。该包实为现有包的分支，因提交者对维护者未响应拉取请求感到沮丧，故添加了小幅修改。

        系统自动标记了该名称，该用户起初因无法直接注册分支而感到不满。但短短数小时内，我们便联系到维护者修复了原有包，并将其添加为原始包的维护者，使其能够自行审核并接受该包的拉取请求。我认为这对所有相关方而言都是更理想的解决方案。

        回复

  73. 本文逻辑混乱。作者在谷歌(绝佳命名)这类公司名称与AWK(毫无描述性但好名字)等工具间反复跳跃。

    不过我深切体会到入职培训的痛苦——当初加入Humungous Entertainment时，工具系统被命名为“痰液”、“粘液”、‘唾液’，甚至可能还有个“胆汁”。:-)

    回复

      1. 看到它用Rust编写且完全兼容Acid规范真是令人欣慰…

        回复

  74. 我认为促使斯托曼发表那场演讲的契机之一，是emacs内置了lsp客户端“eglot”。据我所知eglot是emacs polyglot的缩写。

    最符合惯例的名称lsp-mode已被其他包占用。斯托曼想另寻新名，但似乎没人像他那样在意。记得他曾提议过“code-parse”之类的替代方案。

    回复

  75. 很多命名问题其实关乎营销策略。有人为工具命名追求噱头效应以博取名声，也可能是公司层面的考量。锤子就是锤子，重锤就该叫“heavy_hammer”。

    编辑：刚注意到文章里也提到了营销角度。

    回复

  76. 我曾在HN上读过一篇文章(记不清具体内容了)，建议给单体应用取完全无意义的名字。核心观点是：不该依赖名称来决定服务该包含什么或排除什么。

    因此上份工作中，我们把单体系统命名为“阿努比斯”。每当有人追问含义时，总能收获满满的欢乐。

    回复

  77. 抛开工具不谈，在全球多数地区，程序员和软件开发者自称的“软件工程师”甚至不被视为工程类职业。

    这就是为何软件工程系大多设在计算机学院而非工学院的原因。

    回复

  78. 深表赞同，脑海中浮现的还有“芹菜”和“Windows”这类命名。但蠢名永远层出不穷——我偏爱“Plan 9”这个以埃德·伍德B级片命名的操作系统。其姊妹系统Inferno则充满双关语，处处暗藏但丁《神曲》的典故。那些企业呆子总坚称中性无趣最讨喜——我虽认同此观点，但这绝非铁律。

    回复

  79. 为何旧金山人从不说“我要走旧金山-奥克兰海湾大桥”，而简称为“海湾大桥”？这就是某些桥梁能拥有优美名称(如金门大桥)，而另一些仅具实用功能(如旧金山-奥克兰海湾桥)的缘由。

    我确信世上还有其他“海湾桥”的存在。

    回复

  80. 我认为任何人若提出或甚至提议新的缩写词，都应被征收某种税款或罚款。无论涉及哪个领域。虽然我某程度上认同这篇文章的观点，但我仍认为即使从字典里随机抽取一个词，也比YAA(又一个缩写词)要好。

    回复

  81. 除非采用单一集中化系统，否则根本无法赋予描述性名称。名称必须保持一致性，这是优质命名体系的核心要求。当整个命名体系保持一致时，单个名称几乎可以任意设定，影响微乎其微。

    回复

  82. 为何非要全盘接受或彻底否定？何不为营销保留一两个醒目名称，既能在“我不是让你搜索，而是让你使用搜索命令”这类句子中脱颖而出，又避免过度浮夸——比如把所有功能都冠以北欧神祇之名之类的荒诞做法。

    回复

  83. 本就没有什么既定路线可循；既然编辑器名称比不上“vi”(毕竟“ed”已被占用)，或许干脆废除动词命名法，打造更“焕然一新”的品牌形象？

    回复

    1. 我只想有个编辑器！不要什么“viitor”，更不要“emacsitor”——这些根本不是词！！！

      试想把公司命名为“商业公司”，这种命名允许吗？

      回复

  84. 描述性命名在初次接触时确实有帮助，尤其当你浏览依赖列表或培训新人时。这点毋庸置疑。但实际应用中，名称很快就会失去实际意义

    回复

  85. 我开发了一种结构化查询语言。基于这篇文章，我决定将其命名为SQL。

    回复

    1. 叫Sequel会更容易发音。我决定在心里这么念。

      回复

  86. 而蝇类物种“Phthiria relativitae”的命名，正是将“相对论”与“Reissa roni”(即“Rice-A-Roni”品牌)双关戏谑的产物。

    回复

  87. 从这个角度看，会议室命名又如何？我现在的公司用橄榄球队或本地地标命名。但听说某公司曾用二战战役命名会议室，结果面试时让日本员工进其中一间时很尴尬。

    回复

  88. 我认同这种做法的领域是人体解剖学。输卵管(Fallopian tube)不如输卵管(eileiter/oviduct)更符合解剖学原理。

    回复

  89. 软件工程中最难的三件事：缓存失效、命名和偏移量错误。

    回复

  90. 解决相同问题的工具五花八门，能力参差不齐。

    它们不可能都用相同名称。若想打造现有方案的替代品，就必须另起新名，这导致命名变得随意。

    回复

  91. 这让我抓狂——我用dmenu启动程序，每次想打开Subsonic客户端时都要念叨“蓝莓？韦申…韦什…菲…菲申！”

    干脆直接叫“subsonicfeishin”之类的名字行不行！

    “Chatgpt… Mc… CODEX！”

    简直疯了。

    回复

  92. 我完全理解这种感受，但软件命名确实困难：a) 显而易见的名称容易被占用；b) 我们处理的对象本质上是具有任意属性的抽象关系。

    回复

  93. RMS(GNU之父而非Unix之父)对命名规范有见解？

    回复

  94. 我更希望开发者为项目自创名称以便检索，至少用个冷门词。Gradle就是好例子。

    回复

  95. > 认知税

    > 每个晦涩名称都是对接触它的开发者征收的交易成本。

    这并非心理负担，而是认知税。更何况是交易成本？向人们征收？占用他们的内存？

    日常英语的简单表达去哪了？

    回复

    1. 总之。我们用了MongoDB好一阵子。

      回复

  97. 超赞建议：

    > 按功能命名库。使用复合词。必要时接受冗长。当凌晨两点排查生产故障时，http-request-validator远胜于“zephyr”。

    回复

  98. 最糟糕的例子：Homebrew命名规范

    典型文档句式：

    > “keg-only”指什么？表示该公式仅安装到Cellar仓库，不会链接到默认前缀。

    回复

  99. 按作者标准，macOS和iOS的程序命名堪称完美：

    App Store、邮件、照片、音乐、书籍、播客等。

    回复

  100. 我几乎完全反对这篇帖子。唯一能认同的是：你应该避免使用令人尴尬的命名。

    描述性名称稍有偏差就糟糕透顶。若库被改作他用，或项目未达预期却仍有价值时更是如此。面对纷繁复杂的状况，无意义名称能迫使人们主动了解其本质，而非让他们从可能误导人的三字描述中妄加揣测。

    作者可能从未经历过这种情况：某个项目被命名为“示波器控制器”，却根本没有示波器踪影。但我们曾经有过示波器，后来调整了几个参数，现在它运行着其他功能，而这个名称早已遍布各处。

    这些都是抽象概念。将数据从点A传输到点B。FIFO？只是首字母缩写。管道？并不能暗示它能缓冲数据。缓冲区？队列？听起来都像是会拖慢数据传输的东西。精确的技术名称固然好，但功能变更的概率也会随之增加！

    回复

  101. R延续了“差一个字母”的传统，它源自S，而其创建者正是Robert和Ross。

    回复

  102. 我认为若始终采用描述性命名，最终会导致多个工具名称重复。

    回复

  103. 不如直接用作者姓氏命名。就像物理学有麦克斯韦方程组，我们就能拥有托瓦兹操作系统。

    回复

  104. 我无法将新公式翻译语言命名为FORTRAN，因为这个名字已被占用，许多其他名称也同样如此。为避免冲突，最终以我家猫的名字命名。

    回复

    1. FIVETRAN作为猫名确实怪异，但至少能避免在兽医诊所搞混。

      回复

  105. 有趣的是我今天刚讨论过这事。要多久才会有人孤注一掷，直接把应用命名为“尿尿便便”？

    回复

  106. 即便是消费类产品——我宁愿看到Mozilla邮件和微软邮件，也不愿看到Outlook和Thunderbird。但该死的营销就是得营销。

    回复

  107. 我完全赞同。比起Viper这类晦涩无意义的名字，更让我困扰的是Hunchentoot这类愚蠢又尴尬的命名。这类名字有时会让人错过优秀软件，就像在严肃研究论文里用Comic Sans字体一样。

    科学领域确实存在类似命名现象，生物学便是典型。生物学家常以名人命名物种，例如虱子Strigiphilus garylarsoni：

    https://en.wikipedia.org/wiki/Strigiphilus_garylarsoni

    回复

    1. 我同意。近期例子是Zig社区中流行的基准测试工具“poop”[1](性能优化观察平台)。它本可命名为“pop”(性能观察平台)，既保持俏皮又不刻意引发尴尬。如今每次看到Zig，我都会联想到“poop”。

      [1]: https://github.com/andrewrk/poop

      回复

  108. 我最爱的例子——90年代扫描仪/成像驱动程序的“Tech without an interesting name(TWAIN)”。

    回复

  109. 趣味派对游戏：问别人是否知道ChatGPT。当他们必然回答“知道”时，再问GPT代表什么。

    回复

  110. 按这个标准，ChatGPT真是绝妙命名：它是个能和你聊天的生成式预训练变换器。

    回复

  112. 用描述性名称命名和用可爱名称命名同样困难。

    回复

  113. 真羡慕那些能为简单想法写出多段落文字的人。

    回复

  114. 计算机科学中最难的两件事：知道何时清空缓存，以及如何命名事物。

    回复

  115. 先是赛马，接着是处方药，然后轮到软件了。

    但愿这股风潮别再蔓延。

    回复

    1. 不过精酿啤酒的名字倒是另当别论。

      回复

      1. 举个近期例子：俄勒冈州波特兰市巨酿啤酒公司的产品——《猫咪偷吃我的藏酒还尿在圣诞树上》
        酒款类型：美式IPA。

        回复

  116. 开源工具我不清楚，但企业内部项目用代号自有其道理。

    回复

  117. 基因和物种有时也会被冠以荒诞的名字。

    回复

  118. 看到这个帖子真高兴，每次学习新工具时，那些既不具备项目专属性，又无法描述项目本质的名字都让我抓狂。

    比如静态网站生成器Zola和Hugo——这些词本身独特且专属，对我而言没有其他含义。我唯一知道的Hugo是《鲍勃汉堡店》里的角色。但选择像Avocado(牛油果)或Spice(香料)这类随机词典词汇，完全无法与我的既有知识建立关联，导致我陷入作者描述的“脑内检索困境”。

    前几天有位HN用户评论道：“NAT，又名IP伪装…(随后继续重复使用该术语)”。据我所知，除非整个组织和供应商都使用Linux，否则业内无人会说“IP伪装”。直接称之为NAT就行，大家都明白意思。这是Linux圈的术语，应当避免使用！

    查阅Britannica.com的词条：

    > 指人们戴面具、常穿戏服的聚会
    > 指虚假或不真实的表象或行为
    > 指伪装成他人或他物

    我猜？我们是在“伪装成对等IP，实则使用局域网IP”。但对我来说这纯属无稽之谈。重点在于大写的T——为路由目的将一个IP转换为另一个IP，别扯什么奇怪的社会隐喻。

    回复

  119. – VTL-O2
    – Forth
    – Grep
    – CVS(我虽非美国人但能理解)

    – Clang

    尽管微软产品同样晦涩难懂，甚至更甚。IBM就更不必说了…

    回复

  120. 记得flickr开创了随意省略元音的命名潮流。

    回复

  121. > 你的HTTP客户端、命令行工具辅助程序、任何库都不是消费级产品。

    不明白作者如何得出这个结论。

    总之程序员在这方面并不比数学家更糟。只需把[虚构名称]替换成某个外语词汇或哲学术语，再用你听过最离谱的逻辑迂回来解释即可。试想古拉丁语使用者，你觉得他们会知道矩阵的用途吗？不会，因为这个词本意是“子宫”。它与“线性变换的表格化表示”毫无关联。

    显然作者是借此宣泄不满，但他们误判了真正的问题所在：

    > 当凌晨两点排查生产环境故障时，http-request-validator 远比“zephyr”更胜一筹。

    读到这里我简直惊掉下巴。居然有人在调试代码库时连依赖关系这种基础概念都不懂，这在我看来简直荒谬至极。这种状况既疯狂又骇人，几乎盖过了整篇博文的其他内容。难道还有人过着这种日子？你们怎么忍受这种环境？为什么要忍受这种环境？

    回复

  122. 我依然认为ICQ是史上最棒的应用名称。

    回复

  123. 难道连乐趣都不被允许了吗？过去三天我在HN看到诸多帖子和评论宣称：

    – 界面元素必须实用，装饰性图标有害
    – 演示文稿禁止使用动画效果
    – 现在连有趣的名字似乎也被禁止了

    搞什么鬼？

    > 没有化学家会起床后决定把化合物命名为“Steve”，就因为Steve是个有趣的名字

    要不要讨论物理学家给夸克命名的事？

    回复

    1. – 博客和HN上的内容几乎全是个人观点，别太当真

      – 趣味与幽默具有主观性，很大程度上源于新颖性和颠覆预期。当观众已见过数十次相同内容时，很难再制造出有趣的东西

      – 受众背景与预期千差万别且随时间变化，因此“趣味”具有特定受众属性且往往呈周期性

      回复

      1. 你说得对，深入探究后发现终究只是炒作噱头

        回复

  124. 我喜欢调侃当前主流趋势是可口可乐驱动的。

    回复

  125. > 化学工程等领域同样如此，那里的学者恪守着更为严苛的规范。IUPAC命名法确保“2,2,4-三甲基戊烷”精确指代唯一分子。绝无化学家会突然决定将其命名为“史蒂夫”——只因“史蒂夫”是个有趣的名字，就以为这样能让论文更平易近人。

    呃…

    https://en.wikipedia.org/wiki/List_of_chemical_compounds_wit…

    “你确定吗？你真的确定吗？”

    我最爱这个：有一种名为“刺猬蛋白”的蛋白质对动物胚胎发育至关重要。(所有“刺猬”家族蛋白质在突变后都会使果蝇呈现刺状外观，故得此名。)当化学家合成出抑制SHH蛋白作用的药物时，他们将其命名为“机器人素”。

    回复

    1. 果蝇研究者的命名方案最妙。真希望我们能延续这种充满奇思妙想的基因命名传统。比如我钟爱的RING基因——“真正有趣的新基因”。我常说若发现有趣基因，定要命名为RUNG。

      回复

    2. “windowpane”是我脑海中的第一个念头 🙂 真是对“-ane”后缀绝妙的玩味

      回复

  126. > 你的HTTP客户端、命令行工具辅助程序或任何库都不是消费级产品。

    > (…) 每个接触到你“有趣”名称的人都要付出微小代价。在整个行业中，这些代价累积起来就是巨大的浪费

    开发开源工具的程序员对你或整个行业毫无义务。你竟把诺姆·乔姆斯基列在“推荐研读作品”里，却似乎认为资本家有权索取免费劳力，甚至开始提出要求。

    回复

  127. 我发现“命名更多是文字游戏而非目的”这番评论… 倒觉得挺有趣？毕竟人们总会用现有工具玩出花样，编程领域里这工具往往就是文字——还能是什么呢？

    极客生态中最糟糕的现象，莫过于时不时冒出的怪异信念：名称理应具有特殊意义。每个生态圈都存在类似妄想，总以为只有自己领域才会滥用命名。

    随便翻翻那些出人意料地以人名命名的清单吧。当然，你可以为Shell排序算法和贝壳毫无关联而恼火，或为布隆过滤器没有数据“绽放”的阶段而纠结。但同样的问题也存在于法式排水系统，或是“燃气灯效应”与用燃气点火及其影响毫无关系。

    老实说，我觉得这份清单完全可以无限延伸，就像当年那些查克·诺里斯笑话生成器一样有趣。

    回复

  128. > 用随机名词、神话生物或虚构角色命名竟成了行业惯例。这种做法在其他技术领域简直是职业自杀。

    真的吗？你最近看过微处理器的规格说明吗？见过药品的命名方式？知道聚合物复合材料是如何命名的？

    回复

    1. 微处理器中的“掠夺者湖”代号仅用于内部，产品上市时采用系统化命名。工程师通过编码代际、层级和性能等级的型号编号来指定芯片规格。

      在医药领域，医生开的是“西地那非”而非“伟哥”。通用名描述化学结构，品牌名是面向消费者的营销手段，而非专业命名体系。

      化学/天文学中的神话命名承载着数百年积淀，与人类文化史紧密相连。以泰坦命名的“钛元素”自带分量，但将SQL复制器命名为“土拨鼠”——这究竟关联了什么？周末去动物园？

      回复

      1. “掠夺者湖”并非内部代号，而是英特尔对外公开使用的正式命名。普通消费者购买电脑时，怎么可能分辨它比“月湖”或“桤木湖”更好或更差？或许他们只会觉得新电脑附赠了款游戏——里面那只巨型恐龙鸟得中途停下来喝水恢复能量。

        但无论如何，命名荒谬之处不在此。真正的问题在于重复使用常见词汇。文章批评“谷歌”这个名字，其实它堪称绝妙——当年搜索这个词时，所有结果都精准匹配需求。相比之下，Alphabet就是个糟糕的名字，因为搜索这个词时，只有极少数结果对你有用。

        回复

      2. 消费品营销中的命名方案具有特定功能：易识别、独特且令人难忘。这些特性通过将独特名称与特定服务/功能/使用效果关联，实现产品标识。

        医学与化学术语体系建立在拉丁语词汇及复合词的历史基础上，其单词构成遵循相同模式。值得一提的是，这些拉丁词汇常指代神话、奇幻或特殊事物——例如水星(Mercury)的命名。唯一区别在于：科学演进耗费数百年时光，才将这些独特名称转化为具有独立逻辑的分类学语言体系。

        计算机科学尚未形成此类分类体系。但在该体系演进过程中，它终将从我们惯用的程序与工具名称中脱胎而出——诸如Rust、Ocaml(注意其兼具趣味性与技术性的组合)、git、npm、bun、ada、scipy等等。

        回复

      3. > 医生开的是“西地那非”，不是“伟哥”。

        这取决于地区吧。我遇过医生直接开商品名处方的情况——我不明白为何在存在剂量相同、给药途径一致且辅料相近的替代品时仍如此操作。更别提那些“不可替代”的处方了，这类要求大多也基于可疑依据。

        至于“西地那非”——我认为通用名通常没什么实际意义。后缀通常与药物类别相关，但前缀字母看起来和商品名里的字母一样随意。我甚至能想象这样一个世界：通用名叫“伟哥非”，商品名却叫“西地”。

        回复

      4. 通用药物名称并不描述化学结构，它们仅暗示用途而已。“-afil”后缀用于特定药物类别，尽管在发现时“西地那非”是该类唯一代表，因此这个后缀本身原本就毫无意义。

        这好比某类工具的首创者将其命名为“Mosaic”，随后同类工具出现时却被称为“Mozilla”。

        回复

      5. 但我们讨论的名称是面向用户推广软件时使用的？我不明白为何不能套用相同逻辑

        回复

    2. 品牌药品的情况略有不同。品牌名称必须同时符合FDA、欧洲药品管理局和加拿大卫生部的命名规范。实际操作中，这使得使用真实词汇变得困难。因此我的公司采用“空容器”命名法——即创造无实际含义的词汇，需满足三点：(1)能引发情感共鸣(如wegovy就是好例子)，(2)可注册商标，(3)能承受品牌压力。

      回复

  129. 刺猬索尼克基因想说句话。

    回复

  130. 我完全不同意。若你说“本告诉玛丽他周二会和斯科特一起修杰夫的房子，但艾米更希望周三”，这句话对说话者和听者都承载着丰富含义——因为这些“名称”对双方都有明确指代。没人能忍受这种描述性替代方案：“总承包公司老板告诉总承包公司秘书，他周二会和总承包公司雇工4号一起修缮客户22号的房子，但客户22号的配偶更希望周三施工”。

    回复

  131. 就像Gmail地址一样，所有好名字都被抢光了。

    回复

  132. 名称向来古怪，但新命名似乎多出于品牌营销考量(我对此不以为然)。你几乎能将“[任意名词] javascript库”输入谷歌就能找到对应结果。这个领域已然饱和，导致名称与实际描述的关联度日益疏离。真该有人创建labubu.js，让人们少做这种事。可用matcha(注意：非matcha.css)进行性能基准测试。

    回复

  134. 无关紧要。大型语言模型早已掌握所有名称。一年后它们将接管所有SSH和终端操作。

    快答：编译器为数学运算生成的AVX2指令名称

    回复

  135. 虽与本文主题偏离，但Debian在这方面堪称最糟。应用程序会被赋予友好名称以提升用户体验。(例如：gedit被称为“文本编辑器”)但用户名与实际包名之间往往毫无关联可循。想卸载gedit？若你连它的真实名称都不知道，那只能祝你好运了。

    回复

  136. 有时“品牌化”命名确实有益。

    例如，严格按功能命名应用模块极其繁琐，且会占用预留术语导致命名歧义。假设系统存在多种权限机制，但若将特定权限系统命名为希腊神祇名称，就能在团队(业务与技术人员)间建立清晰统一的认知——请注意，沟通的本质正是建立共同认知，别无其他。

    附注：(此处刻意回避该命名方式的弊端讨论)

    回复

  137. “…当你看到’libsodium’时，必须从问题解决模式切换到侦探模式：‘这是什么？让我查查README。啊，是个加密库…’”

    若README文件能更清晰地说明命令的背景与功能，我倒不介意那些词源复杂或富有创意的命令名称。尽管我在计算机系统领域涉猎广泛，仍常遇到令人困惑的README文件。我不该需要层层搜索才能找到线索。

    回复

  139. 现代网页开发者：“哦我只用Gulp、Jenkins、Babel、Yarn、Bower、Grunt、Slurp、Vite和Rollup”

    我：厌恶地慢慢后退

    回复

  140. 我完全赞同楼主观点。首页上太多帖子取名像“汉堡包——某个工具”这样，既不醒目也不独特，以后想找起来简直要命。

    回复

  141. 最讨厌那些剽窃科幻概念的玩意儿，每次看到什么“戴森球冷聚变无人机”之类的名字，我都会被虚假兴奋感蒙蔽。

    回复

  142. 这种愚蠢的AI生成的文字怎么会出现在Hacker News上？

    回复

  143. 我至少十年都认同这个观点。命名要体现功能本质。

    厨师做什么？园丁？猪？打嗝？

    胡说八道。

    回复

  144. “我们用confman管理配置，配置流向climan生成命令行界面，wsconn处理WebSocket连接，permgr管理权限，所有操作都通过jqueue进行任务队列处理”

    这样就好了？这是《高地人》的设定吗？每样东西只能存在一个？那这些工具的变体呢…cman2？confman？cfigmgr？项目命名(进而工具命名)往往既关乎命名空间也关乎含义。绝大多数非简单工具/项目必然存在多个版本，不可能每个配置管理器都叫“confman”(即便这算“好名字”)。

    关键在于将实用性与“名称”关联：若将“你那个拥有45颗GitHub星标的MIT许可文件解析器”简单称为“解析器”，几乎注定永远拿不到第50颗星——因为已有大量同名项目，用户毫无理由找到你的版本。

    “每个名称都索要贡品：几秒钟的脑力解码。这些秒数累积成分钟与精力，最终堆成贯穿职业生涯的认知消耗之山。”

    并非如此，因为你并非每次都进行这种解码。就像“grep”现在对你来说再自然不过——毕竟你用了这么久；当你在某个项目中工作时，“cobra”这类词立刻会联想到“那个命令行库”。最初几次或许需要片刻思考，但人类擅长内化这类抽象概念，程序员在这方面更是出类拔萃。

    Unix工具的例子实在糟糕。“我用grep检查etc目录下的配置文件，再用cat合并后经sed和awk处理，最后打包成tarball通过curl上传到webdav服务器。”这些操作之所以直观，纯粹因为你早已熟知它们。“sed”代表“流编辑器”？拜托，这名字可不因合理而得名。为何不叫strmed甚至streameditor？简单直观不是吗？只因’sed’在保持独特性与记忆度的前提下，实现了最短字符数的极限。awk更是反驳文章论点的绝佳反例：纯粹是乱码，毫无意义！与实际功能完全_毫无关联_。

    “金门大桥的名字告诉你它横跨金门海峡。”

    呃，它可没告诉你这个。布鲁克林大桥横跨布鲁克林海峡吗？乔治华盛顿大桥呢？桥梁命名并非专指其跨越的水域，软件命名也并非完全对应其功能。

    回复

  145. 这读起来像是对个人偏好的冗长辩护，坦白说令人疲惫。个人偏好无可厚非，我也有自己的选择。但请别以为它们具有普适性。

    Laravel比Rails-but-PHP好用。Ruby on Rails胜过“固执己见单人堆栈用Ruby”，我对Ruby这个名字也毫无意见。

    为致敬楼主，我将新产品命名为larmn。

    回复

  146. 等你进入企业环境就知道了——“模糊芥末项目”触发了黄丘子系统的弹性鱼指标违规，最终演变成“轻度薰衣草代码”配粉色糖粒。

    回复

    1. 我待过那种在摞里塞生菜、番茄和芹菜的项目。

      回复

    3. 我他妈真参与过“洋红色龙虾计划”。

      回复

      1. 那算什么，我们有个叫“粉红手套”的项目。

        回复

  147. 我同意内部命名这样做，但反对公开软件/外部命名采用这种方式。

    我反对公开/开源软件采用这种命名，因为：许多软件其实已有好名字。虽然它们使用神话名称，但功能相似或存在关联性。

    不过我支持内部命名，因为：我接触过太多(遗留)代码命名糟糕透顶。问题不仅在于名称本身，还涉及大小写规范和命名一致性。说真的，在某家FAANG公司，我见过用于一级服务值班系统的“蜘蛛侠活动”和“蝙蝠侠活动”这类命名。

    >(虽然该系统并非一级服务，但也并非完全属于二级服务——它实际支撑着一级服务的运行，某些故障可能引发严重后果…)

    试想你正试图理清一个庞大系统，它可能存在数十个依赖项和同等数量的被依赖项，你还得努力回忆哪个API是“蜘蛛侠”，以及它与业务究竟有何关联…

    关于命名规范，还有那些可怕的首字母缩写(这种现象不仅限于软件工程领域)，以及产品经理们发起投票/调查来给“我们这个能实现X功能的新玩意儿起个有趣的名字，但我们不想直接这么叫它”。

    更深层次的问题在于工程师自身的疏忽。我见过太多CDK堆栈命名混乱：不仅混用连字符与下划线，还存在微妙的大小写差异。

    每年我都在解决Java开发者的问题，其中不少属于“在我机器上能运行”的类型。而相当比例的问题源于多数开发者使用Mac和macOS——其文件系统默认不区分大小写，但部署目标和CI环境是Linux系统，文件系统区分大小写。由此可见，驼峰命名法若遇疏忽，便会造成数小时的无谓浪费。

    > 这简直是场灾难。

    诚然存在AI的疏漏，但人类同样粗心大意。我对LLM/生成式AI颇为满意，它们不仅能捕捉这类问题，本身也较少犯此类疏忽(作为“预测文本引擎”，其词汇建议本质是历史词频数据的复刻)。

    与此同时，各类缩写词引发的“幻觉”现象令人咋舌。这本在所难免——即便作为人类，若缺乏上下文，我也可能陷入困惑或直接套用已知信息…

    回复

  148. 反驳观点：

    Pascal, Eiffel, Ada, C, APL, Dylan

    回复

      1. 有趣评论：

        > InfoWorld：据我所知，JavaScript最初名为Mocha，后更名为LiveScript，直到网景与太阳微系统合作时才定名为JavaScript。但它实际上与Java毫无关联或关联甚微，对吗？

        > Eich：没错。从1995年5月到12月短短六个月内，它经历了Mocha到LiveScript的演变。12月初网景与太阳公司达成许可协议后，它正式更名为JavaScript。其初衷是打造一种与Java编译语言互补的脚本语言。

        回复

  150. 这再次证明软件工程中有三大难题：命名、缓存失效和偏移量错误。

    回复

  151. 是我眼花还是网站完全无法阅读？黑色文字配深灰色背景

    回复

  152. 其实还有个未提及的好理由：别按功能命名工具

    – 功能终将改变

    你的“硅谷银行集成器”终需更新以承担新任务。

    或你的“登录页面配置服务”终将超越登录功能。

    采用无意义词汇或神话命名既能形成易记名称，又避免让人误认其功能——这些功能可能早已过时。

    回复

    1. 此外，过于精确简洁的工具描述会导致不同实现方案在命名上相互竞争。

      项目名称应具备足够的唯一性，使其能成为项目标识符：

      – 便于定位项目
      – 支持项目范围的扩展或收缩

      拥有标识符至关重要，虽然将其与项目初衷关联很理想，但这属于次要考量(只要不因变更导致误导即可)。

      回复

    2. “目的会改变”的论点恰恰证明了相反观点。当工具范围超出其名称所示时，描述性名称会警示你出了问题。即便如此，即使需要将“登录页面配置服务”重命名为“身份验证配置服务”，也并非大问题——若采用描述性命名，重命名成本将大幅降低。但最关键的是，我不愿为避免重命名(项目生命周期中仅发生一次或两次)而牺牲可发现性(每次接触工具时都会发生)。

      回复

      1. > 若改为描述性名称，重命名成本将大幅降低

        我可不这么认为，发布后重命名简直是噩梦。

        假设你想把fish改名为a-decent-shell：- 所有发行版的包都需要重命名- 所有使用/安装fish的系统配置都需要修改- 脚本需要变更，从shebang到内容都可能需要调整 – 用户需理解现在必须用新名称检索文档。 – 文档需迁移至新域名，经sed替换后重新审核。

        所有迁移工作都需要跨多个发行版和部署环境的同步多步骤流程。

        我更希望采用能作为标识符的名称。

        回复

        1. 假设你想把fish重命名为a-decent-shell

          你这恰恰印证了我的观点。重命名之所以困难，正是因为最初选错了名字。所以从一开始就该选对名字。

          你列举的所有成本[发行版包、配置文件、脚本、文档、域名]无论重命名为描述性名称还是另一个随机词汇都同样存在。迁移痛苦完全相同。“Fish”→“decent-shell”的成本与“fish”→“zephyr”无异。我的核心观点是：若最初就选用恰当名称，这种重命名根本不会发生，且极少出现更名需求。我们不该为规避重命名而优化——这无异于用永久性的认知负担来换取罕见的维护事件。

          回复

          1. > 重命名之所以困难，恰恰是因为你最初就用了错误的名称。所以必须从一开始就用对名称。

            不，问题在于该死的字符串ID遍布太多地方，你不可能用sed命令一次性替换全世界。无论这个字符串多么可爱、多么花哨，或是你认为多么合适，都无关紧要。

            回复

          2. > 我们不该为了避免重命名而进行优化。

            > 你应该从一开始就取对名字。

            这本质上仍是避免重命名，只是方式不同；况且你刚说重命名成本很低，到底哪种说法才对？

            回复

    3. 采用任意代码名确实合理——在产品达到通用可用阶段(超越开发者圈层的限制)后，再赋予更具指导意义的正式名称。

      回复

      1. 我赞同这种做法。在项目启动阶段使用内部专属的俏皮易记名称，待产品面向用户时，内部名称便成为维基百科上的趣味注脚，而外界看到的则是经过严谨考量的正式名称。

        回复

  153. >每个接触你“有趣”名称的人都要付出微小代价。全行业累积起来，这些代价将形成巨大浪费

    >创意名称应保留给注重品牌形象的终端产品。对于基础设施、工具和库，永远选择清晰易懂。

    啊，我免费赠送的软件必须体谅那些从中榨取价值的可怜风投和商业傀儡们。

    回复

  154. 这简直像个老人对着云彩咆哮，试图说服自己隔壁的草更绿。

    >没有化学家会起床后决定把实验命名为“史蒂夫”，只因史蒂夫是个有趣的名字，他们以为这样能让论文更平易近人。

    这种事每天都在发生。每个科学领域都有技术名称和大众记忆名称。若我提及ENSG00000164690，无人能懂；但若说是刺猬索尼克基因，人们立刻明白——有趣的名字更易铭记。

    > awk(Aho、Weinberger、Kernighan；创作者首字母缩写)

    真想看看有人如何辩解工具名称用创作者首字母能说明功能。除非研究过工具历史，否则根本无从知晓。

    又一篇“我用的工具最棒而你用的垃圾”的论调，偏偏把焦点放在命名而非功能上。

    回复

    1. Windows和macOS在命名方面各自胜出的例子有哪些？

      我一直觉得iOS命名很合理——计算器、备忘录、信息、邮件、健康、时钟、日历、照片、通讯录、地图、设置。这些名称仿佛宣告它们才是标准实现，其他都是第三方应用。

      而在Windows中我们有记事本、画图、终端/命令提示符。Word和Excel已是家喻户晓的名字，很难要求从未听过它们的人描述其功能。但他们确实推出过“Clipchamp”——我个人认为这是个相当愚蠢的程序。

      现代Windows应用命名规范可参考此文：https://windows-11.fandom.com/wiki/List_of_apps

      回复

      1. Windows确实糟糕，但暗黑设计奖非macOS莫属——它充斥着臃肿的服务程序。普通用户难道不该理所当然地认为AppleTV播放视频文件，Apple Music专注播放MP3吗？谁能想到Quicktime才是干扰最小的选择？它被深埋在Automator、3D国际象棋和图形计算器这类晦涩过时的应用堆里——谁都曾误点过这些程序。至少Windows懂得把垃圾应用藏在开始菜单里。

        macOS现在搞得连我父母都用不来。他们用Windows时根本分不清终端和命令提示符，但macOS对他们来说简直是记忆怪兽般的存在。

        回复

  156. 笑死，兄弟，不喜欢？那就分叉项目改个名啊。作者对人类语言科学的理解简直天差地别，难怪他是乔姆斯基信徒。

    经验法则：凡是使用“上下文切换”这个词的帖子，统统忽略。

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：