全國最多中醫師線上諮詢網站-台灣中醫網
發文 回覆 瀏覽次數:3148
推到 Plurk!
推到 Facebook!

Delphi 的現況

 
tigery2k
一般會員


發表:5
回覆:20
積分:10
註冊:2002-06-06

發送簡訊給我
#1 引用回覆 回覆 發表時間:2011-11-24 11:52:33 IP:60.248.xxx.xxx 訂閱
因為工作的關係,常會去大陸出差,最大的喜好就是逛那的書店,那的書比台北天龍書局的多很多.我想說的重點是,上半年去那,Delphi的書還可以看到個10種左右,前一個月再去時居然只剩一,二本.不知針對Delphi的推廣是不是那裡出問題了,由出書的狀況來看,用的人大概快絶版了.

march77
一般會員


發表:2
回覆:2
積分:0
註冊:2002-03-13

發送簡訊給我
#2 引用回覆 回覆 發表時間:2011-11-24 19:31:20 IP:122.117.xxx.xxx 訂閱
根據我的國內實務觀察,很多書店都沒有Delphi,大型書店也只剩下一種(天瓏無時間去逛),我認為很多人投向.Net
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#3 引用回覆 回覆 發表時間:2011-11-24 22:07:18 IP:118.169.xxx.xxx 未訂閱
其實現在要找Delphi書比中樂透還難, 這是不爭的事實, 也很悲哀, 但 .net 也不見得好到那裡, 由兩三年前佔十來個書櫃到現存僅存一個書櫃, 所以有點是五十步笑百步的狀況, 現在正夯的不外乎是iPhone, iPad, Andriod 吃了50%以上的空間, 再來是Office系列, win7 技術書等等
===================引 用 march77 文 章===================
根據我的國內實務觀察,很多書店都沒有Delphi,大型書店也只剩下一種(天瓏無時間去逛),我認為很多人投向.Net
ANDY8C
資深會員


發表:114
回覆:582
積分:299
註冊:2006-10-29

發送簡訊給我
#4 引用回覆 回覆 發表時間:2011-11-25 08:58:39 IP:210.66.xxx.xxx 未訂閱

行銷 推廣 的問題 , 無關產品好壞 , 青菜蘿蔔,每個人的喜好不同

工具是拿來用,能用到很熟練,然後可以謀生,這點很重要.

每次聽到 " 喔! 您用 DELPHI , 聽說它做資料庫軟體很方便" ,

在學校進修 ,老師知道我用 DELPHI " 啊 !! 那是很古老的產品,現在還有誰在用 "

不知要哭,還是笑這些人的無知....

說實在的,我又不是每天要去應徵工作,何需隨著大家再學新的東西,

如此篇所說
我用一輩子的時間只做這一件事,怎麼會不成功
http://delphi.ktop.com.tw/board.php?cid=32&fid=107&tid=103523

我用一輩子的時間學 DELPHI , 當然能做出一些東西
每一種開發工具都有它的市場,選擇它後,就好好學,
只怕你不熟,做不出東西,那才是笑話

工具熟了,接案/結案速度就很快,生活當然會變好

其實....我的經驗.....接案才難,業務那塊,不是一般工程人員能想像的.

我有很多 DELPHI 技術,是自己 "拼湊" 出來,一路走來很辛苦,但也玩的很有成就感(自我安慰)

在客戶面前, 要解決的是問題,客戶才不會管你用什麼工具.

所以....下決心,要學什麼工具,趕快進行就對了.

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.
huangeider
高階會員


發表:288
回覆:492
積分:231
註冊:2003-02-26

發送簡訊給我
#5 引用回覆 回覆 發表時間:2011-11-26 17:19:09 IP:114.39.xxx.xxx 未訂閱
小弟2003年是由學delphi開始寫程式,許多問題都是在ktop提問得到回答的,
在此先謝謝站長各位板大與各位前輩的指導.
2003年時delphi書大概買了十多本,不過大多是基礎的書,
好幾本翻過一次就知道大同小異,雖然幾年前就改用bcb,
不過也還是希望delphi的書不要成為絕版書,
我想delphi新的使用者愈來愈少了,所以就絕版了
這幾年有問題都上網找資料,很少去書店,或者跟網路發達也有關系

pprayer
高階會員


發表:35
回覆:185
積分:174
註冊:2002-03-13

發送簡訊給我
#6 引用回覆 回覆 發表時間:2011-11-26 17:29:55 IP:114.32.xxx.xxx 訂閱
我想 Delphi的隱憂是 Win32 API 
Win32 API 基本上不會有新的東西了吧
且未來微軟會不會壯士斷脕吧 Win32 API 做個大整頓呢??
或許現在還用WinNT平台的人還不少 不過IE6的殷鑒不遠
.NET 雖然慘,不過至少微軟還有再推出新版本的Framework

畢竟大家都是站在微軟這巨人的肩膀上做事
微軟未來想怎麼搞 大概不會因為有人用了Delphi 二三十年就有所顧忌
puff
一般會員


發表:1
回覆:13
積分:2
註冊:2002-08-13

發送簡訊給我
#7 引用回覆 回覆 發表時間:2011-11-26 18:33:48 IP:59.117.xxx.xxx 未訂閱
幾個月前在天X書局有發現Delphi的簡體版書,真是難得。


P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#8 引用回覆 回覆 發表時間:2011-11-26 23:11:42 IP:118.169.xxx.xxx 未訂閱
我想應該沒有什麼隱憂的問題, 
現在的Delphi 已發展 FMS 系統, 這是完全擺脫 WIN32 API 的包袱, 但不代表開發的系統就無法在WINDOW平台跑, 反而我看來是海濶天空, 我認為 FMS 未來是一佪無可限量的發展, 就算Delphi可能無法起色, 但 FMS 將會是帶動一股潮流
===================引 用 pprayer 文 章===================
我想 Delphi的隱憂是 Win32 API
Win32 API 基本上不會有新的東西了吧
且未來微軟會不會壯士斷脕吧 Win32 API 做個大整頓呢??
或許現在還用WinNT平台的人還不少 不過IE6的殷鑒不遠
.NET 雖然慘,不過至少微軟還有再推出新版本的Framework

畢竟大家都是站在微軟這巨人的肩膀上做事
微軟未來想怎麼搞 大概不會因為有人用了Delphi 二三十年就有所顧忌
暗黑破壞神
版主


發表:9
回覆:2301
積分:1627
註冊:2004-10-04

發送簡訊給我
#9 引用回覆 回覆 發表時間:2011-11-28 10:19:05 IP:122.117.xxx.xxx 未訂閱
其實,在醫藥界用的文字是”拉丁文”,為什麼是拉丁文?
因為它是一種”死”的語言。不會再有多變化跟創新。
在當年 Delphi 跟 C Builder 都還很”活躍”時,使用者也會有種永遠在追新功能的一種行為。
暫且不論那些新功能是好還是壞,總是一出新版時,就會造成了一些個不相同的出現。

但是,這幾年它一直沒更新了,老用戶反而是越用越熟,都可以游刃有餘。這在版本一直更新的年代是不太可能做到的事。
而這也未嚐不是件壞事。

Win32 API 會不會死?
即使它死了。win32 也會活在 VM 之中。沒什麼好怕的啦。

===================引 用 pprayer 文 章===================
我想 Delphi的隱憂是 Win32 API
Win32 API 基本上不會有新的東西了吧
且未來微軟會不會壯士斷脕吧 Win32 API 做個大整頓呢??
或許現在還用WinNT平台的人還不少 不過IE6的殷鑒不遠
.NET 雖然慘,不過至少微軟還有再推出新版本的Framework

畢竟大家都是站在微軟這巨人的肩膀上做事
微軟未來想怎麼搞 大概不會因為有人用了Delphi 二三十年就有所顧忌
ko
資深會員


發表:28
回覆:785
積分:444
註冊:2002-08-14

發送簡訊給我
#10 引用回覆 回覆 發表時間:2011-11-28 17:57:15 IP:61.66.xxx.xxx 訂閱

Win32 API 會不會死?
即使它死了。win32 也會活在 VM 之中。沒什麼好怕的啦。

============================================
VM萬歲!
------
======================
昏睡~
不昏睡~
不由昏睡~
cancer
高階會員


發表:58
回覆:319
積分:190
註冊:2004-07-31

發送簡訊給我
#11 引用回覆 回覆 發表時間:2011-12-30 10:29:33 IP:220.128.xxx.xxx 未訂閱
沒差,我現在用 Delphi 2006,根本沒有用到 Delphi 全部能力的一半,其實用 Delphi 7 就可以搞定,但更高版本會有更好的編輯器。
有時候開發工具標榜有甚麼厲害的地方,但對於資料庫程式而言,一點都派不上用場,因為重點不在於開發工具,而是在於開發人員對專案所屬的行業別有多少了解。
Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#12 引用回覆 回覆 發表時間:2012-01-22 21:22:04 IP:114.45.xxx.xxx 訂閱
FMS 這副鳥樣子, 距離真的能用, 還有好一段距離,
看現況, 市面上根本沒新書, 更別說FMS 一大堆問題.
而自己的compiler 又還未好, 還要借用freepascal 的.
對compiler 可以有較好的方法
1. 跟freepascal 的合作, source license?
2. 買下freepascal team.
3. 買下codewarrior
而framework FMS 的部分, bug 也太多了點. 先集中人手來清理bug, 作一個VCL to FMS 的轉換方式, 以及為各平台加速吧.
別現在這個不湯不水的鳥樣子, 看起來是有好過沒有, 實際是好看不好吃.

===================引 用 P.D. 文 章===================
我想應該沒有什麼隱憂的問題,
現在的Delphi 已發展 FMS 系統, 這是完全擺脫 WIN32 API 的包袱, 但不代表開發的系統就無法在WINDOW平台跑, 反而我看來是海濶天空, 我認為 FMS 未來是一佪無可限量的發展, 就算Delphi可能無法起色, 但 FMS 將會是帶動一股潮流
===================引 用 pprayer 文 章===================
我想 Delphi的隱憂是 Win32 API
Win32 API 基本上不會有新的東西了吧
且未來微軟會不會壯士斷脕吧 Win32 API 做個大整頓呢??
或許現在還用WinNT平台的人還不少 不過IE6的殷鑒不遠
.NET 雖然慘,不過至少微軟還有再推出新版本的Framework

畢竟大家都是站在微軟這巨人的肩膀上做事
微軟未來想怎麼搞 大概不會因為有人用了Delphi 二三十年就有所顧忌
GrandRURU
站務副站長


發表:240
回覆:1680
積分:1874
註冊:2005-06-21

發送簡訊給我
#13 引用回覆 回覆 發表時間:2012-01-24 07:33:00 IP:111.249.xxx.xxx 未訂閱
10年來,官方連 BDE to DBX 的轉換工具都沒出現了, VCL to FMS?
你有得想囉,哈!
===================引 用 Lordaeron 文 章===================
...43...
而framework FMS 的部分, bug 也太多了點. 先集中人手來清理bug, 作一個VCL to FMS 的轉換方式, 以及為各平台加速吧.
...43...
Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#14 引用回覆 回覆 發表時間:2012-02-07 20:57:58 IP:1.161.xxx.xxx 訂閱
Android 方面, 現在做的是偷雞法, 將pascal 轉成對應的java
這實在是腦殘到極致的方式, 我來寫java 加上eclipse 即可, 我何苦呢?
現在android 最大的問題就是慢, 所以google 才又弄個NDK 出來解決這問題.
delphi 應該是往這方向走才對, 將UI 的部分用偷雞法給java, 而其它部分, 就一樣是
native code. 這樣才顯得出價值所在.

而iOS 的部跟, 跟來鬧的沒兩樣, 完全無法抓到iOS 的核心, 無法像obj-C 哪樣寫
也是採偷雞的轉法, 實在是引不起太多的回響是必然的.

要成覇業, 又不想流血衝突, 這是不可能的, 歷史上從未發生過.

轉換工具, 我沒說要, 我也不期待, 人人的寫法習慣不同.
只要是轉換的方法, 有個方式, 有個方向能快點轉, 才是正路.

===================引 用 GrandRURU 文 章===================
10年來,官方連 BDE to DBX 的轉換工具都沒出現了, VCL to FMS?
你有得想囉,哈!
===================引 用 Lordaeron 文 章===================
...43...
而framework FMS 的部分, bug 也太多了點. 先集中人手來清理bug, 作一個VCL to FMS 的轉換方式, 以及為各平台加速吧.
...43...
GrandRURU
站務副站長


發表:240
回覆:1680
積分:1874
註冊:2005-06-21

發送簡訊給我
#15 引用回覆 回覆 發表時間:2012-02-08 09:02:00 IP:59.120.xxx.xxx 未訂閱
每轉一個平台就要學一種語言,不是所有人都是語言天才
要掌握各種語言的特性,也不是一天兩天就可以達成的 (好吧,我承認我有語言障礙)

Lordaeron大所言的也可以套用在低階語言上
「將 Keil C 轉成對應的 ASM,這實在是腦殘到極致的方式,我來寫 ASM 漢書即可,我何苦呢?」

但事實上是?

能用拿手的語言寫出各式的平台,就算效能差點,能達到正確的結果才是重要的不是?

===================引 用 Lordaeron 文 章===================
Android 方面, 現在做的是偷雞法, 將pascal 轉成對應的java
這實在是腦殘到極致的方式, 我來寫java 加上eclipse 即可, 我何苦呢?
現在android 最大的問題就是慢, 所以google 才又弄個NDK 出來解決這問題.
delphi 應該是往這方向走才對, 將UI 的部分用偷雞法給java, 而其它部分, 就一樣是
native code. 這樣才顯得出價值所在.

而iOS 的部跟, 跟來鬧的沒兩樣, 完全無法抓到iOS 的核心, 無法像obj-C 哪樣寫
也是採偷雞的轉法, 實在是引不起太多的回響是必然的.

要成覇業, 又不想流血衝突, 這是不可能的, 歷史上從未發生過.

轉換工具, 我沒說要, 我也不期待, 人人的寫法習慣不同.
只要是轉換的方法, 有個方式, 有個方向能快點轉, 才是正路.

===================引 用 GrandRURU 文 章===================
10年來,官方連 BDE to DBX 的轉換工具都沒出現了, VCL to FMS?
你有得想囉,哈!
===================引 用 Lordaeron 文 章===================
...43...
而framework FMS 的部分, bug 也太多了點. 先集中人手來清理bug, 作一個VCL to FMS 的轉換方式, 以及為各平台加速吧.
...43...
Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#16 引用回覆 回覆 發表時間:2012-02-08 11:56:53 IP:114.45.xxx.xxx 訂閱
對我來說, 一本cook book, 一本language reference, 一本API 就夠了, 什麼鬼language  (Except prolog and lisp) 都麻是
這些梗. 其它的, google 查.
Delphi(object pascal) vs Java vs C# vs Objective-C
有什麼很大的差異嗎? 我怎麼看都沒有.
你要玩OO 基本也就哪樣, 沒什麼梗. 隨非要套framework 才大一點
漢書, 十幾年沒碰了, 但寫ASM 也沒什麼好說的C 轉ASM 就轉囉,
C 轉ASM 只有哪些現成的function 比較麻煩, 觀念上還比OO 來得好轉

Delphi 的現況是:
要方便, 你得做一個跟別人不同的, 才能有賣錢的點, 否則做個像現在的
不湯不水, 要快沒有, 要特色沒有的, 光靠正確性, 有什麼用?
難道市面上沒有相似的東西嗎?

===================引 用 GrandRURU 文 章===================
每轉一個平台就要學一種語言,不是所有人都是語言天才
要掌握各種語言的特性,也不是一天兩天就可以達成的 (好吧,我承認我有語言障礙)

Lordaeron大所言的也可以套用在低階語言上
「將 Keil C 轉成對應的 ASM,這實在是腦殘到極致的方式,我來寫 ASM 漢書即可,我何苦呢?」

但事實上是?

能用拿手的語言寫出各式的平台,就算效能差點,能達到正確的結果才是重要的不是?

===================引 用 Lordaeron 文 章===================
Android 方面, 現在做的是偷雞法, 將pascal 轉成對應的java
這實在是腦殘到極致的方式, 我來寫java 加上eclipse 即可, 我何苦呢?
現在android 最大的問題就是慢, 所以google 才又弄個NDK 出來解決這問題.
delphi 應該是往這方向走才對, 將UI 的部分用偷雞法給java, 而其它部分, 就一樣是
native code. 這樣才顯得出價值所在.

而iOS 的部跟, 跟來鬧的沒兩樣, 完全無法抓到iOS 的核心, 無法像obj-C 哪樣寫
也是採偷雞的轉法, 實在是引不起太多的回響是必然的.

要成覇業, 又不想流血衝突, 這是不可能的, 歷史上從未發生過.

轉換工具, 我沒說要, 我也不期待, 人人的寫法習慣不同.
只要是轉換的方法, 有個方式, 有個方向能快點轉, 才是正路.

===================引 用 GrandRURU 文 章===================
10年來,官方連 BDE to DBX 的轉換工具都沒出現了, VCL to FMS?
你有得想囉,哈!
===================引 用 Lordaeron 文 章===================
...43...
而framework FMS 的部分, bug 也太多了點. 先集中人手來清理bug, 作一個VCL to FMS 的轉換方式, 以及為各平台加速吧.
...43...
編輯記錄
Lordaeron 重新編輯於 2012-02-10 22:03:42, 註解 無‧
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#17 引用回覆 回覆 發表時間:2012-02-12 17:39:14 IP:111.240.xxx.xxx 訂閱
這個站上 絕大多數的程式設計師, 學習一套從未接觸過的新語言或工具,
大概只要一周就可以學到80%的相關知識,
這實在是沒有甚麼好拿來說嘴的

問題在於剩下的20% 大概需要個3年5年甚至更久 才能慢慢補齊
最現實的是 一套成功的產品 就是需要100%的知識 才有辦法達成

舉我自己的例子 當年我從VB轉到Delphi ,起初的一個禮拜我就認為我全部都了解 ,
而且也能利用Delphi 做出完美的產品

實際上是 產品已經出貨了 我才發現TBCD類別有bug, 間接造成客戶嚴重的損失

我大概是寫了3年的Delphi 後 才慢慢領悟到 如何用package 來完美切割佈局程式

很多東西是只能意會的 , 書上不會寫 前輩不會講 自己遇到才會慢慢明白
你已經知道只要怎樣做 就可以沒問題 這都是長時間經驗的累積
一下子就拋棄這些經驗 是十分不智的

我自己認為 現在的Delphi團隊 是知道自己在做啥 舉RTTI來說 D2009加入泛形
2010就開始對RTTI有大幅功能性的發展 到現在XE2 RTTI也還在演進中
這對早繫結的語言 可是一大福音 漸進式的發展 才是王道


我相信Delphi對自己未來要如何發展 是了然於胸 為了行銷而提出過度時期的做法是在所難免
一來試水溫 二來打廣告 這對公司經營是正確作法

PD大說得沒錯 VCL和wn32牽扯太深 要跨平台是不會成功的 ,CLX就是個例子
各位想要FireMonkey跨平台 就辛苦點吧 不然也可以用RemObjects Hydra 作漸進式的轉移

雖然我在工作上 已經幾乎不用Delphi了 但我相信 他還會在Native 市場稱王


===================引 用 Lordaeron 文 章===================
對我來說, 一本cook book, 一本language reference, 一本API 就夠了, 什麼鬼language (Except prolog and lisp) 都麻是

Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#18 引用回覆 回覆 發表時間:2012-02-12 21:17:53 IP:118.160.xxx.xxx 訂閱
我是不知你的80% 原來是這樣. 哪真的沒什麼好說嘴的了.
哪我沒什麼好講的了.
但要跨平台, 現在的Delphi 的狀況, 可以說, 還久呢.


===================引 用 leveon 文 章===================
這個站上 絕大多數的程式設計師, 學習一套從未接觸過的新語言或工具,
大概只要一周就可以學到80%的相關知識,
這實在是沒有甚麼好拿來說嘴的

問題在於剩下的20% 大概需要個3年5年甚至更久 才能慢慢補齊
最現實的是 一套成功的產品 就是需要100%的知識 才有辦法達成

舉我自己的例子 當年我從VB轉到Delphi ,起初的一個禮拜我就認為我全部都了解 ,
而且也能利用Delphi 做出完美的產品

實際上是 產品已經出貨了 我才發現TBCD類別有bug, 間接造成客戶嚴重的損失

我大概是寫了3年的Delphi 後 才慢慢領悟到 如何用package 來完美切割佈局程式

很多東西是只能意會的 , 書上不會寫 前輩不會講 自己遇到才會慢慢明白
你已經知道只要怎樣做 就可以沒問題 這都是長時間經驗的累積
一下子就拋棄這些經驗 是十分不智的

我自己認為 現在的Delphi團隊 是知道自己在做啥 舉RTTI來說 D2009加入泛形
2010就開始對RTTI有大幅功能性的發展 到現在XE2 RTTI也還在演進中
這對早繫結的語言 可是一大福音 漸進式的發展 才是王道


我相信Delphi對自己未來要如何發展 是了然於胸 為了行銷而提出過度時期的做法是在所難免
一來試水溫 二來打廣告 這對公司經營是正確作法

PD大說得沒錯 VCL和wn32牽扯太深 要跨平台是不會成功的 ,CLX就是個例子
各位想要FireMonkey跨平台 就辛苦點吧 不然也可以用RemObjects Hydra作漸進式的轉移

雖然我在工作上 已經幾乎不用Delphi了 但我相信 他還會在Native 市場稱王


===================引 用 Lordaeron 文 章===================
對我來說, 一本cook book, 一本language reference, 一本API 就夠了, 什麼鬼language (Except prolog and lisp) 都麻是

P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#19 引用回覆 回覆 發表時間:2012-02-21 23:08:11 IP:118.169.xxx.xxx 未訂閱
所有的事情都一定有支持者與反對者, 我認為是再也平常不過的, 雖然這是一個互動連絡園地, 但我認為各位相互討論當中, 可以保持更平和的方式來談論, 不要擦槍走火, 那就是一件最美好的呼應!
系統時間:2024-03-29 21:53:36
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!