相信大家都已知道，ECOIV 或未來版本即將在 VS環境中支援了，可以想像，
DELPHI 的最大最新價值是ECO 的技術平台，一且支援了MS-VS，DELPHI
可能因為其本身的BUG一堆運作不穩定以及文件技術說明不足等等不利因素
將造成了許多人轉向VS.NET 平台使用ECO技術。而更令人不願見到的事是:
原本會使用DELPHI C#設計系統大部份是因為C# BUILDER 的ECO 支援。
但是在D2007 的平台中，卻將C# BUILDER 從此抽離，這個廣大被採用的
新興語言，DELPIH 竟不支援，那麼使用C# 的人，將轉向VS 陣營中。而且
未來ECOIV 等等後續版本也將支援VS.NET 的C#語言，那麼無非是C# BUILDER
的巿場明顯的白白送了MS 了嗎?那麼這幾年來從D8到D2006 所辛苦經營ECO For C#
的巿場不就等於空忙一場?。
沒事還搞個ROR IDE ,明明就很少人用的WEB 平台開發工具，卻冒然投入，
也實在錯誤的決策。真不懂他們的CEO 倒底專不專業呢?!去投資ROR ,裁掉ECO for C#
Builder ，實在是不明智的決策。而且更讓對手MS也支援了ECO 的技術，如這樣的話
DELPHI 的未來還有什麼特殊的巿場區隔可言呢?相信許多人也會全力轉向MS.VS平台。
畢竟VS.NET 比DELPHI 來得穩定且技術文件充足，而且又本土化的中文環境與技術支援。

------
ATEIN

編輯記錄

RAD Studio 2007 with Update 3 實際上就是 Delphi 2007 for Win32 + C++ Builder 2007 + Delphi 2007 for .NET (光碟中有看到 C# )

參考 http://delphi.ktop.com.tw/board.php?cid=169&fid=973&tid=90502

===================引 用 ATEIN 文 章===================
相信大家都已知道，ECOIV 或未來版本即將在 VS環境中支援了，可以想像，
DELPHI 的最大最新價值是ECO 的技術平台，一且支援了MS-VS，DELPHI
可能因為其本身的BUG一堆運作不穩定以及文件技術說明不足等等不利因素
將造成了許多人轉向VS.NET 平台使用ECO技術。而更令人不願見到的事是:
原本會使用DELPHI C#設計系統大部份是因為C# BUILDER 的ECO 支援。
但是在D2007 的平台中，卻將C# BUILDER 從此抽離，這個廣大被採用的
新興語言，DELPIH 竟不支援，那麼使用C# 的人，將轉向VS 陣營中。而且
未來ECOIV 等等後續版本也將支援VS.NET 的C#語言，那麼無非是C# BUILDER
的巿場明顯的白白送了MS 了嗎?那麼這幾年來從D8到D2006 所辛苦經營ECO For C#
的巿場不就等於空忙一場?。
沒事還搞個ROR IDE ,明明就很少人用的WEB 平台開發工具，卻冒然投入，
也實在錯誤的決策。真不懂他們的CEO 倒底專不專業呢?!去投資ROR ,裁掉ECO for C#
Builder ，實在是不明智的決策。而且更讓對手MS也支援了ECO 的技術，如這樣的話
DELPHI 的未來還有什麼特殊的巿場區隔可言呢?相信許多人也會全力轉向MS.VS平台。
畢竟VS.NET 比DELPHI 來得穩定且技術文件充足，而且又本土化的中文環境與技術支援。

一個企業專注於一個產品線久了,自然就會想多角化經營,
多角化經營久了, 就會回縮單一產品線, 不同的管理階層有不同的作法......
CodeGear的企業使命可能已不是單單開發好用的IDE
因為單是IDE現在已經賺不到什麼錢, 而單純的framework也賺不到什麼錢
必須以更高的思維, 去轉化及看待整個大環境的變遷

個人在想.....當初聽到ECO是把商業規則整理成跨程式語言平台,在佈署時才build成某一程式語言
我可以維護單一的商業規則, 給Win32、dotNet、Java、PHP、RoR......
精神核心如此, 理想境界可以這樣

不然想不出為什麼CG要跨足涉獵PHP及RoR的理由
背後應該有其它的願景在執行

在 RAD Studio 2007 中，C# 已被降格成和 VB Builder 一樣，沒有 designtime support ，沒有 CodeDOM，ECO 在 RAD Studio 2007 是不能生成 C# 的。要用 C# 的話就要借助 EcoModler 如果你有用過 Delphi .NET (2006) ECO 的話，小弟希望聽一你的意見，對我來說 ECO Delphi 2006 是一個惡夢 超爛的 IDE 會自動更改源碼殺掉一些表單上的元件，相信是那 Winforms/Webforms Designer 的問題，事實上我已先後在四個 Windows (XP x2, Vista x 2) 上安裝過 BDS 2006，結果都是臭蟲一大堆，反觀 ECO C# Builder 就相當穩定。加上 Delphi 先天 circular reference 的限制，有些合法的 ECO model 是不能生成合法的 Ｄｅｌｐｈｉ 的 加上那聞名已久的客戶服務

CodeGear 又一損失
http://www.droopyeyes.com/

===================引 用 syntax 文 章===================
RAD Studio 2007 with Update 3 實際上就是 Delphi 2007 for Win32 C Builder 2007 Delphi 2007 for .NET (光碟中有看到 C# )

參考 http://delphi.ktop.com.tw/board.php?cid=169&fid=973&tid=90502

基本上,CG在PDA的開發領域之中,到目前為止算是交了白卷;
很遺憾的是,針對市場的需求;提供解決方案,不是最優先的事情嗎?
會讓客戶直接在網路上公佈這些訊息,說不再願意使用Delphi ,這是很嚴重的一件事了!!

不知道CG還一直在擴展新的IDE工具,難道是為了讓研發人員玩玩技術而已嗎?
有時後是否可以想想這些可憐的舊客戶們?

基本上, 從標題的 " Delphi 未來的隱憂 在對手 MS-VS.NET ",

來看,

其實敝人看法,倒認為,

如果要比較同型產品就應該看solution跟整個環境,
比方某個solution,可能的方案,開發主導者會根據,
應該比較方式為:

(codegear Delphi 協力廠商 .. )
vs ( MS MS-vs.net 協力廠商 solution的相關產品聯合行銷火力,如SQL /exchange 公關人脈影響力 .. )
vs (其他solution )

等作評估的.


就像 MS 本身也會定位 MS-SQL 走高/中階資料庫solution, Ms-Access 走入門級資料庫.

應該以找 MS產品線間,有較大空隙的發展空間為宜.



至於程式設計師的話, 個人看法,較不適合單學Delphi,

因為就工作機會來說, MS家族 或 Java 的工作機會都比Delphi 多很多.

可兩者都學,或者也學 Java 或其他熱門語言吧.


因為雖然說Delphi 入門門檻低,生產力高,
但,當薪專案數不多時,專案用較少的 人月 來完成,
那市場工作機會減少的特別明顯,
且工資也可能會比 Java/C#/...等來的低.
這對程式設計師而言也是潛在缺點. 不可不慎.

編輯記錄

To:

syntax

-----的回應,
請您確認,您可能不了解,c# builder 的 可視設計form 已經不見了,只留下 code edit ,並不能設計應用軟體。

------
ATEIN

編輯記錄

以整體資源來評估技術性,對DELPHI而言您這樣講,我則有其它看法,在近15年來開發許多ERP/MRP/CRM... 軟體大型系統經驗而言,
MSSQL 或MYSQL...等等DBS可以透過DELPHI 來整合,在資料庫與IDE工具,沒有什麼IDE相容性的問題，只有DB DRIVER的問題。
基本上DELPHI MSSQL /ACCESS ... 都相容得非常好。一直以來都是如此順利。DELPHI 造就多少的就業率，至少在過去都是如此美好。
例如若要開發SQL資料庫應用軟體系統 ,只要看MSDN 或SQL HELP 皆可完善地開發APPLICATION;這在DELPHI/JAVE/VS 或VB/..都是一樣。

而好用的IDE工具才是評估的重點。

像ECO 就是所有的IDE 無法比較的好處與強大之一。
因為在研究ECO,多年以來，一直感覺ECO 是一個強大的開發技術，有了ECO後,其他的技術我都看不上眼了。
什麼ADO.NET 或其它技術而言,沒有能比上ECO 的快速與效益;以及低的維護成本。
===================引 用 system72 文 章===================

基本上, 從標題的 " Delphi 未來的隱憂 在對手 MS-VS.NET ",

來看,

其實敝人看法,倒認為,

如果要比較同型產品就應該看solution跟整個環境,
比方某個solution,可能的方案,開發主導者會根據,
應該比較方式為:

(codegear Delphi 協力廠商 .. )
vs ( MS MS-vs.net 協力廠商 solution的相關產品聯合行銷火力,如SQL /exchange 公關人脈影響力 .. )
vs (其他solution )

等作評估的.


就像 MS 本身也會定位 MS-SQL 走高/中階資料庫solution, Ms-Access 走入門級資料庫.

應該以找 MS產品線間,有較大空隙的發展空間為宜.



至於程式設計師的話, 個人看法,較不適合單學Delphi,

因為就工作機會來說, MS家族 或 Java 的工作機會都比Delphi 多很多.

可兩者都學,或者也學 Java 或其他熱門語言吧.


因為雖然說Delphi 入門門檻低,生產力高,
但,當薪專案數不多時,專案用較少的 人月 來完成,
那市場工作機會減少的特別明顯,
且工資也可能會比 Java/C#/...等來的低.
這對程式設計師而言也是潛在缺點. 不可不慎.

------
ATEIN

前陣子看一篇報導的統計資料,

就使用率的佔有率,還有名次之類來說,

Delphi 最近那幾年,兩者都是下降的,


就業機會來說的話,其實去網路人力銀行收尋就可以知道大概.
比方在 1x4,我現在 輸入關鍵字:
"Delphi",可查到 22筆, 需求年資:2年~不拘.
"Java" 可查到 211 筆,需求年資:8年~不拘.
幾乎是Delphi的10倍了,而且重要的事,還有年資需求3-8年這段.


(另,在有些公司似乎是每年每個月都在徵同樣人力,

這種大概是徵假的,

比方為了,裝成公司生意很好,所以老是在徵人.
或者專案大至完成,但要裝成被挖角,所以裝要徵人,但因其實不需要所以就徵不到人,或順便於讓留下的自己人卡位,或加班加薪.

要不然,那種,名聲待遇不錯的公司,真的有長期人力需求的,通常徵個2個月內就徵到人,就會關掉徵人廣告.,
而進去的人正常也會待個一年,或少說至專案完成,而公司也較不會假裝徵不到人)



其實,Delphi 搭配 MS-SQL, Oracle 也很不錯吧.


但基本上不是Delphi本身不好,

而是 市場需求 與人力供需的問題,

因為 生產力高,又容易上手的工具,
一些舊專案一年才累積零出來需求的修改,維護等,通常老手2-3個月就可以完成,
新手也可以半年-1年內完成,
所以徵人大概徵0~2年經驗的就夠了.

如果沒有大公司的全新的大案子,是以Delphi開發的話,
人力供需上,Delphi為主力的人力需求較其他工具少.



倒是,如果是程式設計師自己當老版,或合夥人,

自家產品用Delphi開發,
那一些情況下是不錯的選擇.

像有些小型的軟體公司,主力產品適用Delphi開發而成,
初期,就只有 一個老闆(工程師),一個業務,一個老闆娘管(財務會計客服),在一個客服(兼網頁美工)
接到大案子時,再找 外包/中短期工程師 來完成.
幾年下來,光維護的合約就滿賺的,再逐漸擴充人員..


===================引 用 ATEIN 文 章===================
以整體資源來評估技術性,對DELPHI而言您這樣講,我則有其它看法,在近15年來開發許多ERP/MRP/CRM... 軟體大型系統經驗而言,
MSSQL 或MYSQL...等等DBS可以透過DELPHI 來整合,在資料庫與IDE工具,沒有什麼IDE相容性的問題，只有DB DRIVER的問題。
基本上DELPHI MSSQL /ACCESS ... 都相容得非常好。一直以來都是如此順利。DELPHI 造就多少的就業率，至少在過去都是如此美好。


例如若要開發SQL資料庫應用軟體系統 ,只要看MSDN 或SQL HELP 皆可完善地開發APPLICATION;這在DELPHI/JAVE/VS 或VB/..都是一樣。

而好用的IDE工具才是評估的重點。

像ECO 就是所有的IDE 無法比較的好處與強大之一。
因為在研究ECO,多年以來，一直感覺ECO 是一個強大的開發技術，有了ECO後,其他的技術我都看不上眼了。
什麼ADO.NET 或其它技術而言,沒有能比上ECO 的快速與效益;以及低的維護成本。

編輯記錄

TO system72:

文中可知您知之甚詳。DELPHI 需求變少，因在於早期的DELPHI技術比於JAVA 的網路應用方案較少之故
;但目前DELPHI 在網路的應用方案逐漸提升，相較之下java 的開發/維護成本較高許多，大部份的java 在
應用而言,則應用在設計java game,以提供跨平台之需較多。

delphi 目前最大投資的價值在於先進的ECO 技術，這要怎麼說呢? 在ECO 中的所有行為皆為物件導向
，且也能充分表達UML 的核心精神，由於架構在DOT NET 上,其效率上沒WIN32/WIN64 原生應用程式
來得良好。不過仍然比JAVA 應用程式來得好。

ECO 效益、開發速度，是目前我看過開發最直覺化、維護成本最低、最快速化、知識經驗門檻最高的
技術、平台。這是JAVA 所無法比擬的。ECO在困難度上及功能上，總體而言都比JAVA 高上許多，且國
內只有李維技術長出過該書。而ECO 是一個以全新的以架構為導向開發，且是以知識、領域、架構、組件
為開發方式，可真正做到軟體邏輯IC的要求及自動化。ECO 也將會刷新DELPHI 開發工具的全新核心價值;
而不是只是如:「單純以往DELPHI 的傳統語言開發思維而已」。

換言之:JAVA EJB.../C# ADO.NET/VB.NET ADO.NET/VB/DELPHI ADO.../DBEXPRESS/ 皆可稱為傳統開發
方式;而C# ECO/DELPHI ECO 可稱為全新架構開發方式。這兩者間的開發方式，差異性必須由您體會才能知道。

------
ATEIN

http://www.ithome.com.tw/itadm/article.php?c=46391

在網頁動態語言世界另闢戰場?

CodeGear在Delphi這條產品線上，從roadmap以及dn上的一些發言
感覺重心似乎偏向native的領域
.NET的比重似乎不再去強調了
不知大家是否也有此感覺
此外，dn上的2008 Delphi Survey (http://infopoll.net/live/surveys/s31894.htm)
大家有空可以去填一填，裡面有關於Unicode方面的調查
讓東方人的心聲在問卷統計上的比例能提升些，這樣CodeGear也許會更重視我們的需求吧

Delphi Prism - new Delphi.NET Solution
http://blogs.codegear.com/chrispattinson/2008/10/03/38898/

Prism不知是不是新版的Delphi for .net
有興趣的人可以去申請參加beta test