這是之前一篇短文的後續，內容主要是該短文所評論的書籍的作者寫給我的信，以及我的回應。
去年 (2024) 十月，我寫了一篇短文：〈My hot take on "Five Lines of Code"〉，分享了我對該書部分內容的個人看法。上個星期，我從我的臉書專頁發現有一則新的私訊，是該書作者 Christian Clausen 發過來的。
Clausen 先生非常客氣而且仔細地針對我那篇短文的幾個看法做出了回應。以下照登來函（沒有遺漏和修改，且徵得對方同意），中文的部分是翻譯和我的回應。
Hi Huan-Lin,
I just stumbled upon your blog post about my book, Five Lines of Code. I think you raise some great points. And I especially appreciate how polite your rebuttal is. Thank you for that. I would like to clarify a couple of things, if I may.
翻譯： 我碰巧看到你的部落格文章提及我的書《Five Lines of Code》。我覺得你提出了很棒的觀點，而且我特別感謝你回應時的禮貌。謝謝你。我想澄清幾件事，如果可以的話。
About the Five Lines rule
You say it is too rigid. I agree. In the form you present it it is too rigid. However, the very next line in the book (unfortunately missing in your screenshot) is:
翻譯： 你說它太死板了。我同意。以你呈現的形式來看，確實太死板了。不過，書中緊接著的一句話（可惜你的截圖中沒有）是：
The specific limit is less important than having a limit. In my experience, it works to set the limit to whatever value is required to implement a pass through your fundamental data structure.
翻譯： 具體的限制本身並不那麼重要，重要的是要有一個限制。依我的經驗，只要這個限制足以讓你完成對核心資料結構的一次遍歷，那就夠了。
I make a point of repeating as often as I can that, no rule is universal nor a replacement for common sense. A good way to think of my rules is as defaults. If you don't know how long a method should be, it is probably safe to go with five.
翻譯： 我經常強調，沒有任何規則是普遍適用的，也無法取代常識。將我的規則視為預設規範是一個不錯的思考方式。如果你不知道一個方法應該有多長，選擇五行通常是安全的。
Another dimension of the rules is impossible to know without reading the book. They work together. And this brings me to me second point.
翻譯： 規則的另一個層面，若不閱讀書本是無法了解的。它們是相互配合的。這也引出了我的第二點。
"Going in the wrong direction"
You write "the direction is wrong from the beginning." I understand why it seems wrong. Humans have an instinctive preference for brevity. In the screenshot you show I am adding a lot of verbosity. However, in order to improve we first need to make room for maneuvering. It's like a mechanic taking an engine apart in order to fix it -- which also requires a lot more space. You wouldn't judge an engine repair by how it works in the middle. The same applies here. You need to judge the final product.
翻譯： 你寫道「方向從一開始就是錯的」。我理解為什麼看起來像是錯的。人類本能偏好簡潔。在你展示的截圖中，我加入了很多冗長的部分。然而，為了改進，我們首先需要留出操作空間。這就像機械師拆解引擎來修理——這同樣需要更多的空間。你不會根據引擎拆解過程中的狀態來評斷修理的好壞。這裡也是一樣，你需要評斷最終的成品。
HSL conversion in Five Lines
You also pose a challenge, which I love: How would you refactor the rgbToHsl function into this style, without making it less clear?
翻譯： 你也提出了一個我很喜歡的挑戰：你會如何將 rgbToHsl 函式重構成這種風格，而不讓它變得不清楚？
Challenge accepted. Of course we cannot eliminate the ifs, since their context is number which is not a type we control.
翻譯： 挑戰接受。當然我們無法消除 if 判斷，因為它們的上下文是 number ，而這不是我們能控制的類型。
type MyColor = { r: number; g: number; b: number };
type MyRange = { min: number; max: number };
function calcHRotation(c: MyColor, r: MyRange) {
if (r.max === r.min) return 0;
else if (r.max === c.r) return (c.g - c.b) / (r.max - r.min);
else if (r.max === c.g) return 2 + (c.b - c.r) / (r.max - r.min);
else if (r.max === c.b) return 4 + (c.r - c.g) / (r.max - r.min);
throw "Impossible";
}
function calcH(c: MyColor, r: MyRange) {
return (calcHRotation(c, r) * 60 + 360) % 360;
}
function calcL(r: MyRange) {
return (r.min + r.max) / 2;
}
function calcS(l: number, r: MyRange) {
if (r.min === r.max) return 0;
else if (l < 0.5) return (r.max - r.min) / (r.max + r.min);
else return (r.max - r.min) / (2 - r.max - r.min);
}
function rgb2hsl_internal(c: MyColor, r: MyRange) {
const h = calcH(c, r);
const l = calcL(r);
const s = calcS(l, r);
return { h, s, l };
}
function rgb2hsl_float(r: number, g: number, b: number) {
const min = Math.min(r, g, b);
const max = Math.max(r, g, b);
return rgb2hsl_internal({ r, g, b }, { min, max });
}
function rgb2hsl_int(r: number, g: number, b: number) {
return rgb2hsl_float(r / 255, g / 255, b / 255);
}
export function rgb2hsl(r: number, g: number, b: number) {
return rgb2hsl_int(r, g, b);
}
In my opinion, this significantly easier to read, wouldn't you agree?
翻譯： 依我看，這樣讀起來明顯更簡單，你不覺得嗎？
我的回應： 這樣拆解函式的方式出乎我意料，而且每個函式真的在 5 行以內，實在佩服。至於這樣的寫法是否更好或更簡單，我心中仍有一些猶豫不決，得再想想。（有可能一部份是我的自尊心作祟）
I'm not an idealist
You write "Christian Clausen might be an idealist." I am sad that I have given you this impression, because I am through-and-through a pragmatist. I love distilling ideas and exploring academic topics. In practice thought, I am not idealistic. The rules are tool for learning. When you don't understand something you have to follow its instructions vigilantly, since you don't know what is essential. Then as your understanding deepens you can begin to experiment with the boundaries. When you finally master something, you don't need to follow anything, because you'll have internalized its intentions rather than its text.
翻譯： 你寫道「Christian Clausen 可能是個理想主義者。」我很遺憾讓你有這樣的印象，因為我完全是個務實主義者。我喜歡提煉想法並探索學術議題。在實際思考中，我並不理想主義。規則是學習的工具。當你不理解某件事時，你必須謹慎遵循其指示，因為你不知道什麼是關鍵。隨著理解加深，你就可以開始嘗試突破界限。當你最終掌握某件事時，你不需要再遵循任何規則，因為你已經內化了它的意圖，而非文字。
我的回應： 原來作者是務實主義者，這跟我當初的想像不大一樣。我承認當時的評語有些主觀和片面，這點確實該自我檢討。下次撰寫個人評論時，我會更謹慎地區分印象與事實。
You write:
- "beginners may be distracted by these rules before they can even write a functioning program."
I agree! Which is why I always state that my book is for after you've learned to program.
「初學者可能會被這些規則分心，甚至都還沒寫出可運作的程式。」
我同意！這也是為什麼我總是說我的書是給已經學會程式設計的人看的。 - "They should have implemented the features that the client wants first."
Agree. Whenever I teach (and in my team) we practice the mantra: First make it work, then make it better.
「他們應該先實作客戶想要的功能。」
同意。無論是我教學時（或在我的團隊中），我們都奉行這句格言：先讓它能運作，再讓它更好。 - "if someone brings up this rule during a code review and asks to make the else clause disappear, otherwise the pull request cannot be merged, it will probably turn into a disaster."
I agree: Asynchronous code reviews are a disaster! I think everybody should do synchronous code reviews, in the form of Strong-Style Pairing. This is also explained in detail in the book.
「如果有人在程式碼審查時提出這條規則，並要求消除 else 子句，否則無法合併 pull request，這很可能會變成災難。」
我同意：非同步的程式碼審查就是災難！我認為每個人都應該進行同步程式碼審查，以強式配對（Strong-Style Pairing）的形式進行。這點在書中也有詳細說明。 - "Look how beautiful my code is! It conforms to a certain dogma."
In the final chapter I state the same thing. The rules should boost collaboration, never diminish it. Dogmatism diminishes collaboration.
「看我程式碼這樣寫多漂亮啊！多符合某個教條規則。」
在最後一章我也說過同樣的話。規則應該促進合作，絕不該削弱合作。教條主義會削弱合作。
All in all, I think we agree about most things. I think you might even enjoy the book if suspend your disbelief for a bit, and go in with an open mind. Really, I just wanted to thank you for the fun little refactoring challenge, and for caring. I don't get offended, I just love seeing people being passionate about programming, like I am.
翻譯： 總的來說，我想我們大多數觀點是一致的。我覺得如果你能暫時放下懷疑，以開放的心態閱讀這本書，甚至會喜歡它。真的，我只是想感謝你帶來這個有趣的小重構挑戰，還有你的關心。我不會被冒犯，我只是喜歡看到人們像我一樣對程式設計充滿熱情。
Kindest regards
Christian
結語
回想起來，我在寫上一篇筆記時，確實帶著一些不吐不快的心情，也坦白說明我並未讀完整本書，故並非全盤否定整本書的價值。儘管如此，若今天角色互換，我可能很難像 Clausen 先生那樣理性且彬彬有禮的回應。因此我也很感謝他，願意花時間寫那則訊息，讓我更了解他的想法。
從他的回應與書中內容來看，也能感受到他對於追求簡潔程式碼的熱情。我想這點是無庸置疑的。
先寫到這裡吧。再次感謝 Clausen 先生的回應。（也感謝你的關注）
Keep learning!
沒有留言: