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，令人期待。
