Delphi斷想
榮耀2002秋
Delphi是迄今為止口碑最好的RAD（Rapid application Development）產品。
Delphi 3.0是Delphi系列中劃時代的版本，成熟穩定的Delphi 5.0更鞏固了Delphi企業級開發工具的領先地位。
Delphi 4.0是印像中最惡劣的一個版本。打了這個補丁，那個程式無法正常編譯；打了那個補丁，這個程式無法正常編譯。當然了，Delphi不會存在明顯的bug的，除非你的程式規模夠大，複雜度夠高。
對企業軟體開發人員來說，Delphi的MIDAS技術具有劃時代的意義。在今天微軟.NET中，仍然可以看到它的影子。
Delphi的Active Form是一項令人大開眼界的技術。它的優點是，你不需要什麼特別的Web知識，就很容易將現有Windows項目包裝為Active Form，只需添加短短幾行程式碼，即可將其展現於瀏覽器之中。進入了IE，也就免去了客戶端維護成本。這種技術的表現力也遠比asp豐富。但它也有一個致命的缺點：它太笨重了，只適合運行在高速區域網路裡。
在電力系統中普及面較廣的財務軟體，就是採用這種技術。沒有最好的技術，只有最適合的技術，Delphi的Active Form技術用在這種地方，再合適也不過。
要想把這種技術用在廣域網路中，或是低速區域網路內，那簡直是一種惡夢。
Object Pascal是我所喜歡的最優雅的語言之一。既傳統，又現代；既簡單清晰，又功能強大；程式碼可讀性好，又不像Visual Basic程式看起來那麼呆板。更重要的是，類似C++，它也支援多種程式設計風格。
三年前，如果你開發資料庫相關軟體，但又不想使用腳本性的語言，或是什麼專用的開發工具（例如Oracle公司的Developer 2000），你希望使用一個由真正物件導向語言驅動的開發工具，那Delphi就是最佳選擇。
Delphi的設計者意識到了絕大部分軟體都要和資料庫打交道，從而加入了對資料庫相關開發功能的強力支持，這種決策是極其明智的。正是這種對資料庫開發的強力支持，導致Delphi取得了巨大的成功。
Delphi對資料庫的強力支持，達到、甚至超過了一些專門的資料庫開發工具。但這也容易讓一些外行人誤解，以為Delphi只是一種資料庫開發工具。
我還記得幾年前，南京新街口新華書店裡赫然擺放著一本書，它有一個很有趣的名字：《關係型資料庫：Delphi》（我記不太清楚了，但大差不差）。
Borland似乎過於注重IDE（Intergrated Development Environment）的功能開發了，它本來可以進一步改善Object Pascal語言質量，一些本該出現於Object Pascal中的語言特性，現在進入了C#，個中原因，無需贅言。
Delphi並沒有包裝所有的Windows API，例如某些COM相關的API，這也是我放棄Delphi的原因之一。
RAD開發環境，對於企業級專案軟體開發來說，絕對不可或缺。 RAD降低了軟體開發的門檻，RAD也「創造」了一大批半調子程式設計師。我懷疑對RAD工具的誤解與偏見，就起因於這些半調子程式設計師。
最新版本的Delphi，總是會帶來一些最新的技術，有時這些技術對微軟來說還只是一個概念，而Borland已經把它變成了產品。但Delphi的最新技術，有時只能算是一種過渡性的技術。
儘管Delphi 6.0對資料存取、Web、xml都有大力改善和支持，但在我看來，Delphi 6.0不過是一個過渡版本而已。
Delphi的BDE（Borland Database Engine）資料存取技術，提供了對ODBC資料來源的完整支持，又打擊了ODBC，這種技術在Delphi 3.0中達到巔峰。 Delphi的MIDAS技術，提供了n-tier資料存取技術，但仍建立於BDE之上。 Delphi 5.0提供了ADO的完整支持，並有放棄BDE的架勢。 Delphi 6.0的dbExPRess和DataSnap技術是Borland對資料存取技術不斷創新的又一例證。
但是，即使在BDE達到鼎盛時期，即使在今天有了那麼多資料庫存取技術，潮起潮落，ODBC的地位，仍然不可取代。除了直接呼叫資料庫專用API（例如Oracle的OO4O）外，還沒有哪一種資料存取技術的效率，可以達到或接近ODBC API。
微軟就是Windows平台上事實上的標準，遺留程式碼（legacy code）的強大勢力往往也超乎任何人的想像。
VCL（Visual Component Library）控制項和ActiveX控制項完全是兩碼事。 ActiveX控制項目標於跨語言的二進位重複使用，而VCL控制項則是目標於Borland開發環境內的元件重複使用，重複使用的層面可以是目標文件，也可以是原始碼，這其實更像C++的類別重用，比如說MFC （Microsoft Foundation Classes）的類別重複使用。
用慣了VCL控制的程式設計師，對於需要單獨發布、註冊ActiveX控制項感到厭煩；用慣了ActiveX控制項的人，對於Delphi把什麼東西都編譯到一個大檔案裡感到好笑。
Delphi的運行時BPL（Borland package library），其實就是一種特殊的DLL，你可以認為它們是Borland格式的DLL。如果你想讓程式尺寸變小，如果你同時要發布數個使用了同樣BPL的程序，使用運行時BPL，它可以使你心想事成。
Delphi對於版本自動增加功能的方便支持，使得Delphi程式設計師對於Visual C++需要手動修改版本號，感到奇怪。 RAD和非RAD的差異，由此可見一斑。
Delphi模式被成功地克隆到了C++Builder身上，但直到目前為止，C++Builder中的技術，一般仍或多或少地滯後於Delphi中的最新版本的技術，但願這種狀況能夠盡快得到改善。
Delphi和C++Builder使用了同樣的後端，但Borland並沒有從一開始就把這兩種語言整合到一個Studio之類的整合開發環境之中，從而可以同樣的風格（乃至功能）的IDE支持不同口味的語言為促銷賣點，讓我不解。我懷疑這要不是決策失誤，就是暗示了Borland缺乏足夠的資源。
對於那些從事企業軟體開發同時又迷戀C++的程式設計師來說，C++Builder無疑是他們的寵兒:)
如果你是一名Delphi程式設計師，如果你熟悉C#，你就會明白，除了C#採用了C/C++風格的語法之外，並且，撇開許多人都說C#是java的克隆不談，C#從Delphi中，借鑒了大量的語言設計思想。
我相信，Anders Hejlsberg在設計C#語言時，首先會本能地想到Object Pascal，而不是Java。看看C#的單實作、多介面繼承的物件導向的實作；看看try/catch/finally異常處理結構（我知道很多人會說，這些都來自Java）；看看屬性（propery）的概念（我知道有人會說，這來自Visual Basic）；看看那個override關鍵字… 幾乎可以斷定，這一切首先都來自Object Pascal。
毋庸置疑，Delphi必須支援.NET。
在.NET平台開發工具領域能夠與微軟Visual Studio .NET一較高下的，目前也只有Delphi具有這個實力。
在Windows平台上，總是有人不喜歡微軟，但這些人中的大部分還是要前進到.NET，Delphi .NET就是一個理想的替代品。
Delphi .NET，令人期待。