“Git 就是给那些只会玩技术的人在自己的小圈子里自娱自乐的，根本不是为那些只想把自己事情做完、不搞遗忘的普通人设计的。”3月15日，CoSy 语言的作者 Bob Armstrong 在硅谷 FORTH 兴趣小组的邮件列表中，毫不客气地抛出了对 Git 和 GitHub 的批评。
他在这封回复老友 Ray Cannon 的邮件中，讲述了自己多年前应 Electronic Design 的 William Wang 建议，将 CoSy 放上 GitHub 的经历。然而，亲身使用后，Armstrong 给出的评价是：“它复杂得离谱，又处处受限，完全不如用一个列表语言加上一个开放目录来得直接。”他说，在 SV-FIG 上听了 John Peters 关于 cURL.se 的分享后，自己用简单的单行命令就实现了 wwwGet 和 wwwPut 的动词，结合 CoSy 的词汇体系，在灵活性和可控性上远超 Git 所能提供的。
Armstrong 的目标很明确：他想要的是一个能让自己“不忘记”的工具，而不是一个让技术人员在技术和权限的藩篱中固步自封的系统。他甚至在邮件结尾给出了两个链接：一个是 CoSy 的简约规则介绍，另一个是代码库本身，以此表明一个直接可用的目录结构和语言本身就足以替代 Git 复杂的版本控制和社交功能。
Bob Armstrong 的这番言论迅速在 SV-FIG 邮件组内激起涟漪。次日晚间，此前刚就 CoSy 内部机制（特别是一种继承自 Arthur Whitney 的递归引用计数内存管理方法）做过精彩分享的 Sam Falvo II 回复了这封邮件。Falvo 毫不掩饰自己的不同意见，他追问：“你当初放在 GitHub 上的又是哪个版本？”言下之意，如果真与 GitHub 打交道，就该清楚其生态和规范，而非简单地将其定性为“极客的自留地”。
Falvo 的反驳点在于，将 Git 和 GitHub 等同于复杂和封闭，忽视了它作为全球协作基础设施的一面。他随后进一步指出，相较于自建目录和自制网络 IO 方案，GitHub 提供的代码审查、议题跟踪、持续集成以及开源社区的可见性，是单打独斗式的本地脚本所无法比拟的。对于个人项目或许能用简单工具应付，但一旦涉及多人协作，Git 的分支管理和版本历史追踪就不是“做一个简单列表语言”能取代的。
两封邮件往来之间，折射出开发者生态中长期存在的一条认知断层。一方是追求极致简洁和自控力的系统构建者，相信语言和数学本身足以作为“思维工具”（Tool of Thought），代码库就该像可执行的数学表达式一样精炼、直接；另一方则是现代软件工程的实践者，认同流程、协作和分布式版本控制所带来的实际价值，即便这意味着需要接受一定的学习成本和工具复杂性。
Bob Armstrong 的观点并非孤例。他长期浸润在 APL 和 K 语言的传统中，这一脉络的开创者 Ken Iverson 将数学作为思维工具，强调符号化的精确表达；继承者 Arthur Whitney 又将数组代数简化为列表的列表，并用极简的词汇将其编译到内存空间中。这种“用自扩展的字典来容纳一切表达”的理念，天然倾向于抵制外部工具链的膨胀。对 Armstrong 来说，一个直接可读写的目录、一段足够可编程的网络 IO，就已经覆盖了 90% 的场景，无需引入一个“本质上是内容寻址文件系统”且命令繁琐的 Git。
但在 Sam Falvo 看来，问题没那么简单。安全、审计、协作、备份，这些并不是“简单”能一笔带过的需求。他指出，Bob 所嘲笑的“极客领地”其实正是大量开发者和公司得以在同一套代码上安全工作、追溯变更的基础。Git 的引用模型和 GitHub 的 Pull Request 机制，降低了信息丢失和代码冲突的风险，而这些在个人维护的目录和自制 HTTP 上传脚本中往往是缺失的。
从两人的交锋中，能看出一个更根本的分歧：工具是为人服务，还是为思想服务？Bob Armstrong 站在思想的队列，他的 CoSy 追求的是用数学和语言本身来表达、推演一切，版本管理和网络交互不过是这门语言中几个小小的动词，复杂的外部系统反而让思维变慢。而 Sam Falvo 则站在工程的队列，认为即便是最有思想的个人，最终也需要与其他人交换代码、同步进度，而 Git 所提供的标准化管道恰恰是让协作得以持续运转的“低级基础设施”。
这场小型论战没有输赢。Armstrong 的邮件依然在呼吁人们回归“简单目录+可编程语言”的本源，而 Falvo 的质疑则提醒我们，每一行被人调侃为“极客的自留地”的代码和流程背后，都可能藏着一大群曾被协作混乱折磨过的开发者。两种逻辑的长期共存，也许正是软件世界从不缺少创新动力的原因。
热门跟贴