很久没有泡Delphi论坛，最近突然手痒了一下，随便侃侃
到现在.net盛行，c#/java等火热只是，这个问题似乎有点不合时宜。但我无意于为任何一种语言/工具辩驳，只是希望从历史唯物主义的角度来看待这个问题。首先，我们来看一下这么多年来Delphi始终不变的部分，不管是好是坏。
1、文档、帮助
作为Delphi开发人员，相信能够始终意识到Delphi的文档之弱、帮助系统之差。虽然在Delphi 3时帮助系统已经基本够用，但是随着Kylix的推出，Borland试图
把CLX的帮助合并入VCL，当CPPBuilder推出，Borland又进一步试图合并C++/Pascal的vcl帮助；现在又是.NET，每一次的合成都不是很成熟，造成学习Delphi的摸索程度
和其他语言很不同。由于学习的进度每一分的积累都受到很大的考验，因此，Delphi论坛、资源网站一度非常热门，草根力量推动了自傲的Borland持续前进。 Delphi 12(2007)
的早期发行的版本里的帮助甚至是完全不可用的，真是让人感到不满的同时对Delphi一贯的表现方式的稳定程度不得不惊叹一下。2、开放源代码的思想
如果说Linux代表了自由软件开放源代码，那么Delphi基本上可以代表了商业开源的始祖。从一开始，Delphi就携带了大量的VCL, RTL源代码面世，使广大Delphi程序员
其实很早就适应了源代码开放的思想。之后出现了大量的fullsource的第三方免费控件，而且，几乎所有的商业控件都提供源代码销售的选项。这一点，在其他商业开发环境中
确实是非常少见的。开发环境指导了开发人员发布的思想，就好像用VC的同学们发布的产品很少是开放源代码的（不是说免费哦），尤其以VBX, ActiveX控件行业盛行。3、深度OO封装的思想
RAD环境历史上遗留了不少，然而包括VB、PB等很多开发环境都没有贯彻比较深入的OO封装思想，Delphi在这一体系上贯彻比较深入，如果回首VCL的历史，会发现其封装的理念、
实现、发扬一气呵成，所以之后可以比较容易移植到CLX，VCL.NET。所以即使从Delphi 1.0 到现在的 Delphi 12 (2007) ，大多数程序员发现VCL当初是怎样的，现在仍然可以怎样。4、 简洁独立的思想
从第一个版本起, Delphi就没有采用dll这种结构实现最终编译结果的交付，而采用一个相对比较大的可执行文件交付。使应用部署相对比较容易。虽然BDE后来带来不少诟病，但是
包括web开发、multi-tier等各类新的应用形式都可以用极简化的方法交付，这一思想性成为Delphi的很大特点。5、管理层的震动
这一点也成为伴随Delphi成长的习惯，其实Borland有很多机会发展成令人瞩目的企业。就好像他们发布的多层产品、Intraweb、令人叹为观止的编译器。BEA、Sun Java等都是在这个阶段
异军突起，可惜没有一个环节被Borland抓住。在.net前的犹犹豫豫，在native compiler的止步不前，每一样只要深入专注相信都可以达到比较好的结果。管理层始终在摇摆造成
的后继无力成为Delphi的发展主旋律。那么Delphi这些年的变化在哪里呢？1、更低调，更专注
相比当年Inprise运动搞得心神疲惫，如今的Borland分出的CodeGear要务实更多。多年积累下来的老问题们开始逐一解决，开发环境IDE、技术支持、Unicode....
然而现在的Delphi最大的问题是，已经不是Delphi 3独领风骚的阶段，如今的Delphi在RAD的发展上确实落后MS很多步。 MS .NET的战略使开发的门槛降低得很快，在MS VS 2008里甚至包含了
Office 插件开发的模板，而且过去以美工、简单代码编写的asp程序员，也有机会登堂入室，进入C#, ASP.NET的开发环境参与更加广阔RAD项目。然而在.net里除了永远有一些高手引导之余，
永远充满了心浮气躁的小孩子，当表现层本身更加容易设计后，广大的新新程序员很少能够在底层低调积累多年，形成稳固的开发基础。和PB/VB还不一样，由于Delphi本身的灵活性和性能，
在Delphi圈子里有很多积累多年的复合型资深人士。 PB里耕耘多年的结果可能仍然是一个C/S数据库开发人员。2、更愿意接受变化
这包括两个方面，１是产品，２是开发人员。 产品角度，通过不断拓展了ECO, DBX,包括Delphi.NET更加适应潮流。而Delphi开发人员不断思考什么是开发的最核心的环节，通过应用Intraweb、ASP.NET(Delphi)
走向web开发。通过对windows底层理解，更加走向API等深入应用。广大开发人员并没有 C++开发人士的包袱，同时在保留自有风格的前提下，仍然可以向四周小步迈进。在Delphi社区不断掀起的
Delphi还混得下去之类的话题使人们愿意到处观察，寻求、适应变化。３、得到新的发展机会的青睐
就好像不少韩国游戏开发采用Delphi，而很多黑客软件、病毒也会应用到Delphi，逐步地，很多Socket网络应用也用到Delphi。这么多年来Delphi其实从来不曾鼓吹在这些领域的应用，原因是因为
大多数此类应用不为Borland/CodeGear带来巨大收入。但事实上，其使用者的广度和深度却始终在增强。这也是为什么不断有人呼唤64bit native Delphi的出现，以及很多api hook等代码以Delphi
的表现形式被发布。其实语言环境在这个过程中，并不是主导因素，核心仍然是开源思想的延续。
在之后的时代里，Delphi未来到底在哪里？我说的Delphi的未来，尤其不是指CodeGear的未来。作为开发的公司本身必须用营收来指导战略，然而Delphi的未来却很清晰。首先是开源精神的延续，随着逐步地发展，哪怕是小企业也需要很多丰富功能的应用软件。过去
仅仅为大公司服务的产品势必面临很大的挑战。而C/C++, Sun Java的开发项目由于配置复杂、应用环境/开发习惯等原因，很难为中小企业的目标进行迁移、拓展。由于简洁的思想性原则和健全的封装思想，Delphi的应用会
较容易被读懂、移植，开放源代码的力量可以被很好的扩展。
其次是，更多面手的发展方向。越来越多的应用变得更加复杂，从后台引擎、前台界面到中间加密、压缩、转换以及从过去的单一的通讯方式，走向穿越、P2P等各类通讯方式。而操作系统本身类似Vista/2008带来更多的
安全限制和规范造成不得不在很多环节下更深入和操作系统结合才能完成很多商业任务。所以Delphi本身和Delphi开发人员都不要拒绝这一未来的到来，更大的发展空间，不仅仅是数据库开发。
再次是，商业应用框架的发展。现在的Delphi社区有不少开源，但是缺少框架。将来的RAD发展方向从过去把软件从１年开发缩减到半年会进一步压缩到１个月甚至１周。必须高质量交付更快更强的应用成为下一代RAD的主要挑战，
设计模式等都是为了解决大型项目，而更多的项目可以通过应用框架来完成。商业应用框架的发展成为CodeGear和Delphi本身的关键，这可能是下一步Delphi商业软件和开源方向的重要目标。 网上已经有了一些例如aspxdelphi.net等项目具备了这类思想，从这一点看，整个社区、开源精神、简洁化和强力的封装思想组成了这一道路发展的重要前提，所以在我看来，Delphi、Delphi开发人员的路非常广阔，只是需要持续专注的前进。
到现在.net盛行，c#/java等火热只是，这个问题似乎有点不合时宜。但我无意于为任何一种语言/工具辩驳，只是希望从历史唯物主义的角度来看待这个问题。首先，我们来看一下这么多年来Delphi始终不变的部分，不管是好是坏。
1、文档、帮助
作为Delphi开发人员，相信能够始终意识到Delphi的文档之弱、帮助系统之差。虽然在Delphi 3时帮助系统已经基本够用，但是随着Kylix的推出，Borland试图
把CLX的帮助合并入VCL，当CPPBuilder推出，Borland又进一步试图合并C++/Pascal的vcl帮助；现在又是.NET，每一次的合成都不是很成熟，造成学习Delphi的摸索程度
和其他语言很不同。由于学习的进度每一分的积累都受到很大的考验，因此，Delphi论坛、资源网站一度非常热门，草根力量推动了自傲的Borland持续前进。 Delphi 12(2007)
的早期发行的版本里的帮助甚至是完全不可用的，真是让人感到不满的同时对Delphi一贯的表现方式的稳定程度不得不惊叹一下。2、开放源代码的思想
如果说Linux代表了自由软件开放源代码，那么Delphi基本上可以代表了商业开源的始祖。从一开始，Delphi就携带了大量的VCL, RTL源代码面世，使广大Delphi程序员
其实很早就适应了源代码开放的思想。之后出现了大量的fullsource的第三方免费控件，而且，几乎所有的商业控件都提供源代码销售的选项。这一点，在其他商业开发环境中
确实是非常少见的。开发环境指导了开发人员发布的思想，就好像用VC的同学们发布的产品很少是开放源代码的（不是说免费哦），尤其以VBX, ActiveX控件行业盛行。3、深度OO封装的思想
RAD环境历史上遗留了不少，然而包括VB、PB等很多开发环境都没有贯彻比较深入的OO封装思想，Delphi在这一体系上贯彻比较深入，如果回首VCL的历史，会发现其封装的理念、
实现、发扬一气呵成，所以之后可以比较容易移植到CLX，VCL.NET。所以即使从Delphi 1.0 到现在的 Delphi 12 (2007) ，大多数程序员发现VCL当初是怎样的，现在仍然可以怎样。4、 简洁独立的思想
从第一个版本起, Delphi就没有采用dll这种结构实现最终编译结果的交付，而采用一个相对比较大的可执行文件交付。使应用部署相对比较容易。虽然BDE后来带来不少诟病，但是
包括web开发、multi-tier等各类新的应用形式都可以用极简化的方法交付，这一思想性成为Delphi的很大特点。5、管理层的震动
这一点也成为伴随Delphi成长的习惯，其实Borland有很多机会发展成令人瞩目的企业。就好像他们发布的多层产品、Intraweb、令人叹为观止的编译器。BEA、Sun Java等都是在这个阶段
异军突起，可惜没有一个环节被Borland抓住。在.net前的犹犹豫豫，在native compiler的止步不前，每一样只要深入专注相信都可以达到比较好的结果。管理层始终在摇摆造成
的后继无力成为Delphi的发展主旋律。那么Delphi这些年的变化在哪里呢？1、更低调，更专注
相比当年Inprise运动搞得心神疲惫，如今的Borland分出的CodeGear要务实更多。多年积累下来的老问题们开始逐一解决，开发环境IDE、技术支持、Unicode....
然而现在的Delphi最大的问题是，已经不是Delphi 3独领风骚的阶段，如今的Delphi在RAD的发展上确实落后MS很多步。 MS .NET的战略使开发的门槛降低得很快，在MS VS 2008里甚至包含了
Office 插件开发的模板，而且过去以美工、简单代码编写的asp程序员，也有机会登堂入室，进入C#, ASP.NET的开发环境参与更加广阔RAD项目。然而在.net里除了永远有一些高手引导之余，
永远充满了心浮气躁的小孩子，当表现层本身更加容易设计后，广大的新新程序员很少能够在底层低调积累多年，形成稳固的开发基础。和PB/VB还不一样，由于Delphi本身的灵活性和性能，
在Delphi圈子里有很多积累多年的复合型资深人士。 PB里耕耘多年的结果可能仍然是一个C/S数据库开发人员。2、更愿意接受变化
这包括两个方面，１是产品，２是开发人员。 产品角度，通过不断拓展了ECO, DBX,包括Delphi.NET更加适应潮流。而Delphi开发人员不断思考什么是开发的最核心的环节，通过应用Intraweb、ASP.NET(Delphi)
走向web开发。通过对windows底层理解，更加走向API等深入应用。广大开发人员并没有 C++开发人士的包袱，同时在保留自有风格的前提下，仍然可以向四周小步迈进。在Delphi社区不断掀起的
Delphi还混得下去之类的话题使人们愿意到处观察，寻求、适应变化。３、得到新的发展机会的青睐
就好像不少韩国游戏开发采用Delphi，而很多黑客软件、病毒也会应用到Delphi，逐步地，很多Socket网络应用也用到Delphi。这么多年来Delphi其实从来不曾鼓吹在这些领域的应用，原因是因为
大多数此类应用不为Borland/CodeGear带来巨大收入。但事实上，其使用者的广度和深度却始终在增强。这也是为什么不断有人呼唤64bit native Delphi的出现，以及很多api hook等代码以Delphi
的表现形式被发布。其实语言环境在这个过程中，并不是主导因素，核心仍然是开源思想的延续。
在之后的时代里，Delphi未来到底在哪里？我说的Delphi的未来，尤其不是指CodeGear的未来。作为开发的公司本身必须用营收来指导战略，然而Delphi的未来却很清晰。首先是开源精神的延续，随着逐步地发展，哪怕是小企业也需要很多丰富功能的应用软件。过去
仅仅为大公司服务的产品势必面临很大的挑战。而C/C++, Sun Java的开发项目由于配置复杂、应用环境/开发习惯等原因，很难为中小企业的目标进行迁移、拓展。由于简洁的思想性原则和健全的封装思想，Delphi的应用会
较容易被读懂、移植，开放源代码的力量可以被很好的扩展。
其次是，更多面手的发展方向。越来越多的应用变得更加复杂，从后台引擎、前台界面到中间加密、压缩、转换以及从过去的单一的通讯方式，走向穿越、P2P等各类通讯方式。而操作系统本身类似Vista/2008带来更多的
安全限制和规范造成不得不在很多环节下更深入和操作系统结合才能完成很多商业任务。所以Delphi本身和Delphi开发人员都不要拒绝这一未来的到来，更大的发展空间，不仅仅是数据库开发。
再次是，商业应用框架的发展。现在的Delphi社区有不少开源，但是缺少框架。将来的RAD发展方向从过去把软件从１年开发缩减到半年会进一步压缩到１个月甚至１周。必须高质量交付更快更强的应用成为下一代RAD的主要挑战，
设计模式等都是为了解决大型项目，而更多的项目可以通过应用框架来完成。商业应用框架的发展成为CodeGear和Delphi本身的关键，这可能是下一步Delphi商业软件和开源方向的重要目标。 网上已经有了一些例如aspxdelphi.net等项目具备了这类思想，从这一点看，整个社区、开源精神、简洁化和强力的封装思想组成了这一道路发展的重要前提，所以在我看来，Delphi、Delphi开发人员的路非常广阔，只是需要持续专注的前进。
解决方案 »
- 请教一个ADO语法问题，为什么提示类型不匹配
- 一个关于不同WINDOWS用户连接SQLSERVER的问题...
- 【版務】在delphi版發布點XXX鏈接送QQ號或送其它之類的廣告, 一律封弒!
- 一个数据库插入语句的问题，比较奇怪
- 我要做一个通用的票据打印的程序,想用fastReport实现,希望高手传授思路,万分感激!
- 请教,fasereport能用在activeform中吗,为什么我在设计状态无法提取数据.
- 用qiuckreport做的报表的顶部20mm的内容怎样也不能显示出来的
- 语句中的decodestring是一个delphi的函数吗？
- 招聘兼职DELPHI程序员
- 用mediaplay控件播放一个avi,mpg文件，如何才能不在新窗口中打开
- 如何释放Timage的动态数组对象？
- 在一个数前面加‘0’用SQL语句怎样实现
不说第三方组见，就说一个最简单的切换事件处理：Form1.OnClick := xxx;
你用Java写出来看看？
>>>>>>>>>>>>>>>>>>>>>>>>>>>
你指那些机制？
我们需要强大的框架来解决问题
==================
恰恰相反，这些Delphi库都可以看作是很低层的了，现在软件越来越复杂，实际上需要的是应用框架（Application Frmaework），像Java的Spring，Hibernate等等。一个底层的JCL之类的确可以解决一部分问题，但都只限于实现部分功能，没有办法提供某些应用，例如Logging框架等等。这些才是现在最主流的框架了，以Java和.NET方面成品最多。Delphi这方面只有一个ECO，而且还是.NET部分的。Win32似乎D7时候到现在就没有什么变化。Delphi今后肯定还是一个不错的工具，但是想成为主流，还是需要一些杀手应用的。Ruby就靠着一个Rails就红得发紫了。这方面CodeGear还是需要努点力的。但是你可以看看从头开发一个新产品例如3rdRails会比扩展Delphi来得简单，因为没有这么多历史负担要处理。
Spring与其说是应用框架，不如说是一种开发模式，或者说是开发的“方法论”，并没有对开发本身提供多少有用的功能（诸如Spring DAO都算是一大模块了，简直是可笑）。
而Hibernate，基本上就是一个数据库接口，这种东西，VCL中大把抓，bde、dao、ado、dbexpress、odac... 和垃圾差不多。所谓“Application Framework”，简单地说就是为了提高开发效率提供的“功能集”，强调的是功能、易用性和重用性。
JCL、JVCL、Indy都“都可以看作是很低层的”？？？
那么什么才算是“高层的”？Logging？这也算个“功能”？都不要说底层高层级了。
VCL中拖一个组件，简单写几行代码，甚至不需要写代码，就能实现某些复杂的功能，这才真是面向应用开发的框架，不是胡说八道、故弄玄虚、为了写书凑字的“大师”嘴里喷出来的“皇帝的框架”。至于什么.net，更是不值一批，事实上.net已经失败了，除了asp.net，根本就没什么象样的应用。
VCL绝对不是“历史负担”，而是宝库，没了VCL，Delphi差不多就NOTHING了，还不如用Free Pascal。
就象x86架构，到底是负担还是财富？intel企图甩开x86搞Itanium，不怎么成功，最后还是要往兼容的x86-64上靠，反而让AMD抢了先机。
VCL在提高开发效率、降低开发难度方面是卓有成效的，以后还是要在这个方向继续增强，而不是象java框架那样玩概念，空谈“模式”。java被更简单的脚本语言取代已经是在所难免，只不过一些大企业在java上的投资减缓了它的死亡过程而已。
做没有自己语言的开发工具，总觉得很被动.
delphi,java都在学，都在用
Borland在1998的BorCon上就展示过一个Delphi到Java ByteCode的编译器，可以把Delphi程序编译成Java二进制代码。
但是为了JBuilder的市场，并没有发布这个产品。至于是否虚拟机代码会成为主流，个人觉得也未必。
现在x86/x86-64架构几乎一统天下，连Apple都放弃PPC，生产基于x86的Mac了。
大规模并行机中使用x86处理器的也超过2/3（世界500强的超级计算机使用intel/amd处理器的占大部分）。
非x86架构主要集中在大中型机、图形工作站、还有移动设备。
在这种情况下，虚拟机代码的价值也就大打折扣了。
以上仅为个人意见。:)
现在已经有这种趋势了,不是吗?
C/S是DELPHI本生就有的,
WEB是后来DELPHI用IW或者ECO来实现的
.NET就不多说了
下一步如果能新建VCL通吃的话,嘿嘿,,还有谁不用DELPHI呀.只要语法不变,用多种编译器就行了.
VCL是一个很了不得的东东,大家不要小看了,如果PASCAL是砖的话,那VCL就是房子.而目前VCL这个房子只是在WIN32下修建,现在在.NET下也在修了,至于在UNIX下还有些旧房子.
发现没有,在.NET下也有VCL哟那就是VCL.NET
为什么说VCL了不得呢,因为他自成体系这意为着稍加修改,那就能编码成任何东西.
如果它的编译器能接近DELPHI ，我肯定把DELPHI 扔了。
.net开发web好东西只是目前自己的水平有限而评价,都是上手快,能快速做出实际有用的东西.
所以 delphi 卖了没关系,下面靠我们广大的delphi fans 一起延续
本人2个三角 倒过一次分.发誓这个ID永不升角. 01-02年注册的ID 混6年了.
就等于抓住了核心，那将无往而不利，毕竟软件本身就是一个工具，具体怎么用，还是要靠你的思想！！
当然 我更希望 Delphi 的未来会更好！毕竟她曾陪伴我走过很长很久！！
M$啥时候打压delphi了???
凡是windows下好的开发工具m$是非常欢迎的
甚至还给borland投过资!
而且记住一点pascal <> delphi 永远不等于!