日本程序员的技术品位真的很好吗？

2005年4月7日，“闭关”一周的Linus上传了一个不起眼的小工具。

在注释中，Linus把它称为“the information manager from hell”。

它就是Git 0.0.1，此时只有不到1000行的C代码：

这些代码被编译成7个单独的可执行命令：init-db、update-cache、show-diff、write-tree、read-tree、commit-tree、cat-file

现在看看这些命令，你可能会好奇，这是那个名扬天下的Git吗？

clone命令在哪儿？add命令在哪儿？

在软件工程中，有个叫做“管道和瓷器”的比喻，管道指的是底层基础设施，低级的API，通常比较原始，不美观。

瓷器表示高级功能，友好的界面，例如如洗手池，用户直接使用它，不用看到管道里复杂的水流。

此时的Git0.0.1就是典型的“管道”，使用起来非常麻烦。

但是Linus在开源界影响力无与伦比，他一发布Git，就立刻引发了热烈的讨论。

尤其是那些想参与开源，想在开源中留名的年轻人，其中一位就是日本人滨野纯（Junio Hamano）

01

滨野纯从东京大学毕业后进入了Twin Sun公司，这家美国外企是个“神仙”公司，竟然采取远程优先的工作模式。

后来公司在洛杉矶有个小项目，滨野纯被派去了美国，在这里他遇到了一位导师Paul Eggert。

Paul是开源领域的著名人物，时间区数据库（TZDB）维护者，GNU项目的长期贡献者，在他的影响下，滨野纯走上了开源和自由软件的道路。

就是在这个时候，滨野纯看到Linus公布了Git，他立刻就下载了源代码，不到一千行代码！花两个小时就看完了！

这对于那些想参与开源的人，真是一个幸福的时刻。

因为很多开源软件成名以后，规模非常庞大，想把代码读一遍都很难，要参与进去做贡献非常麻烦，只能从提个issue，fix个Bug开始。

但是Git不同，初始版本就在眼前，1000行代码，了无秘密，何况还是自己的偶像Linus写的，设计简洁，代码清晰。

此时不加入，更待何时？ 

当然，事情都有两面性，越是开源项目的早期，对人的要求就越高。

比如Linus在邮件列表中提了一个需求：用脚本语言实现Merge功能（没错，Git0.0.1还没有实现merge）。

可是几天过去了，没人响应。

滨野纯出手了，他用Perl写了一个Merge实现，发到了邮件列表。

Linus看到后很兴奋：这正是我想要的..... 于是两人就在邮件列表中不断地讨论，修改代码，最终找到了一个优雅的方案来实现Merge。

和自己的偶像一起工作，开发开源软件，这种感觉肯定是无与伦比的。

滨野纯在Twin Sun公司有自己的日常工作，刚开始的时候，他主要在早上上班之前，以及下班之后和周末来进行Git相关的开发，后来他发现自己的办公室隔间没人能偷看，在白天也可以“偷摸”着干点儿Git的活儿。

（其实滨野纯的公司Twin Sun也很开明，后来NEC一起赞助滨野纯用20%的工作时间，兼职开发Git。）

滨野纯对Git的贡献越来越多，他逐渐赢得了Linus和整个社区的信任，仅仅三个月以后，Linus就宣布将Git维护者移交给滨野纯。

这个过程看起来一帆风顺，似乎只要你用心投入时间开发就可以，实际上并不是这样的。

当时有很多优秀的程序员在参与开发，不少还是从Linux内核社区过来的。

对同一个功能，可能有多个竞争者同时在设计和开发，滨野纯的设计要精良，代码要漂亮。

开发速度不但要快，还得能很好地给竞争者展示出来，说服别人。

所以，开发的过程就像一场混乱的竞争，滨野纯能胜出，关键的原因就是Linus所说的：

“有明显的、非常重要但难以具体描述的‘好品位’”

“这样的人虽然稀有，但你一眼就能认出来。我觉得自己最大的成功之一，其实发生在 Linux 之外：那就是我找到了滨野纯来维护Git项目。”

滨野纯也没有辜负Linus的信任，成为维护者后，一干就是20年，带领Git成为世界上最流行的版本控制软件。

那什么是“好品位”呢？ 我觉得至少有两点：

1.能分辨什么是好设计，什么是坏设计

2.懂得取舍和简洁

比如Git，核心的数据结构只有四种：Blob、Tree、Commit、Tag。

这四者加上哈希引用，居然就能表达整个历史树！

设计极度简洁，但威力无穷。

这和 UNIX 哲学一样，少而精，组合强大。

02

Linus夸滨野纯技术品位好，不由得让我想起另外一位更加知名的日本程序员：松本行弘。

松本行弘是Ruby之父，在设计Ruby的过程中展示了极佳的技术品位。

1. 平衡“灵活”与“可控”

Ruby以动态性和元编程能力著称，但松本行弘在设计中刻意规避了某些过度自由的特性（如Lisp风格的宏），以避免代码可读性崩溃。

他很克制，拒绝完全开放语法，但提供了attr_accessor等元编程工具，这就让Ruby代码既灵活，又不会因过度自由而失控。

2. 面向对象的纯粹性与实用性

Ruby将Smalltalk的面向对象思想推向极致，同时解决实际痛点：

一切皆对象：包括基本类型（如1.class #=> Integer），实现概念一致性。

Mix-in优于多重继承：通过module实现功能组合，避免C++多重继承的复杂性。

3. 函数式特性的优雅融合

Ruby并非函数式语言，但巧妙吸收了高阶函数和闭包：

代码块（Block）：

- 受Lisp启发，但通过do...end/{}语法更符合命令式语言习惯。

- 实现迭代器（如each）和回调（如File.open的自动资源释放）。

链式数据流：map/select/reduce组合操作时，代码如自然语言般流畅。

所以使用Ruby编程，给人的感觉特别舒服，代码非常优雅，后来也随着Ruby on Rails的东风而大爆。

松本行弘后来曾尝试设计一种基于流模型的并发编程语言，名为 Streem，旨在将数据流编程的理念引入更广泛的应用场景，其核心思想是通过管道连接多个任务，实现数据的流动与转换。

比如这个例子：生成 1 到 100 的序列，每个数乘以 2 后输出。

seq(100) | map { x -> x * 2 } | stdout

还有这个：Streem 自动将任务分配到多线程，无需手动管理：

fread("large_file.txt") | map { line -> process(line) } | fwrite("output.txt")

都是把流式编程变得像写shell脚本一样简单。

03

滨野纯和松本行弘技术品位极佳，但是他们并不能代表日本程序员，我搜了一下，发现起源于日本/日本程序员主导的知名开源软件并不多，远远比不上中国，有知道日本开源软件详情的朋友欢迎告知。

不管如何，我们都能看到技术品位的巨大力量，对好设计的追求，对简洁的追求，会让软件具备长久的生命力，而这一点，是人工智能很难做到的。

无论你是程序员，还是未来的软件架构师，学会欣赏并培养这种“好品位”，才是走向卓越的必经之路。

Git 0.0.1 下载：https://www.kernel.org/pub/software/scm/git/