作者: capita (小明) 站內: CompBook
標題: 對侯捷回應的辨正
時間: Tue Nov 17 17:17:14 1998
※ 引述《jjhou》之銘言：
> ●得魚而忘筌
> 這讓我聯想到我一直鼓勵的「紮根基」學習方式。前不久我在版上
> 貼了一篇 <C++ 的沉迷與愛戀>，曾被網友譏為「老人」的學習方式，
> 並質疑難道學習 Java 也得把 Java virtual machine 搞懂才可以？
> 我的想法是，就拿作業系統的學習而言，為什麼要寫上述那樣一本書呢？
> 我們沒有人想自己寫一個作業系統呀，但是教科書上所說的那些邏輯的、
> 籠統的、抽象的方法，沒有辦法令我們安心。如果能夠拿某個平台的
> 實際作法，與教科書上的一般化概念兩相比對，我們就可以「落袋為安」。
> 特定平台上的技術，雖然不具代表性，卻是一個具體的東西，加強並提昇
> 我們原本模模糊糊的概念，使我們胸有成竹。
> 我要的，便是這種「胸中自有丘壑」的感覺。從基礎知識中受惠的眾多
> 讀者，要的應該也是這種「胸中自有丘壑」的感覺。
我覺得，jjhou 從來沒有搞懂過我說的話，卻總在別的地方批評著，
已經好幾次這樣了。這也是我不喜歡和 jjhou 對話的原因。
上次我的重點是談「倒因為果」的學習方式，事實上，
比較熟悉我的網友應當知道，我對知識深度的重視，恐怕不是其他人可比的。
我所想要表達的，物件導向理論和物件導向實作，不應該用倒因為果的方式來學習。
今天之所以會有人用倒因為果的方式來學習，正是因為有人看不懂理論，
非得要拿實例來學習不可，這是不得已的學習方式，而不是正確的學習方式。
我覺得看理論就很清楚，誰說非得要有實作才能安心?
當年大家學 BASIC 時，誰告訴我們 BASIC 的內部結構了?
但對於只學過機械碼的老老程式員或從電子轉向電腦的人而言，
他可能就需要搞清楚 interpreter 是怎麼做出來的，
不然他不會安心。
正如同我所見到的，現在新學程式設計的人，對於 multithread 是那麼感到自然，
而從來不會覺得有什麼不對，不需要非得把 multithread 的內部實作拿出來才行。
但對從 DOS 時代過渡至今的程式設計者而言，所有的多工形式都可能令他們感到陌生。
就要挖啊挖的，不然就不會安心。
這樣的「不安心」我能理解，但請不要說「非如此不可」。用新的思維方式來學習，
亦有其廣大的思維空間可以發揮，那很可能有許多部分是老人們看不到的。
早年我用 BASIC 的程式產生新的 BASIC 程式併入原程式中執行時，
就讓電腦老師大惑不解過，現在我愛談的 pattern design 、Internet programming
也有很多沒搞懂物件導向的人看不懂，因為他們的思考模式骨子裡還是舊的東西。
無意強調兩者之間的優劣與正確與否，每個人有自己的學習之路，
但請儘量給予思想上的寬容，不要再說不懂那些底層的實作就是「不高明」了。
也許不高明的反而是自己。
對於 jjhou 的處境，我也不是不能諒解。只是不希望有人被誤導了。
而我也只是有時愛說話而已，不然，真的是何必呢，你們玩你們的就好。
以下為原文：
==========================================================
平常候捷的文章我是不回的，我們對新事物的理解能力和方法都差別太大。
但既然講到了程式語言，我非常不希望這樣的觀點一直流傳。
記得在《1984》裡，有一個很重要的觀點，就是「語言決定思想」，
因此為了消滅「錯誤思想」，書中的主角把所有表示「壞」的詞都全部改掉，
不再有 bad 了，只有 good, good plus, good plus plus ...
而這也就是 C++ 的名稱由來之一，可說是 Bjarne Stroustrup 的惡趣味，
在《The Design and Evolution of C++》裡就有提到。
語言決定思想的概念，事實上也是 C++ 被創造出來的原始動機之一，
因為我們不能老是用舊的程式語言實作新的概念。
現在大概已經很少人會用 C 來寫作物件導向程式了吧，
我的兩個朋友分別都在高三很無聊時這麼做過，
其中一個是在 Turbo C 2.0 的時代就想寫物件導向程式，不得不這麼做，
另一個是不滿 C++ 的物件導向能力不足想要自己創造更好的機制，
結果到後來都失敗了，當程式變得過大時實在沒辦法除錯。
我們的確需要新的程式語言。
但如同我們不需要明白每個 I/O 控制的內部機制，
也不需要將所有程式的邏輯用 Turing Machine 表示一樣，
我們也沒有必要將每個物件導向的機制用 imperative language 的方式來思考。
今天不論是 make destructors virtual in base classes 或
never treat arrays polymorphically 都有完整的物件導向思想的解釋，
如果不能學會用物件導向的思考方式來寫作程式，
仍舊沉迷於 C 甚至 x86 的運作邏輯，我甚至可以說，
這樣根本沒學會物件導向，根本不懂 C++ 的原理。
明白這些機制會幫助你在現今的 CPU 架構下寫作更有效率的程式，
或者可以在一些特殊狀況下避開某些編譯程式的錯誤，
而不是倒因為果地用這些內部機制來「學習」物件導向。
事實上，Gnu C++ 的內部機制就和 VC++ 或 BCB 不同，
C++ 作者在 1990 年之前就已一再強調這是 Compiler 的事情，
不是程式語言的事情，到後來大概是講到不想講了，才沒有繼續反覆聲明。
所有的東西都能在程式語言裡找到答案，不需要那些東西。
我十分可以理解老程式員在無法瞭解新語言時的痛苦，
這時用 C++ 內部炫目的機制，的確可以有效吸引他們的關注，
virtual function 不正是 C 語言裡 pointer to function 的高段技巧嗎?
當他們發現到 C++ 更完整地實作他們常用的技巧時，自然是眉開眼笑一掃陰霾。
這在我大一時 (差不多是 1991 年) 也發生過這種事，
因為 compiler 的 bug, 在信心不足的情況下，我逐個機器碼去 trace 程式，
才相信 C++ compiler 並沒用到我不能理解的技巧，
virtual function 也沒什麼了不起的地方，於是才安心下來。
但我真的要說，這只是一種過渡，這樣子不叫懂 C++，
這樣離真正懂得物件導向、並懂得 C++ 的設計內涵，還有很大的距離。
更重要的是，這樣的權宜之計不能變成學習新程式語言必經的歷程。
如果還要用這樣的觀點去學 Java ，恐怕會痛苦萬分，
大家都輕鬆自在地寫 Java 程式時，這些人只怕還在 JVM 裡鑽不出來。
還好現在流行的網路程式語言不是 Effiel ，
現在也不流行把程式碼當參數直接塞進模組裡的功能 (first-class function)，
不然只怕這些人全都會因為腦袋轉不過來而死光光。
要學好一個新語言，就要學會用它來思考，要是人家問你 "How are you?"
你還得一個一個字地翻譯成中文才能想到回答，
再一個一個字翻成英文並套用文法，最後才能告訴對方，
你也別想自己去跟外國人談生意了。
小孩子學英語跟老人學英語是不一樣的，別用老人學英文的方式教小孩子學英文，
同樣的，也請不要用老人的方式教孩子們學 C++ 。
============================================================
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: pc5.adsl936.tku.edu.tw
※ X-Info: Mave -> ric.bbs@ptt.csie.ntu.edu.tw
※ X-Sign: 0ROABM6PHudohbU3fWV2 (99/07/09 7:05:42 )