懷璧其罪 RAD

侯捷 1999/01/26


●讀者來信 & 我的回覆

> 候老師 您好! 第一次寫信給您,還真怕您嫌我的問題太無聊了。
> 如果您回了我的信,我一定會比上次收到Bjarne Stroustrup的
> 回信還要高興...
  

觀念性的問題我幾乎都會回的。技術性問題就不一定,有時翻箱倒櫃找答案挺累人。

印象裡百家姓中沒有「候」這個姓喔 :)

> 我原本是一個一天到晚使用RAD工具的人,對於微軟的Visual Basic
> 情有獨鍾,但是歷經了三個版本之後,我有一種被騙的感覺,
> 因為處在這個環境中,似乎是投身在別人設好的一個圈套裡!
> 這種東西會讓人對於『了解 OS 內部運作以及各種規範與協定的
> 基礎層面』的慾望慢慢減低至零。今天為了突破某一個元件的
> 限制而自己寫了一個元件,明天 VB 新版的內附元件就出現了比自己
> 寫得還要好的東西。到了最後,自己不想寫,只想等別人寫給你
> (反正怎麼寫也不會比人家寫的好!);要是別人不寫,你就
> 徹頭徹尾地喪失了一項能力...(天曉得要等到何年何月),
> 要不然就是官方給的元件功能少東少西. 不只這些!最讓我
> 受不了的是,我竟然發現:程式用這種方式去寫,簡直就比用
> Office 還要簡單,深入的思考幾乎是零...。   
> 其實在所有程式語言裡,我最喜歡的是 C!只是初接觸 Windows 時,
> 心想快一點兒能 "有所作為",所以從了VB這一條路...。沒想到
> 這一踏進去,就花了我好幾年的時間!一開始嘗盡甜頭,越到後來
> 越覺不快(根本就是不爽!)。  
 

任何一種語言,任何一個工具,都有它的擅長與不擅長。從信中知道你比較喜歡「了解 OS 內部運作以及各種規範與協定的基礎層面」,也就是比較喜歡「做學問」,因此對 VB 的 programming 方式(乃至於所有的RAD 工具)產生了反感。

但是我想說兩點:

1. RAD 並非罪惡,而是優點。要怎麼用它則是 developer 自己的問題。侯捷對於 RAD 工具如 Visual Basic 或 Delphi 或 C++Builder 並不擅長,但我知道 Visual Basic 可以呼叫 Windows API,做相對低階的動作;當然,以軟體工程角度來看,VB 是比較弱,因為它不具 OO 特性。至於 Delphi,我有兩位這方面的專家朋友(wolfgang 和 xshadow),他們可以使用 Delphi 做任何事情,沒有任何你想像中 RAD「該有」的限制;C++Builder 和 Delphi 系出同門,一樣沒有什麼限制。

2. 如果「寫一個程式,比使用 Office 還要簡單,深入的思考幾乎是零」,其實不是壞事。大家都能夠隨手寫個小程式解決手邊幾個小問題,是為component software 以及 RAD 的大貢獻。其實你的形容太誇張了啦,目前的 RAD 應該還不至美好到「寫一個程式,比使用 Office 還要簡單」,總還要有些程式邏輯和程式語言的基本訓練。真到了你說的那一天,我覺得是件好事而不是壞事。只不過,那樣子完成的程式,都需藉助現成的 components;如果你要突破現成的框框,當然你就得有更深的功力。無論如何,RAD 應該不會是你的絆腳石。

以下引一段我在【汗如雨下.雜感.1998/11】的文章片段:

●關於 RAD(Rapid Application Development)

《Delphi 學習筆記》作者錢達智先生,是我的好友。我們之間對於 RAD 有段討論,或許你想聽。

■侯:BBS/News 上時有關於 RAD 的工具見解。我認為你很夠資格說些話。不少人對 RAD 有誤解。如果你能點醒大家 :

(1) RAD 是很好的開發工具
(2) 使用 RAD 並不代表不需要底層紮實的基礎,

那麼誤解的人就會比較少一點,知道該怎麼做的人就會比較多一點。

■錢:過去在 DelphiChat、NEWS Group 以及我的書中,這樣的想法都不只一次宣揚過。

其實,就我接觸過的人,不論是網路或者是學生,RAD的使用者的確是比較急功近利,也難怪會有這樣的刻板印象。 :(

雖然說過,但還是要持續宣揚這種理念,就如大哥說的,誤解的人會少一點,知道該怎麼做的人就會比較多一點。


在【汗如雨下.雜感.1998/11】一文中對 RAD 有更多的討論,或許你可以參考。

RAD 真是「匹夫無罪,懷璧其罪」呀。

> 在「天瓏」看到了您對物件導向的諸多精闢解說,我心想:
> 這才是我要的!這才是正途!該是我抽身的時候了!
> 於是我又重拾了 C 與 C++ 的研讀. 我的 SDK 基礎目前很差
> 但是,為了能夠讀解您的大作,
> 我幾乎是買足了所有關於 Windows 在 C 和 C++ 上的書(尤其是
> 您的著、譯作品),現在的我正卯足了全力研讀 Charles Petzold 的
> Programming Windows 95!不過,這個過程裡在工具的使用上,
> 我有幾個大疑點,想請您撥冗為我解答:
>
> 一、以SDK方式寫成的一個程式,在編譯器的選擇上,是否只有
> Visual C++可以使用?還是另有一套專門用於 SDK 的編譯環境?
> (我在Jeffry Richter的書中看到有所謂的『 Win32 SDK Header Files』...)
> 如果有,那麼我該如何取得這一個編譯環境呢
> (何處可Down Load 還是要用買的?


的確,除了 Visual C++ 之外,另有所謂的 SDK 開發工具(Win95 SDK, WinNT SDK)。這些東西可在 MSDN level2 中獲得(MSDN 要用買的)。不過,任何一套宣稱「Windows 平台上的 C/C++ 編譯器」,都可以吃 SDK style 程式,例如 VC、BCB、Watcom C++。所以你其實不需要 SDK。印象中只有非常特殊的、比較晚近發明的 API,才可能會「先」出現在 SDK 上(隨後便可能在新版的 VC 上出現)。

Jeffry Richter 書中所謂的 Win32 SDK Header Files 指的是\VC\INCLUDE\ 下的傳統 SDK include files (而非 \VC\MFC\INCLUDE 下的 MFC include files)。這些所謂的 SDK Header Files 你都可以在 VC 中獲得。所以,Jeffry Richter 書中所有程式都可在 VC 環境中 build 出來。

> 二、若想造出一個純正的 OS 原生執行檔,而不需要其它的
> RunTime VM,
> 是不是一定要以 SDK 的方式來寫?(我指的是Microsoft自家 Solution)


"Runtime VM" 是 VB 和 Java 的觀念。Java VM 我懂,VB's VM 我其實不懂。不過,回到你的問題,你所謂「純正的 OS 原生執行檔」,究竟是什麼意思?如果你是指一個不需任何附件就可執行的 .EXE,那麼,任何 C/C++ 編譯器所做的可執行檔,都是這種性質(我們稱為portable executable file format;PE 檔案格式),當然,執行時必要的DLL 必須存在。

> 我並不是科班出身的人,基於一股對 Programming 的熱愛,靠著
> 多年的自修與磨練,現在我能和很多科班出身的人平起平坐,
> 這一條路不甚好走,但我終也不會放棄! 我極力地追上所有
> 走過「正途」的人,更謝謝您指示了我重生的路
> 一個想好好寫程式的人


出了社會,便會發現,求職、工作、發展,和科不科班沒有關係,和實不實力才有關係。科班只不過是向別人展現「我曾經受過怎樣怎樣的訓練」。

非科班的人一路走來當然稍微辛苦一點,受到的委屈也可能比較多一點,不過,走在自己的興趣上,到底是人生最美好的一件事。

good luck to you.

--- the end