感恩DELPHI的衰落

[圣手书生肖让]

我可以算是一个酷爱Delphi的人。97年毕业于清华计算机系，在学校期间我就开始使用Delphi。后来在工作中我曾经用PB，JAVA，C#，但是所有我自己的软件都使用Delphi开发。Delphi开发工具的优雅与高效，是每一个公正的人有目共睹的。从我个人的角度，以后基本会持续使用Delphi作为基本的开发工具。

而我的题目是感恩Delphi的衰落。

曾几何时，Delphi作为常用的软件开发工具，在社会上得到大量公司的认可。搞Delphi的人可以轻松地更换工作。我个人对Delphi的熟练掌握和热爱达到了如此的高度，那个时候我感觉有信心用Delphi开发各种软件（包括网站和设备驱动程序），而且感觉在Delphi中去研究一些未知课题充满了乐趣。更奇妙的是对Delphi的热爱并没有阻止我进入其他编程语言，我很有兴味地去研究Lisp，proLog等让我感到有趣的语言，就像有朋友指出的，真正掌握了Delphi的人，进入其他语言会相当容易。不断提高编程水平几乎就是那个时候的全部主题。因为Delphi编程的工作给我带来了在当时看起来还算不错的收入和在当时看起来不错的职业身份，所以我有充足的心情去继续研究。

但是！

如果那个时代持续到现在，我只怕我自己仍然沉浸在对编程的执着中。我不知道经过这么长时间的持续研究，Delphi水平将会达到何种境界；但可以肯定，我将没有时间和动力去了解那更广阔的真实世界。

Delphi的衰落，让我同时看透了其他编程语言的前途。我认识到了无论什么语言，都有它自己的生存周期，不可以作为长久的追求。Delphi时代的衰落，似乎同时也释放了程序语言的种类，许多以前未曾听说过的语言都有公司在用，但是每种语言都没有了当年的那种走遍天下的感觉。我甚至听到过用Java的同事也在抱怨JAVA语言越来越不吃香了。

这一切，都促使我，放弃了对于编程——我当年的最擅长的技能的执着。感恩Delphi的衰落！

当然中间的经历，不想仔细讲，不过请想一下，一个熟悉了编程高手的身份的人，开始去艰难地做一些原先不甚了解的事情，经常刚刚毕业的大学生都似乎比我懂得多。公允地说，这种感受通常不被认为是很美妙的。

又过了很久，我可以自己做一些事情，我忽然发现，以前的编程经历对我大有帮助。当我进行一些数据分析的时候，我可以提出相当有效的算法，并可以很快地实现。我渐渐意识到，当我哦放弃了对编程的执着之后，编程反而开始真正能给我的生活带来帮助。感恩Delphi的衰落！

还有一个值得一提的变化是，当我执着于自己编程的时候，有一种困扰一直存在：每当看到一个新技术，我所想的就是怎么（用Delphi）去实现。似乎有一种竞争之心在逼迫我。而当Delphi衰落之后，我认识到，即使有相当多的技术问题我不能自己去实现它也不是什么值得注意的事情。有了这种意识，反而可以开始真正欣赏技术进步带来的新的更加广阔的天地。感恩Delphi的衰落！

[hsfzxjy]

因为NOIP，我与pascal结缘。可以说，pascal是最接近于人类语言的编译型语言。C/C 语系那丑陋的大括号，让人望而生畏。 宝兰败就败在没有将pascal标准化。看如今的java,c#等，还不都出自一个老祖宗？C标准化了，便可以繁衍后代，可以生存下去。如果当年pascal也标准化了，当今语言形势决不是这个局面。 泛型怎么了？反射怎么了？当年我们没有这些东西，程序照样跑，跑得比VC，VB快N倍！不要忘了，delphi是曾经的VBKiller！ 楼主说的对：万物兴衰是一个轮回。兴衰交替，天下方能生生不息。语言竞争也是如此。相信在不久的将来，delphi会寻回往日的辉煌。

[sztony]

光是从计算机语言学本身来说，PASCAL风格确实C要好得多， 严谨、简练、容易阅读和使用，是PASCAL系的最大优点。 PASCAL系是学院派系搞出来，C是工程需要搞出来的。用过这二个语言后，就非常感受这点。

[helyna]

引用 44 楼 u011512342 的回复:

请不要说Delphi“跑得比VC，VB快N倍”这种自欺欺人的话了，跑得比VB快当然毫无疑问，比c/C++快就难说了，都是native语言，执行效率如何看写代码人的功力。难道跟std::string比一下赋值速度，就说比C++快了？ 深入学习使用过其它语言的人是不会有这么肤浅的认识的。 Delphi的优势是界面设计方便、开发门槛低、配置简单。但也正是这些原因，造就了一大批水平奇差的程序员，体现在很多人用了好几年Delphi，写的代码也不少，仍然： 1. 不懂library path、browse path、runtime package、design package、链接dcu、链接dcp、bpl模块化开发。不懂得建立合理的project目录结构，为源代码（pas,dpr）、目标文件（dcu），输出文件（dll,exe,bpl）分类存储。不认同的，请手动安装整套DevExpress控件，安装完后，删除所有非必需文件，只留下支持正常使用这套控件的dcu,dfm,res等文件 2. 不懂event handler里Sender参数的具体意义、string+string背后发生了什么。不懂string、AnsiString、WideString、PChar、PAnsiChar、PWideChar、array [m..n] of Char、 array [m..n] of AnsiChar、array [m..n] of WideChar的区别，进行一些库函数调用传递不严格匹配的参数时它们的隐式转化以及由此产生的开销。 3. 没有理解继承和多态、virtual、abstract、override、overload、reintroduce等关键字的用途。不能熟练甚至根本不懂进行面向对象设计和开发。体现在软件中一切窗体都是直接从TForm派生、项目中一大堆重复或高度相似的代码。 4. 对诸如TCP、UDP、进程、线程、同步，基本数据结构和算法等一些基础知识的了解几乎为0. 以上所有问题，从Delphi论坛版块上充斥的基础得不能再基础、低级得不能再低级的提问上就可以看出。 最后说一句，做开发多年，如果没有掌握一些所有语言、所有平台都共通的基础知识和基本能力，就太失败了。

不管是C还是DELPHI，最终还是生产汇编，效率问题和语言无关，和编译器有关。

[Hank]

引用 44 楼 u011512342 的回复:

请不要说Delphi“跑得比VC，VB快N倍”这种自欺欺人的话了，跑得比VB快当然毫无疑问，比c/C++快就难说了，都是native语言，执行效率如何看写代码人的功力。难道跟std::string比一下赋值速度，就说比C++快了？ 深入学习使用过其它语言的人是不会有这么肤浅的认识的。 Delphi的优势是界面设计方便、开发门槛低、配置简单。但也正是这些原因，造就了一大批水平奇差的程序员，体现在很多人用了好几年Delphi，写的代码也不少，仍然： 1. 不懂library path、browse path、runtime package、design package、链接dcu、链接dcp、bpl模块化开发。不懂得建立合理的project目录结构，为源代码（pas,dpr）、目标文件（dcu），输出文件（dll,exe,bpl）分类存储。不认同的，请手动安装整套DevExpress控件，安装完后，删除所有非必需文件，只留下支持正常使用这套控件的dcu,dfm,res等文件 2. 不懂event handler里Sender参数的具体意义、string+string背后发生了什么。不懂string、AnsiString、WideString、PChar、PAnsiChar、PWideChar、array [m..n] of Char、 array [m..n] of AnsiChar、array [m..n] of WideChar的区别，进行一些库函数调用传递不严格匹配的参数时它们的隐式转化以及由此产生的开销。 3. 没有理解继承和多态、virtual、abstract、override、overload、reintroduce等关键字的用途。不能熟练甚至根本不懂进行面向对象设计和开发。体现在软件中一切窗体都是直接从TForm派生、项目中一大堆重复或高度相似的代码。 4. 对诸如TCP、UDP、进程、线程、同步，基本数据结构和算法等一些基础知识的了解几乎为0. 以上所有问题，从Delphi论坛版块上充斥的基础得不能再基础、低级得不能再低级的提问上就可以看出。 最后说一句，做开发多年，如果没有掌握一些所有语言、所有平台都共通的基础知识和基本能力，就太失败了。

我也认为，这才是Delphi衰落相当大的原因！ 基于Delphi的定位，国内使用Delphi的，基本上都是创业型的小型软件公司，产品主要是各种、各行各业数据库管理软件，尤其是桌面型管理软件。 Delphi易学好用->门槛很低->垃圾程序员太多->企业规模扩大不得不淘汰此类人，同时工资也不高，高水平的逐渐放弃Delphi->Delphi烂掉了。 整体来说，IT人学历和能力是成正比的，Delphi开发的毕业学校比VC、JAVA等整体差一截，很多人搞了几年D还处于拖拉控件的水平，一旦卡住，直接找控件，作为一个搞产品的公司，是不允许出现这种情况的。那么结果只有一个选择，放弃DELPH Delphi的没落有很多原因，以上这个原因，在中国大陆地区，至少占40%权重，另外40%就是版权、市场问题。

[ksjxqy]

引用 47 楼 Hank 的回复:

我也认为，这才是Delphi衰落相当大的原因！ 基于Delphi的定位，国内使用Delphi的，基本上都是创业型的小型软件公司，产品主要是各种、各行各业数据库管理软件，尤其是桌面型管理软件。 Delphi易学好用->门槛很低->垃圾程序员太多->企业规模扩大不得不淘汰此类人，同时工资也不高，高水平的逐渐放弃Delphi->Delphi烂掉了。 整体来说，IT人学历和能力是成正比的，Delphi开发的毕业学校比VC、JAVA等整体差一截，很多人搞了几年D还处于拖拉控件的水平，一旦卡住，直接找控件，作为一个搞产品的公司，是不允许出现这种情况的。那么结果只有一个选择，放弃DELPH Delphi的没落有很多原因，以上这个原因，在中国大陆地区，至少占40%权重，另外40%就是版权、市场问题。

如果是凭真正实力考上名校（没有各种各样加分、潜规则、本地户口降低分数线等），那基本上学历和能力（尤其是学习和掌握新技术的能力）成正比。下三滥的院校学历，等同于无。

[fox600123]

丢乸码，看着看着又逐渐演变成浮躁的装逼表演贴，扫兴。

[日立奔腾浪潮微软松下联想]

喷又不违法...

[自然静]

我觉得的你说的甚是，马克一下。 兄弟也可以慢慢开博把这些道理撸一撸，造福水平低的大家。

引用 44 楼 u011512342 的回复:

请不要说Delphi“跑得比VC，VB快N倍”这种自欺欺人的话了，跑得比VB快当然毫无疑问，比c/C++快就难说了，都是native语言，执行效率如何看写代码人的功力。难道跟std::string比一下赋值速度，就说比C++快了？ 深入学习使用过其它语言的人是不会有这么肤浅的认识的。 Delphi的优势是界面设计方便、开发门槛低、配置简单。但也正是这些原因，造就了一大批水平奇差的程序员，体现在很多人用了好几年Delphi，写的代码也不少，仍然： 1. 不懂library path、browse path、runtime package、design package、链接dcu、链接dcp、bpl模块化开发。不懂得建立合理的project目录结构，为源代码（pas,dpr）、目标文件（dcu），输出文件（dll,exe,bpl）分类存储。不认同的，请手动安装整套DevExpress控件，安装完后，删除所有非必需文件，只留下支持正常使用这套控件的dcu,dfm,res等文件 2. 不懂event handler里Sender参数的具体意义、string+string背后发生了什么。不懂string、AnsiString、WideString、PChar、PAnsiChar、PWideChar、array [m..n] of Char、 array [m..n] of AnsiChar、array [m..n] of WideChar的区别，进行一些库函数调用传递不严格匹配的参数时它们的隐式转化以及由此产生的开销。 3. 没有理解继承和多态、virtual、abstract、override、overload、reintroduce等关键字的用途。不能熟练甚至根本不懂进行面向对象设计和开发。体现在软件中一切窗体都是直接从TForm派生、项目中一大堆重复或高度相似的代码。 4. 对诸如TCP、UDP、进程、线程、同步，基本数据结构和算法等一些基础知识的了解几乎为0. 以上所有问题，从Delphi论坛版块上充斥的基础得不能再基础、低级得不能再低级的提问上就可以看出。 最后说一句，做开发多年，如果没有掌握一些所有语言、所有平台都共通的基础知识和基本能力，就太失败了。

[2000年的六年级三好学生]

引用 44 楼 u011512342 的回复:

请不要说Delphi“跑得比VC，VB快N倍”这种自欺欺人的话了，跑得比VB快当然毫无疑问，比c/C++快就难说了，都是native语言，执行效率如何看写代码人的功力。难道跟std::string比一下赋值速度，就说比C++快了？ 深入学习使用过其它语言的人是不会有这么肤浅的认识的。 Delphi的优势是界面设计方便、开发门槛低、配置简单。但也正是这些原因，造就了一大批水平奇差的程序员，体现在很多人用了好几年Delphi，写的代码也不少，仍然： 1. 不懂library path、browse path、runtime package、design package、链接dcu、链接dcp、bpl模块化开发。不懂得建立合理的project目录结构，为源代码（pas,dpr）、目标文件（dcu），输出文件（dll,exe,bpl）分类存储。不认同的，请手动安装整套DevExpress控件，安装完后，删除所有非必需文件，只留下支持正常使用这套控件的dcu,dfm,res等文件 2. 不懂event handler里Sender参数的具体意义、string+string背后发生了什么。不懂string、AnsiString、WideString、PChar、PAnsiChar、PWideChar、array [m..n] of Char、 array [m..n] of AnsiChar、array [m..n] of WideChar的区别，进行一些库函数调用传递不严格匹配的参数时它们的隐式转化以及由此产生的开销。 3. 没有理解继承和多态、virtual、abstract、override、overload、reintroduce等关键字的用途。不能熟练甚至根本不懂进行面向对象设计和开发。体现在软件中一切窗体都是直接从TForm派生、项目中一大堆重复或高度相似的代码。 4. 对诸如TCP、UDP、进程、线程、同步，基本数据结构和算法等一些基础知识的了解几乎为0. 以上所有问题，从Delphi论坛版块上充斥的基础得不能再基础、低级得不能再低级的提问上就可以看出。 最后说一句，做开发多年，如果没有掌握一些所有语言、所有平台都共通的基础知识和基本能力，就太失败了。

大神所言极是。我工作三年，好在对以上所有问题，都有些了解了。现在我还是在用Delphi，其他的语言和工具用得不多。Delphi的问题在于，有些技术更新不及时，没办法查资料，而.Net在网上能查到的资料和方法一大把。然而这也是强迫我使用Delphi进步的原因，Delphi的大多数三方组件与本身的VCL，都可以追溯到原代码，祖宗类TObject，所有的实现机制五脏六腑都是可见的，于是有心学习的人，便可以在祖宗群里面挑一个合适的类，用于继承，用于实现自己的复用的组件，封Dpk。.Net上却大多框架不开放，初学者看不到，只能到网上查查资料和接口。知其然不知其所以然。

[lenswell]

纠结什么语言干嘛，有面包才是硬道理

[haitao]

44 楼 u011512342 的回复: 请不要说Delphi“跑得比VC，VB快N倍”这种自欺欺人的话了，跑得比VB快当然毫无疑问，比c/C++快就难说了，都是native语言，执行效率如何看写代码人的功力。难道跟std::string比一下赋值速度，就说比C++快了？ 没人会说delphi的程序会比vc的快吧？ 专门看了一下，好像就是我说过： 开发效率和运行效率的同时高，除了delphi，以前没有，到现在也还是没有 开发也快，运行也快 怎么就被理解为delphi比vc还要快了？ 我一直认为 delphi程序的运行速度大约是vc的98%左右（普遍情况）

[shien00000xu]

真是一篇文章引起的*案

[xjlqlqlq]

来吧，这有delphi工作。

[eagleblueII]

我跟楼主岁数差不多 从DELPHI2就开始用了一直用到了DELPHI6,没错就是D6，直到现在我60%的编程工作还在用D6（虽然我的编程工作已经不多了） 楼主从DELPHI的衰落 体悟到人生中不应仅仅局限在这狭小的编程空间中，是件值得祝贺的事情。

[lyhoo163]

希望D能重现辉煌。

[lobtao]

管理系统用java+flex，和开发delphi一样的。delphi开发效率和其相当，部署方面，绿色方面，远不如java+flex，性能方面表情不如，跨平台方面更更不如。

[haitao]

引用 59 楼 lobtao 的回复:

管理系统用java+flex，和开发delphi一样的。delphi开发效率和其相当，部署方面，绿色方面，远不如java+flex，性能方面表情不如，跨平台方面更更不如。

它的前端是 浏览器 还是 浏览器+java applet？ 性能比delphi的应用好？ 跨平台？不同浏览器、版本的兼容性不用考虑？

[haitao]

引用 60 楼 sz_haitao 的回复:

[quote=引用 59 楼 lobtao 的回复:] 管理系统用java+flex，和开发delphi一样的。delphi开发效率和其相当，部署方面，绿色方面，远不如java+flex，性能方面表情不如，跨平台方面更更不如。

它的前端是 浏览器 还是 浏览器+java applet？ 性能比delphi的应用好？ 跨平台？不同浏览器、版本的兼容性不用考虑？[/quote] 哦是 浏览器+flash(as语言)，与ie+activex（没脚本语言）差不多了 如果这个activex是我的delphi解释器（把dfm+pas作为脚本）转成的activex，就一模一样了。。。。 当然，activex只能运行在ie，这个是限制 但是性能上，还是慢一点：毕竟都是脚本程序 如果是win32桌面，直接使用客户端，绿色、多层的客户端，性能会最大化

[山东蓝鸟贵薪]

赞美的帖子呀 顶顶

[msb]

还是很喜欢DELPHI