Delphi不差钱，差的是框架+鼓吹！我是不看好目前的java开发模式及其框架（以及java/ws最喜欢的xml），delphi用2
Delphi不差钱，差的是框架+鼓吹！
我是不看好目前的java开发模式及其框架（以及java/ws最喜欢的xml），
delphi用200万能搞定的项目，改用java就得1000万
但是市场就是认java。。。。。
虽然它们自己出新版本（新框架）后，也会严重BS自己旧版本的毛病；
但是出新版本前，这些毛病却是只能被称为“艳若桃花”、神圣不可指责的
但是，框架的确是有意义的
以建楼为例子
建2层楼，用delphi是很快，楼也很不错
但是如果建的是100层楼，在没有框架的情况下，直接使用delphi，一般水平的开发者，就很难建出让人满意的楼了
所以，我是希望delphi能有对应的框架，能让delphi在企业级应用、市场里叫响
巨型的应用，目前是不指望客户会考虑delphi的
但是，中小型的应用，开发、运行（软硬件）成本可以说：delphi用200万能搞定的项目，改用java就得1000万
这一点，应该由熟悉delphi、想用delphi做事情的人实际比较和大力宣扬的
（当然，不利的地方是：现在的一些客户的决策者是看回扣的，项目越贵，回扣自然也就越多；
一些客户的IT人员是赶时髦追名词的，看重的不是成熟稳定性价比，而是流行、时髦：我用了流行、时髦，等于我也挤入流行、时髦的行列了，与其他IT同行交流起来，也就牛X多了）
如果client/webserver（Client/Server的C加上Browser/Webserver的W）能流行，
后端，delphi专心写高效的isapi运行与iis下
前端，delphi写win32客户端是谁都知道的了
两者通过http(s)连接，网络穿透性与b/s基本一样
【
INI@HTTP通讯传输架构（Client/WebServer）： http://szhaitao.blog.hexun.com/37197154_d.html
我有一个梦——应用浏览器： http://szhaitao.blog.hexun.com/8872169_d.html
】
delphi限于win平台是事实
不过，就后台来说，win服务器也是越来越强大了，而且，既然是以iis为应用后台，一旦已有的服务器不够了，再加多少个win服务器加进来就是，只要大家公用一个数据库（它可以是单服务器，也可以是集群；可以是sqlserver也可以是oracle/db2）
pc服务器比起类似规模的中、小型机要便宜多了
另外，kylix虽然已经停止更新了，但是用它写apache的fastcgi之类的后台，应该也完全足够了，这样，后台也就可以换为linux了，前台不会感觉有什么差别
至于delphi写的游戏客户端的庞大，不知道是想与什么比较：java桌面程序？b/s的浏览器？
如果是前者，恐怕也不会比delphi写的小；
如果是后者，就怕浏览器的表现能力、交互效果、响应速度跟不上
商业应用的前端，要求的不是花哨，而是要替日复一日面对它的最终用户考虑：便捷！操作100遍之后，再花哨也都是累赘。
我在dos进入windows时，从borland c++的dos版（3.1）到win版（4.x），感觉没什么太多的跃变；
看过一点vb(4?)，然后就遇到了以前turbo pascal的接班人：Delphi 1.0！
从而走上不归路，15年来就没再改攻其他语言，主要是用过delphi之后的一览众山小（或者说除却巫山不是云）——当然，也许深层的原因是个人眼界小，懒惰
delphi开发（当然，都不是大项目）的得心应手，再用别的语言、平台，实在是觉得太束手束脚了，尤其是java/c#的庞杂
——就像习惯了ini，看到xml就难受（无法忍受xml的解析开销：类似洁癖的性能癖。后来也有一些json之类的东西，也有人开始发出微词了）
曾经接触python，唯一有比delphi还精练的感觉，但是性能低、脚本（代码容易反编译），还有靠缩进来决定代码块的层次，也就没真正用起来——当然，也没有合适的项目需要
至于工作所需的脚本，其实我是把delphi当“脚本”工具来解决机械、重复的繁琐（开发快捷、运行高效、发布简单）
[解决办法]
SF
回复内容太短了！
[解决办法]
同意缺框架
【字数补丁.INI】
[解决办法]
我个人也是希望，Delphi能强大起来，用了这么多年，真是舍不得。
[解决办法]
应用浏览器，Delphi版的RIA？
[解决办法]
部分同意。。
[解决办法]
强烈支持，不过起步太晚了。
[解决办法]
3年Delphi了，真心希望D能越来越好
[解决办法]
回帖，帮顶下！！！！！！
[解决办法]
看看
[解决办法]
学习了！回复内容太短了！
[解决办法]
关注 。
[解决办法]
真心希望Delphi能越来越好
[解决办法]
有300分接,强力插入...
[解决办法]
不利的地方是：现在的一些客户的决策者是看回扣的，项目越贵，回扣自然也就越多
[解决办法]
Delphi 太差錢了。越來越討厭它了。
------解决方案--------------------
delphi就是太容易用了
[解决办法]
同感！希望Delphi越来越好！
[解决办法]
我个人用惯了Delphi,也是希望Delphi能强大起来!
[解决办法]
虽然不会用Delphi，但Delphi的大名一直如雷贯耳。。。 希望Delphi越来越强大！
[解决办法]
美好的愿望，残酷的事实！
[解决办法]
好像有几个高手在开发一个框架，是基于delphi2010的
[解决办法]
回帖，帮顶下！！！！！！
[解决办法]
应该说已死的BORLAND浪费了大量的时间，才让DELPHI有今天的结果。
成也BORLAND,败也BORLAND！
[解决办法]
过来学习下，太短了太短了，杯具啊杯具
[解决办法]
Delph已死，有事烧纸。
[解决办法]
[解决办法]
FlashPlayer纯粹就是个虚拟机了.
感觉DELPHI出个类似的也不错，毕竟以后浏览器更像个小操作系统了。
[解决办法]
除了用DELPHI还不会用别的写HELLOWORD经典程序
[解决办法]
兰州童鞋，
居然还在纠结这个本不是问题的问题。
xml的好处你不能理解那是因为你应用得太肤浅了，
不能体会到这种工业化标准的东西好处到底在哪里。
它可不仅仅是用来存放你的配置数据的，像ini那种弱智的玩具一样。
解析开销也并不像你想象得那么重要，因为它从来都不是bottleneck, 如果是的话，那么毫无疑问，设计出现了问题。
而且现在M$不也是大举的向xml靠拢了吗，并非只是java，ws采用。
如果说框架和鼓吹的话，delphi并不比java差，delphi的控件铺天盖地，几乎可以解决你遇到的任何windows平台的问题，
它的两层和三层架构也非常优秀，虽然是基于M$问题多多，自己也不爱用的com,dcom以及com+技术.
delphi确实不差钱，borland最牛X的时候花费了4亿美金收购了根本不值钱的dbase，这也从一个侧面反映出了borland管理层的弱智和白痴，也是borland的从盛到衰的开始。
那么问题到底出在哪里？是什么导致delphi走向灭亡？
这是值得每个delphier深思的问题。
原因并不是楼主提到的所谓的鼓吹和什么框架。
[解决办法]
忽 悠
[解决办法]
我做过一个事情，用delphi半小时搞定，用JAVA愣是要三四个小时，DELPHI作为快速开发工具还是有相当大的优势的
[解决办法]
[解决办法]——说ini弱智，是你用的浅。我与很多鼓吹xml的比试过：xml能描述什么的，我都可以用ini描述
——比如array1[123].field2，而从ini里取array1[123].field2比xml要高效得多！
******************************************************************
别的不说，就从第一个例子就知道你着相了.
如果ini什么都可以描述的话,那么就是xml了,失去ini本身的意义.
你举的第二个例子,不好意思,本人完全不同意,在OOP的application世界里,你这种简单的所谓高效根本就没有任何意义.
——这样的东西，几年前偶尔在linux下做服务程序（c++/tcp）时，也是很希望能有这样的框架，因为之前只是做过dos的c程序和win下的delphi程序。可惜找到的都是很复杂，上手、熟悉更慢
——不得不自己从头做起：日志、tcp服务、数据库访问、监控输出。。。。。。。
这些恰恰是java的强大之处,和你所鄙视的框架轻松搞定的东西,如果你觉得上手慢非要自己重复发明轮子,那么不好意思,本人完全不同意.本人能下结论就是你的学习能力还是有所欠缺的.
——标题的不差钱，其实意思是：不差技术。不是delphi公司不差钱或delphi开发者不差钱
——borland公司的决策绝对是有大问题。包括现在换了老板，市场占有率这么低了，还在大抓d版。
大错特错,borland的编译器技术是很牛X的,不然gates也不会三顾茅庐把anders挖过去搞.net和java对抗.
可是技术只是公司生存的一个小方面,而且是很小的方面,这点可以用sun公司和盛大作比较.sun也是曾经很牛的公司,技术牛B得一塌糊涂,不论硬件和os方面,单从java得火爆程度就知道sun又多牛,可是目前也被oracle公司收购了,盛大P技术都没有一样火爆.M$当年也不靠技术发家致富的.个中原因大家都很清楚是怎么回事.
你错在,delphi没落不是因为盗版或者是反盗版,相反delphi在中国遍地开花也是因为盗版的普及.就向大家离不开的windows一样,它失败在市场和技术方向定位方面,这点和anders当初离开borland时的高瞻远瞩的原因一样(方向问题和管理层发生了严重的分歧).结果证明anders的英明,borland完蛋了,delphi完蛋了.
[解决办法]
不懂
纯灌水
现在还有人用Delphi？
[解决办法]
[解决办法][解决办法]不是太懂，但是很感兴趣，学习一下，
[解决办法]delphi 好久不用了 不知道啥样了
[解决办法][解决办法]ini能描述复杂的结构、数组，不等于必须像xml一样做成树状才行的，你的思维显然太局限
有局限不要紧，没试过就下结论，则太武断了
---------哈哈,你又错了,ini也是tree型的,只不过层次没有那么深.你不但思维局限而且抽象能力还是不够啊.由此我推断你还是一个程序员而不是总揽全局的架构师.
我已经说delphi不差技术了，你也说“borland的编译器技术是很牛X的”，为什么却还“大错特错”？
---------我的意思很明确,delphi的衰落不是因为差框架(技术上的原因)和鼓吹.大错特错这是针对你标题.
强大且易用 看似矛盾、要求过高，其实vcl比mfc就是这样的完胜
---------你这个结论下得太天真了.如果你很了解mfc的话应该谨慎说这句话.
delphi的反d版绝对太严，以至于真的想参与推广的国内公司都缩手缩脚，这个也无须多说的
我反感这样的愚蠢：市场已经很小了，还不知道先培植。这不是根本原因，但是也是反映当时borland决策昏庸的一个实例。
--------我说过了 盗版和反盗版根本就不是delphi完蛋的原因,不再重复了.
[解决办法][解决办法][解决办法]同意，严重同意
同意，严重同意
同意，严重同意
[解决办法]真是舍不得 我转C#了
[解决办法]呵呵，可能你还没搞清楚我讨论的范围呢，不多言了。
[解决办法]回帖，帮顶下！！！！！！
[解决办法]楼主说的ini的功能如何强可能都是事实，但是有多少人会运用这些高级的功能或技巧就不好说了。
xml能流行不是因为他技术上有多牛，而是刚好顺应了软件的发展趋势。
个人觉得delphi的没落除了公司决策的问题外，功能没有紧跟web大流行的趋势也是一个重要的原因。
[解决办法]部分同意,。。不再参与这个帖子的讨论 ,浪费时间啊
[解决办法]``````````谁交我？ 我转来搞 哈哈
[解决办法]好象什么时候听说ini大小大于多少K时解析会有问题的。不用xml可以用json，ini的初衷本来就只是当配置文件用
------解决方案--------------------
看高手PK，俺们学习。
[解决办法]还是回头说一句，如果你只是把INI看成SECTION对应一个对象，节点对应一个属性，那就是思维上的局限。为什么不可以节点对应一串东西，又或者专门开个SECTION来保存对象间的引用关系之类呢？还是那句，看你序列化和反序列化的机制而已。
至于什么XML的工业标准之类，那是另外一个话题，不谈。
[解决办法]delphi没有好的应用服务器.做一个大的系统,应用服务器可以自己做到集群,负载均衡,资源调度,多线程.....要让每一个开发工程师自己写,那是一个悲剧.所以只能做桌面应用.
[解决办法]支持一下，总结的很好，很详细
[解决办法]Delphi使用者
希望Delphi能再辉煌
[解决办法]php也沒框架, 也能建大站, 基本上還比java建個好, 例如facebook, 所以delphi只欠吹吧
[解决办法]java的跨平台性非常适合做后台开发，再加些XXXX什么的，不多说了。
.net和ms系统的紧密性也不用多说了。
FLASH BUILDER(FLEX）有adobe的 flash player， XX率在那摆着呢.也不多说了。
web开发上，delphi。。。。。
delphi靠什么？....好难过!
涉底层点的，有组件还好说，没有的话，自己来吧。
作应用软件开发应该是“讨厌”涉及底层的东西的....不是不研究，而是没时间。
[解决办法][解决办法]却对 仅仅有版本升级才需要的客户端的自动更新 就无法接受了。
－－－－－－－－－－－－－－
哎，客户一开始就说，能不能点IE就什么出来了呢？另装这装那的了。
[解决办法]考虑用java是长期发展策略 ，快平台，开元 免费， 不会手任何系统或公司限制
delphi写的只能绑死在win上,delphi完蛋自己就完蛋了
[解决办法]像JAVA那样的框架，DELPHI在10年前就欠我们了！现在居然还没有，的确太过分了！
[解决办法]还差高性能的应用中间件。
[解决办法]da家不要只是出于感情
而是要集思广益，提供一些能说服客户（决策者+IT人员）的素材，方便大家汇集、共同使用这些素材ding
[解决办法]很好 很好 很好 很好 很好 很好 很好
[解决办法]强烈支持~!强烈支持
[解决办法]我不会怎么办哪 呵呵
[解决办法]DELPHI能不能做数字图像信号的处理
[解决办法]大家多点创新精神。自然就会越来越好的。
[解决办法]希望Delphi越来越好！
[解决办法]上学那会儿用过delphi ，怀念ing
[解决办法]这学期刚学HTML，菜鸟过来看看
[解决办法]xuexue xiexei
[解决办法]我个人也是希望，Delphi能强大起来，用了这么多年，真是舍不得
[解决办法]大家好,Delphi的兄弟们过的好吗?
[解决办法]请别拿艳照赌明天901901901901901
[解决办法]谢谢楼主，值得学习。
------解决方案--------------------
[解决办法]各有各的好处吧,不过现在流行还是JAVA多点.
[解决办法]有300分接,强力插入...
[解决办法]我不做开发好多年了我不做开发好多年了
[解决办法]对于 ini & xml ……
我也偏向于 ini
就像 bpl & dll，我偏向于 bpl。（除非不得已）
原因是，xml dll 主要考虑的是共享的话题，通常我喜欢的d，而且只喜欢用d ，没有必要共享出去。（除非某些地方必须要用到）。
用简单的手法， 写复杂的程序。是我做程序员的宗旨。
其实，用哪种都无所谓，都有各自的优势和劣势。而且也差不多能共通。
说起框架，我没能理解（本人从来不看java一眼），是不是指 interface ？
最近也在理解这个名词，有兴趣的话，可以一起研究，共同进步。
[解决办法]你们没讨论到点子上，INI文件不是DEPHI的，XML也不是JAVA的，DEPHI可以用XML，JAVA也可以用INI。
比较语言要,要从语言本身上比较。
DEPHI的begin...end和C系语法的{}相比，那个高效那个直观？那个容易维护？仅此一点，DEPHI必败！死抱DEPHI的，必将被时代淘汰。
begin...end是罗嗦至极的语法，真想不明白你们为什么竟然能忍受，浪费了你们生命中的多少时间啊，让学DEPHI,就等于慢性杀人！
当年我一见什么PASCAL/DEPHI那烂语法，就觉得恶心。DEPHIER们你们为什么不恶心呢？
[解决办法]框架没有，可以再写再做，功能没有，可以再加，
可是底层语法设计的根本出了问题，除了废了它，还有什么办法？
[解决办法]而且，还有DELPHI的那破烂IDE,DELPHIER们啊，服了你们啦
[解决办法][解决办法]太极端了 dd
[解决办法]DELPHI不是差鼓吹，当年不是鼓吹说是什么VBKiller吗？结果VB没倒，DELPHI却先亡了，一个先天不足的付不起来的阿斗，再怎么起劲的鼓吹也是无济于事啊！
[解决办法][解决办法]哈哈，看啊，谁说DELPHI就不能用XML了呢？官方都嵌入支持了。我真奇怪，众DELPHIER们，你们以前就没在DELPHI下用COM/DLL的经验么？XML的解析库很多的，MS的，GNU社区的……或者COM，或者DLL，谁说DELPHI不能用XML？
http://news.csdn.net/a/20090911/213665.html
是时候抛弃Delphi 7了
2009-09-11 15:33 | 28391 次阅读 | 【已有6条评论】发表评论
关键词：新闻资讯 | 感谢ydj9931的提供 | 收藏这篇资讯
Delphi 2010已于近日由Embarcadero公司发布。作者Kim Madsen作为一名资深的Delphi开发者，在他的博客中谈到了Delphi 2010的新性能、它的使用感受以及对Delphi语言未来的期望。博文如下：
Delphi 2010使用的第一感觉是：是时候为它抛弃Delphi 7了。
Delphi 2010比以往的Delphi版本都要快，而且它保留了一些Delphi 7的特性，比如可以将旧的条形控件（componentbar）找回。但这同时也带了相关的问题（比如在重启Delphi 2010之后componentbar的位置看起来挪动了），不过这只是细节问题，相信在之后的修补中会解决这个问题。
在D2005, D2006, D2007和 D2009中，IDE中都有不少漏洞，以至于内存会迅速被泄露导致IDE以及电脑的其他部分特别地慢。尽管从D2005到D2009，Delphi已经做了很多努力，但这种漏洞仍然存在，开发者不得不经常重启IDE来避免内存泄露。
然而在Delphi 2010中我们欣喜地发现内存泄露的问题得到了解决，以前我从事很复杂的项目开发，很难做到个把小时都不重启电脑，但现在已经不用重启了。另外，IDE的响应也得到了显著的提升，启动时间比D2009快了不少。
D2010还有许多其他组件的性能提升，但我个人感觉新增的手势支持（gesture support）是个很有趣的特性。手势支持（gesture support）的意思是你可以做出特殊的鼠标移动来向应用发送一个命令信号。就好像是用的不是鼠标而是触摸屏，因此也有可能做出像iPhone的触摸屏一样的界面。我想这是一个很重要的特性，除了手势性能以外，更大的意义在于它表达出了Delphi在桌面端的发展方向。
以前我曾写博文诟病过Delphi在桌面领域的表现，因为像Adobe Flex和MS WPF等开发工具功能强大而齐全，可以以相对简单的方法开发出很酷的客户端应用，而用Delphi却很费劲；我也曾诟病过Delphi在服务器领域的表现，而且它的市场由于Java和.Net而大幅缩水，而且由于缺少跨平台的兼容性、抛弃传统的Kylix编辑器而丧失了Linux的支持，Delphi在竞争对手面前沦为开发者的末端选择。这种境况在今日仍然如此，但是在过去的六个月中，Embarcadero公司宣布计划将支持Mac和Linux的跨平台编译，无疑这是Delphi向前发展的一大步。
由于全新的手势支持以及跨平台的计划，Delphi在未来几年有望赢过竞争对手并重新夺回市场份额。当然这取决于跨平台特性的最终性能，而且 Embarcadero也不应当放松对手势支持的控制和研发，毕竟这是它桌面应用的方向。
那么Delphi还应当在哪些方向继续努力呢？
*改良数据绑定。现在的Delphi唯一的绑定是用特殊的数据源绑定有意识的控制（TDataSource和TDBxxx组件）。这一特性在当年刚推出的时候非常酷，但是它现在已经被.Net和Adobe Flex/Flash 4超越，因为.Net和Adobe Flex/Flash 4有两种方式可以将任何属性绑定到其他属性。因此，需要抛弃现有的Delphi DB控制，增加先进的自动的两种绑定方式。
*优化现有的TCanvas和Device Contexts，从而可以将任何控制放在画布（Canvas）上，让画布自动浮动在3D空间。这将给开发者带来新的用户界面，比现有的2D更有感觉。举个例子：在显示器帧值一定的情况下，如果你想呈现产品清单软件中的多个产品的细节，你就要经常使用目录，点击列表中的项目以在窗口上显示产品的细节，或者添加许多产品标签才能实现。然而这两种方法都不能同时展现产品和信息。如果使用Apple CoverFlow会怎样呢：就可以在3D空间中展示产品信息了。结合手势控制和触摸屏，开发者使用手指就可以浏览产品。虽然它的硬件要求比2D更高，但是现在即便最普通的PC都可以满足这一要求。
在服务器端，我的期望是Delphi可以实现单一来源、多平台支持。
语言特性方面，我期望Delphi：
* XML和正则表达式成为语言的一部分。XML不消多说，正则表达式在字串匹配和许多应用使用的解析设备方面非常有用。为什么不让它们成为Delphi语法的一部分呢？实际上，查看XML的E4X EcmaScript，可以将XML直接整合到语言中，所以看起来Delphi应该可以很自然地使用XML。
除此之外，Embarcadero的开发者还应当考虑如何解决下面的任务来更好地做好Delphi的开发：
* 应用的打包和分配；
*尽管存在各种第三方安装工具，但如今分配到Win32环境还是很复杂。主要的原因是因为需要其他开发工具和语言来创建相关的安装脚本，而且这些脚本的更新周期很快，需要持续不断地更新。
*文档在源代码内提供了各种注释，因而某种程度上它已经成为了开发过程的一部分。我个人很讨厌这种方法，因为它将源散落得到处都是，而现在的文档则是分离式的也很不方便。因此IDE需要提供一种解决方式，既让文档同步，同时又能够将文档和源分开从而可以简单地将文档翻译到其他语言中。
[解决办法]
