日本程序員的技術品位真的很好嗎？

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）

0 1

濱野純從東京大學畢業后進入了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 哲學一樣，少而精，組合強大。

0 2

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腳本一樣簡單。

0 3

濱野純和松本行弘技術品位極佳，但是他們并不能代表日本程序員，我搜了一下，發現起源于日本/日本程序員主導的知名開源軟件并不多，遠遠比不上中國，有知道日本開源軟件詳情的朋友歡迎告知。

不管如何，我們都能看到技術品位的巨大力量，對好設計的追求，對簡潔的追求，會讓軟件具備長久的生命力，而這一點，是人工智能很難做到的。

無論你是程序員，還是未來的軟件架構師，學會欣賞并培養這種“好品位”，才是走向卓越的必經之路。

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