你不選擇Delphi.Net嗎?

許多人曾預言,隨着.Net的引入,從一種語言的角度來說,Delphi將會衰落或者消亡。在過去的幾年裏這種預言就已出現很多次了,然而Delphi仍然保持了穩定的發展,甚至還有幾次斬獲。我相信隨着.Net的持續增長,Delphi將不僅會保留住它的擁護者,而且其使用與擁護者都會增加。這是與今天許多人的意見相反的,下面我將解釋這一點。

誰將從.Net獲益?

.Net是個好東西。但是.Net所提供的大部分東西只是對程序員有好處。除了程序員利用.Net提供的東西外,最終用戶只能獲得極少的好處。沒有最終用戶會重啓他們的計算機,並說“是的,我想今天我將安裝.Net”。用戶將只在被.Net應用程序要求的時候去安裝.Net。

就個人而言,.Net對我最大的吸引力就是我們最終擁有了代碼的跨語言兼容性。這已被延誤很久了,但是跨語言兼容性也僅是程序員的工具。最終用戶不會關心C#代碼是否能與Delphi一起工作的很好。最終用戶只關心這個程序是否做了他們希望它做的。

.Net是爲服務器的

在你反駁我之前,這條申明從來都不是真的。.Net當然不是隻爲服務器設計的。.Net也是爲桌面計算機設計的,然而從相近的術語上層面上說,.Net是爲服務器設計的,這就是爲什麼.Net現在是並且將來也是被用作這種相近術語的原因。在一個機器上安裝.Net,1.0版本需要20M以上的空間,1.1版本已發佈,體積更大(1.1版爲23M,並且最終的安裝需要110M)。這僅僅是在安裝方面,除了體積大以外,它還將變成操作系統的一個核心部分。

對於那些安裝大小不是個問題的用戶來說,部署與支持卻也是個問題。對於有着成百上千的計算機的那些公司來說,不會簡單地大規模部署任何軟件系統,當然也不會不做許多準備工作就貿然安裝像.Net這樣的核心軟件。

對於家庭用戶來說,就不僅僅是安裝問題了,還有帶寬的問題。軟件當然還是通過CD來發布的,但大多數家庭用戶使用的非遊戲軟件都是從因特網直接下載的。當然許多用戶今天也擁有寬帶接入,但是除去程序員以外,大部分家庭用戶都沒有寬帶接入。多數可下載的程序都在1-5M之間,這是一個可以接受的下載大小。把體積增大到5-20倍那就不太好下載了。

一旦你安裝了它,它就在那兒了

是,又不是。一旦你安裝了.Net,事實上你就擁有它了,並且對於所有.Net程序來說,它都是可用的。然而,.Net框架1.1版本已經發布,顯然1.2或者2.0也已在開發之中。以前的經驗告訴我們每一個版本都會比老版本體積大。如果一個用戶已經安裝了1.0,但是你的程序又需要1.1,這個最終用戶就需要另外的更大的安裝。最後,完全可以想象最終用戶將需要多達4個不同的.Net框架版本,來支持已安裝的軟件。

程序員的觀點

.Net很酷。.Net很新。這就足夠讓大多數程序員期望.Net了。當然,.Net也確實有足夠的真材實料來讓自己值得程序員的期望。不過,我們還是從不同語言的角度來看一下吧:

  • C++ - 簡言之,C++是不能被託管的代碼,這樣就不能在.Net上很好的工作。C++用戶將被劃歸到非託管代碼或者設備驅動開發這一類中去。微軟已經在鼓勵C++開發者轉移到C#了,並且最後非託管代碼將不只是不被鼓勵,而是幾乎就是不被允許了。雖然C#在很多方面與C++都相似,而且顯然(其語法)根植於C++,但是仍與C++有着很大的差異。多數C++開發者都是純粹主義者,對他們的語言有着非常狂熱的執著。由於這一點,許多C++開發者都不喜歡C#,並且根本不情願轉移到C#上去。

  • Visual Basic - Visual Basic 在.Net中並不存在,而是變成了Visual Basic.Net。VB.Net與VB是不兼容的,僅僅在一些基本語法上有些類似。(在.Net上)VB程序必須被重寫,而且幾乎是完全重寫。當VB最終有了一些改變來使它成爲一個“真正的”語言時,VB用戶卻開始反對了。許多VB用戶很不滿意地稱VB.Net爲Visual Fred,而且誓不轉移到.Net平臺,或者乾脆就投奔Delphi。

  • delphi - delphi 7用戶已經有了一個Delphi for .Net編譯器DCCIL的預覽版。Delphi 8 將提供完整的Delphi for .Net編譯器。現有的Delphi代碼,當然需要一點改變,將能被輕鬆地移植到.Net平臺。


這意味着什麼?這意味着Delphi將是移植到.Net的路徑中代價最小的一條。如果你是一個Delphi開發商,你知道你就能以最小的顧慮而轉移到.Net上,然而如果你是一個Microsoft開發商,你就要選擇是完全重建還是維護兩套不同語言的系統,兩種選擇都很拖累。也就是說是繼續維持現有的VB或C++的系統呢,還是重新以C#或則VB.Net建造新的系統。

.Net需要兩次開發

由於語言兼容性問題,.Net基本上是個比較極端的事情。由於很可能衆多公司將只在服務器而不是桌面計算機上部署.Net,因爲現存的應用將很可能不被移植到.Net上,開發者們必須以兩種語言開發,一種是VB 或 C++,另一種是 C# 或 VB.net。除了開發人員必須被培訓兩次外,還必須爲可預見的將來保持分開的不兼容的兩份代碼庫。

很少開發商能爲使用了.Net的最終用戶而完全轉移到.Net上來,即使他們可以,也不得不支持老的應用或爲移植問題而重寫代碼。
在另一方面,Delphi允許開發者只維護一份通用的代碼庫,就能被用作在Win32 (不是 .Net) 與 .Net上跨平臺部署。Delphi也能讓開發者通過Kylix(重新編譯源代碼)而在Linux上部署應用。對現有的Delphi開發商而言,只需要對開發人員進行很少的再培訓。

可是現在並沒有Delphi.Net

現在並沒有Delphi for .Net,但許多開發者已看到這種趨勢了。在Delphi 8中的Delphi for .Net將提供獨一無二的跨平臺選擇與簡單容易的移植路徑。在預料到這一點之後,許多開發者正在轉向Delphi。

.Net開啓了大門

由於現存的庫,代碼與第三方支持(有許多是非Delphi語言的),語言互操作性的缺乏曾經阻止了許多開發者使用Delphi。有了.Net,語言就不再是個問題。.Net將使更多的開發者轉移到Delphi上來。(這裏所謂更多的)開發者就是那些以前曾經考慮過Delphi,但由於這個約束而沒有轉移過來的開發者。

delphi 8 衝擊

作爲一個組件供應商,我們可以研究我們自己的客戶。雖然Delphi7是一個成功的產品,但許多用戶還仍然在使用Delphi5與Delphi6。這些用戶只是僅僅沒有看到任何使用Delphi7的需要而已。然而,帶有.Net支持的Delphi8將給他們提供一個非常強大的升級動機,現在許多這類用戶正在等待着Delphi8的問世。就我看來,Delphi8將是一次非常成功的發佈版本,將不只是Delphi7用戶的升級目標,也將是許多Delphi5與Delphi6用戶的期望之選。

結論

我恨.Net嗎?不,恰恰相反。但是,轉移到.Net也不是一蹴而就的,而且還要付出一些代價。Delphi提供了最佳的移植路徑,特別是在.Net普及後,其優點更是意義重大。所有這些因素都將讓Delphi 8獲得巨大成功,並且推動Delphi被更多地使用。


作者簡介: Chad Z. Hower是Delphi組件集Indy的原始作者,組件集IntraWeb的作者,AToZed公司創始人,常去世界各地遊歷。

譯註:原文發表日期爲2003年9月11日,本文在徵得作者同意後翻譯,翻譯完畢日期2003年9月17日。轉載請註明出處:www.delphidevelopers.com,並保留作者譯者名稱。

發佈了32 篇原創文章 · 獲贊 0 · 訪問量 7萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章