Delphi 浴火重生, 火猴的逆襲已經來臨

楔子

自 FireMonkey 推出以來, 漸漸燃起了從 2000 年以來這十年間, Delphi 程式人員對於 Delphi 的信心。從 2000 年 Anders Hejlsberg 琵琶別抱, 為微軟量身訂做了.NET 平台與 C# 程式語言之後, Delphi 的聲勢江河日下, 再加上 Borland 的策略失準, 以行銷為導向, 失卻了 2000年以前 Delphi 所自豪的穩定性與效能, 曾被稱為 VB Killer (VB 殺手) 的 Delphi, 在 2000-2010這個十年之間, 完全失去了主要程式開發工具的地位。

然而, 在歐洲各地的 Programmer 們並沒有受到 Delphi 崩壞的影響, 在俄羅斯、義大利、法國，Delphi 在程式開發的這個圈圈裡, 仍舊有許許多多的人在努力著, 從 2001 (年份我可能記得不清楚了) 的 Delphi 8, 到之後的 Delphi 2005, 2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, 到 2014 年的 XE6, 各式各樣功能的第三方 VCL 元件不斷在全世界被創造、散佈，使用在各種場合與應用裡.

Tnt 元件

在 Delphi 2009 發佈之前, 所有 Delphi 的元件與 IDE 並沒有支援 Unicode 的字元, 也因此從 Delphi 5 開始, 就有兩三種內建的工具讓程式開發人員可以製作出 Resource 檔案, 用來儲存 Form 當中的各種多國語言的內容, 然而, Unicode 才是王道, 沒有 Unicode, 多國語系真的是個遙不可及的夢想。

Tnt系列元件, 是提供尚未支援 Unicode 的版本的 Delphi (Delphi 2009 以前的所有版本)對應的 VCL, 從 TLabel, TEdit, 到 BDE 的絕大多數元件, 都有對應的 Unicode 版本元件, 對應上來就是 TtntLabel, TtntEdit 等等。

在提供多國語系的應用程式上, 或者處理跨國企業的資料庫時, 都對程式人員提供了非常多的幫助, 感謝 Tnt 元件的開發者.

Indy 網路元件組

從 1999 年的 WinShoes, 到 2000 年開始的 Indy 7, Indy 8, 一直到目前搭載在 Delphi XE5 的 Indy 10.60, Indy 陪伴著 Delphi 開發人員走過了將近 20 個年頭, 從 Client, Server, Protocol, 各式各樣的功能, 讓開發人員處理網路相關的程式功能更不費力.

目前 Delphi XE5 當中的很多官方元件, 例如 DBX 系列元件的底層, 也都是以 Indy 作為其基礎, 因此如果我們遇到 DBX 系列元件發生了什麼問題, 也就可以從 Delphi 內附的 RTL 或 VCL 程式原始碼來抓出到底是那兒出了問題.

跨平台的努力-FireMonkey

從 Delphi 2009 把 Unicode 功能完完整整, 裡裡外外的融入了 Delphi 的 IDE, 編譯器以後, 我們現在已經可以在程式裡面用中文變數, 甚至各國文字作為變數, 要怎麼處理多國語系, 都不是問題.

但 2009 年的時空, 已經不是 Windows 桌面應用程式的天下, 就連網頁程式也已經是小學生就能提供的東西, 因此, Delphi 的下一版, 除了把 64 bit 編譯器做出來, 讓效能能夠更好, 接著就是朝向跨平台的目標前進.

在 1993-1995年間, JAVA 的概念與程式標準開始被 SUN 提出, 每個新的產品都有其行銷的口號, JAVA 當時的口號就是: Once Compile for All Platforms. (編譯一次, 所有平台都可用)

這個口號非常美好, 但大家可以在後來的桌面應用程式跟網頁程式當中得知, 這個口號又是另一個夢幻泡影. (如露亦如電, 應作如是觀 - 引述自金剛經)

JAVA 的 Once Compile for All Platforms, 是奠基在『所有硬體設備上面都會提供有 JAVA 虛擬機器 (本文後將簡稱為 JAVA VM)』的這個前提假設上, 然而, 並非每個硬體設備都有 JAVA VM, 且當時設計這個概念的人也沒想到 JAVA VM 的效能簡直是一場惡夢.

Delphi XE2 開始, 把這個概念作了一些些修正, 叫做 One Code for Multiple platforms (同樣一份程式碼, 能夠在多種平台上執行), 這個口號聽起來沒有很炫, 但卻實際多了.

從 Delphi XE2 開始, 沿用了 20 多年的 VCL 有了 32/64 bit 兩種版本, 另一組新的視覺元件庫: FireMonkey 也被推出, 透過 FireMonkey 元件組所撰寫的程式 (我們先討論一般桌面程式), 就可以直接編譯成 Win32, Win64, 以及 OSX (Mac 作業系統).

雖然要編譯三次, 在操作上多一些些步驟, 但編譯出來的程式, 在各個平台上都是原生程式碼, 不再透過像 JAVA 那樣高階的虛擬機器, 而能夠讓編譯出來的程式碼直接就是機器碼, 這效能的提升, 比透過直譯器達成的程式, 或者虛擬機器達成的程式, 都高出了不知道多少倍.

且 FireMonkey 所提供的介面, 在設計階段都是 Windows 的外觀, 但實際執行的時候, 在Windows 跟 Mac OSX 上面, 都完完全全是原生平台的程式外觀, 不用程式人員再花額外的功夫去處理佈景或圖片的問題了.

至此, 跨平台的功能頗有小成, 但請回想一下, 2009 年, 已經是 iOS 跟 Android 打的死去活來, Windows Phone 只能撿一些小屑屑, 市佔率幾乎達不到兩位數, 開發人員完全不會去想提供 Windows Phone 平台的應用程式.....

因此接下來的 XE3, XE4, XE5, XE6, Delphi 就花了更多的功夫在這兩個完全引領主流的作業系統上面, 到 XE5 算是有所成, 第一次能夠讓 FireMonkey Mobile 的同一份程式碼在 iOS 跟 Android 系統上面執行.

未來將何去何從?

這個題目太大, 即使問微軟說: 你們的 Visual Studio 接下來要提供什麼功能? 相信微軟的開發人員也會一下就楞住, 我相信 Delphi 跟 C++ Builder 也一樣.

目前 Visual Studio 2012 版, 提供了 C#, VB, VC 三種程式語言, 可以透過 .NET 開發網頁程式、Windows 應用程式, 以及透過一些第三方工具, 讓一部分程式能夠編譯成 iOS 能執行的 app (是透過像 JAVA 那樣的虛擬機器, 類似 Mono).

有了網頁, 桌面應用程式, 手機應用程式, 程式人員對 Delphi 的未來還有什麼期待?

未來是不斷在人們手中開創的, 2005 年的時空下, Windows Mobile 幾乎主宰整個智慧型手機市場, 靠的是 Compact .NET framework, 然而, 誰會知道 2007 年 iPod Touch 即將推出, 2008 年 iPhone 2G 與 App Store的推出會讓 XCode (Objective C) 在兩年內席捲全球? 2009 年 Android 系統跟 Eclipse 讓 JAVA 借屍還魂?

誰又知道 2014 年六月, Apple 會推出語法近似 JAVA 與 C#, 包含有完整物件導向概念, 原生相容於 XCode 所有 Framework 的新程式語言 Swift? (按筆者: 所有程式語言, 請從其概念來理解, 則只需要 Reference 文件就可以很快學會, 大約 1-2周吧)

未來, 永遠是軟體人員心中永遠的期許, 也是傷痛, 這兩個字代表著無限的學習, 永不停止.

對 FireMonkey 的不熟悉

FireMonkey 是一組全新的元件, 大多數一直使用 Delphi 的程式人員, 都有著陌生的感覺, 在台灣, 除了 Embarcadero 原廠的文件與代理商捷康努力的推廣, 請李維大師持續的在這塊領域上耕耘之外, 能夠說自己已經熟悉 FireMonkey 的人恐怕不多.

筆者從 Delphi XE5 使用至今, 剛剛有一些些熟悉, 未來也會把這些相關經驗在網路上分享出來, 期望透過交流與跟網路上的開發人員交互學習, 讓 Delphi 與 FireMonkey 能夠發揮出很好的功能, 讓 Delphi 的程式技巧能夠再次引領業界與學界的風氣, 在未來的某一天, 如果台灣能夠開始對軟體開發稍微正眼看待的時候, 讓 Delphi 與 C++ Builder 能夠成為程式人員前幾名的選擇.

Dennies
2014 年六月.