盒子论坛 v2.1
自动登陆(30天有效)
≡技术区≡ ①
≡发布区≡ ②
≡事务区≡ ③
最新加入：
今日帖子：
在线用户：
斑竹:liumazi,sephil
(乐天无极)
▲▲△△△
发现一个不错的ERP&C#源码，看完界面，对delphi有些不忒看好
浏览:<font color="#63
软件是这货是赤裸裸开源的，ERP的大型源码――delphi版本的可不多的。软件名称：C#.NET&WinForm&企业ERP管理系统源码(VS.net+SQLServer)开发语言及数据库：(C#&加SQLServer2005)架构：C/S&WinForm控件下载地址：源码下载地址：/share/link?shareid=&uk=解压密码：kmylarERP登录用户名：administrator&密码：1具体地址：
此帖子包含附件: 大小:129.7K
----------------------------------------------
相信自己，若自己都不相信，那还有谁可信。
(乐天无极)
▲▲△△△
<font color="#楼：
还有一个苗头很不对。很多收费的delphi控件，都有.net版的，比如，fastreport那东东，devpress也有的。
----------------------------------------------
相信自己，若自己都不相信，那还有谁可信。
(Flying Wang)
▲▲▲▲△
<font color="#楼：
用&DLEPHI&也能写这么垃圾的东西啊。想写垃圾，不用管语言的。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
大势来看，windows&下的MIS，以后基本是C#的天下。Delphi已经找不到自己的定位了，VCL处于尴尬的位置，EMB想为VCL找个替代品，却又找不到能抗大梁的。&FMX就目前来看，难成气候，抗大梁更是不用谈。给自己画了个美丽的饼：一个代码基，编译到多个平台。结果却选择最不好达到目标的UI这一块进行。&Java，有Orcale这样的大财主背后支持，也没能让Java在UI或者说桌面开发这块跨平台有什么起色，EMB却好高骛远。结果09年至今，5年了，这个FMX还只是玩具。
----------------------------------------------
(乐天无极)
▲▲△△△
<font color="#楼：
这不是垃圾不垃圾的问题，而是C#有现成的源码，同时delphi控件的优势，也会被c#取代。换句话说，delphi的易用性与多重控件的好处，在C#下完全都不是优势。还有C#的oop比delphi更彻底。
----------------------------------------------
相信自己，若自己都不相信，那还有谁可信。
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
还有C#的oop比delphi更彻底。-------这个不见得。我只知道，你C#没装.NET框架就运行不了。这个也能彻底一点吗？？
----------------------------------------------
QQ:&9717005&我的Blog：
▲▲▲▲△
<font color="#楼：
想下载学习一下，但是控件下载地址好像失效了，楼主能否提供一下，谢谢
----------------------------------------------
(乐天无极)
▲▲△△△
<font color="#楼：
还有C#的oop比delphi更彻底――这是肯定的。你自己用建模工具试试，有几款彻底支持建模的。
----------------------------------------------
相信自己，若自己都不相信，那还有谁可信。
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
都是一个爹的孩子，没啥好计较的。
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
(littlecat)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
我们公司正在使用三品的PLM软件delphi7做的，你看看怎么样吧？
----------------------------------------------
泱泱华夏十亿兵,国耻期待儿孙平,愿提十万虎狼旅,跃马扬刀灭东京!
▲▲▲▲▲
<font color="#楼：
to&doorkey&&Win7以后，你还能找到不装.net的windows么。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
就我的经验而言，如果只针特定的开发，c#是好的选择。但现实的操作系统繁多，还有用win2000，xp也不少，所以net的版本真还要考虑的，对于win的系统，想一套通行，暂时用Delphi的win32的模式，几乎能用在Win2000-Win7，包括32/64版，我只能佩服ms他们工作的前瞻性和兼容性，jdk和net版本的兼容性就比不上Ms操作系统，真感觉这帮弄操作系统的家伙太厉害
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
做了十几年的erp，就界面而言，没看到&C#&比&Delphi&好在哪里，用&delphi&做过更漂亮的功能更强大的&UI。但话说回来，delphi好，C#也不错（个人觉得C#&+&MSSQL&效率差一点），能写出什么样的ERP（从UI到功能），不在于开发工具，而是看谁开发，所以，类似这样的题目，我觉得没有讨论的必要。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
做应用开发的，许多都是雕虫小技，大多都是苦力
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
10&正解，楼主是狡辩。3楼是啥都不懂。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
控件下载不了，链接不对
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
易博龙倒没想给VCL找替代品,FMX是跨平台的产物,VCL是Windows开发专用的,各有其擅长领域.两手抓.到今天VCL依然是Windows桌面开发的最佳工具
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
此地址已经无法下载
----------------------------------------------
(DELPHI先生)
▲▲▲▲△
<font color="#楼：
VCL依然是win32开发的首选项，至少目前是这样。
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
对不起楼主，我看错楼号了。是我这个2&楼下面的&2&楼啥都不懂。您只是死鸭子嘴硬而已。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
一看到ERP我就想吐,不知道为什么
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&wr960204&(武稀松)&易博龙倒没想给VCL找替代品&&这个我的确是猜测。然而FMX既然号称是“跨平台”的产物，那么“跨Windows平台”和VCL又是个什么关系呢？“到今天VCL依然是Windows桌面开发的最佳工具”这个很难认同。看看新系统，商家的选择。如果真是“Windows桌面开发的最佳工具”，Delphi的工作岗位至于有这么少么？1.Windows下的桌面软件（通用软件：比如QQ&WPS等等）这种企业需要在整个互联网进行竞争，企业需要的是高质量产品，无论执行速度，应用体积等等。他们需要的是在自己可控的范围内做到产品最优，开发的便利性，开发效率全都是次要问题。&显然C#,Java之类的不符合需求。Delphi呢？Delphi曾经在桌面开发中进入了这些大的互联网企业的选择，&例如WPS&FoxMail等。然而现在Delphi编译器优化效率与VC不能比，VCL框架在碰到Vista&Win7后显示出了明显的不适应。因此，已经没有足够的理由选择Delphi了。周爱民曾经说RAD已死，其立论的主要依据大意主要是，UI的部分应该由专业的美术（职业分工）来完成，而不是程序。我们去看看，QQ，迅雷等等，的确是这样的，他们都封装了一套UI库，界面布局基本由XML配置完成。2.&Windows下的桌面软件（MIS类软件）这种开发的，一般是做行业软件的公司。执行效率，应用体积等都不是核心问题。最核心的问题是开发效率。因此符合Delphi应用开发的特点。这也是为什么现在还有不少做行业软件的公司使用Delphi的原因。然后，即便是这些公司，也都在转型。长期做行业软件比较成功的公司（规模较大的）也开始慢慢积累自己的开发库或者代码。当他们完成了积累之后，这种由开发工具提供的RAD就已经不需要了，他们有更符合自己需求的自己的RAD工具。比如金蝶，曾经是用Delphi&CB的，现在去看，还有什么？还有些规模较小的公司，Delphi目前来说还是个比较合适的选择。然而，随着C#的结合Windows的强势插入。不转C#已经是耗无道理的事情了。3.手机应用？FMX刚出来时，我是持怀疑观望的态度。现在，我持悲观看法。5年的时间，已经可以说明一些问题了。2015年，FMX会起来么？我估计不会有太大的变化。那FMX就是6年了，还需要等多少年？
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
楼上又在丢人现眼。说的好像&DELPHI&不能用&XML&做&UI&似的！说的好像，我的&EXE&不支持&WIN7&8&10&似的！说的好像&那些&FMX&开发都饿死了似的！
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
楼上的，我跟同事兼朋友聊天，请你让让。
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
请你们俩私聊。
----------------------------------------------
▲▲▲▲△
<font color="#楼：
你们还记得胜天进销存吗？&而且是开源的，多少年前的软件了！也是这种界面。
----------------------------------------------
▲▲△△△
<font color="#楼：
又看到，讨论谁好谁不好的...
----------------------------------------------
(似水?流年)
▲▲▲△△
<font color="#楼：
不喜欢Delphi的，认为Delphi不好的，就别用，别在祸害人心，充其量只是在丢人现脸。
----------------------------------------------
我爱Delphi，我用Delphi&
▲▲▲△△
<font color="#楼：
我忍不住要和小周童鞋聊几句了。关于做&UI&方面，你敢说你用过&VC&写过&UI&方面的东西？我若说用&VC&写&UI&是最反人类的事情之一相信会有不少码农认同。“&然而现在Delphi编译器优化效率与VC不能比，VCL框架在碰到Vista&Win7后显示出了明显的不适应。因此，已经没有足够的理由选择Delphi了&”――前半句话，你好歹也摆出点实例出来，譬如用&Delphi&写的&客户端应用&效率是瓶颈――有吗？后半句，我又想起了之前那个橙子（何晓杰）的搞笑言论（大意是&Delphi&写&UI&和&VC&比是渣）――自己水平差就不要口出谬论丢人现眼。你列举&QQ&等例子，那你不应不知道企鹅等在&UI&库方面经历了多少的积累才有这样的成果，你曾经呆过的迅雷难道不一样吗？“&UI的部分应该由专业的美术（职业分工）来完成，而不是程序&”――这样的话其实是废话。至于你说的高质量产品，Skype&算不算？执行速度慢不慢？而&QQ，体积难道不大？哦，你会说它包含了一堆东西（功能）。我也认同&C#&很好，但你一边倒的批判就不对了。我也认为&FMX&做得很不够好，但凡事最好有个对比：对照下&QT，花了多少人力和时间才做得像样――而它的体积，麻烦你也用一下。当然，对于&FMX&的效率问题，改进空间非常大。至于&“&Delphi的工作岗位至于有这么少么&”&等之类话题，确实是很大硬伤。造成这样的局面当然有很多原因，Delphi&自身的不作为（或精确点，没落）当然是非常重要的原因。但你有看到吗，基于&Windows&平台的开发空间越来越小，不单单是&Delphi，C++&之类在这方面一样在没落。所以&Delphi&将重点移向了移动开发方面――但问题是，它还很不够成熟并且，缺少成熟的譬如&cocos2d&等之类框架/开源应用。只将自身定位在所谓的普通&APP&开发远远不够。我之前还一直想看&Delphi&这方面能否成熟起来，现在看来，恐怕无期之约。有坛友说，看到&MIS&就想吐――bingo！我也一样。不知道为什么，只要有扯到&数据库开发、MIS、ERP&等之类，我就毫无兴趣甚至反感，这类应用大家都知道，基本上是，业务逻辑才是根本，市场也早饱和，技术方面快糙猛，我真不觉得有什么好讨论的。做技术的眼光要放远点，眼界要大一点，不要总是因为一些实在低级不过的东西而喋喋不休。有这精力，不如谈谈风月。
----------------------------------------------
人生若只如初见
▲▲▲△△
<font color="#楼：
正如&@lsoft&童鞋说的，东西写得好不好，（绝）大部分情况下还是要看是谁写的。确实有部分应用开发方面，C#&取代了&Delphi，而这很大原因是因实在招不到&合适的&Delphi&码农了。像&C#&这样，入门也快，用起来也顺手，同一个爹搞的东西，RAD&方面应该仅次于&Delphi&，当然是好选择。P.S：WPS&以前&UI&部分是&Delphi（7）&开发的，前几年换成&QT&了，而换&QT&的最主要原因是：金山招不到合适的&Delphi&程序员了――自从其项目部有两个&Delphi&码农跳槽之后，就只剩下一个&Delphi&码农了，这实在是个悲剧。这不是&Delphi&的悲剧，这就是&Delphi&的悲剧。最后，我认同武大说的，直至今天，VCL&依然是&Windows&桌面开发的最佳工具。不服？不服我也不会辩。谁用谁知道，扯那么多干啥。即便我也只是业余才偶尔用用&Delphi&了。
----------------------------------------------
人生若只如初见
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
认同界面由专业美工来完成这点，Delphi程序员大部份迷失在拖拉控件，寻找控件中。可不可以集合一下力量，搞个像迅雷bolt那样的东东出来。
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
(Flying Wang)
▲▲▲▲△
<font color="#楼：
楼上的提议，我支持。我和楼上一样都是懒鬼，开发UI引擎的事，就交给大家了。我和楼上，只负责免费使用。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
C#若完全native，把代码安全和效率提高上去，那还真是确实不错。用VC++之类做前端程序搞UI，除非你有很深的类库积累，不然和Delphi根本没有可比性，VC++之类真不是做UI而生的。Delphi作为一个商业产品，个人觉得已经很不错了，要想想C#是出自微软之手，不缺钱，不缺人，有Windows平台的支撑优势，只是当初确实不应该做成纯Framework语言。同时C#和Delphi都是出自同一人之手（最初设计），都是非常重视开发体验的产品，个人人为UI编程就是应该对着可视化的界面来做，把精力放在程序功能的实现，而不是像VC那样边写代码边想象自己想要的界面结果。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
某人说要我私聊，本不想说了。但是“小周童鞋”明显不小。这个称呼，武大对我似乎更合适一点。你毕竟比我小很多。“你敢说你用过&VC&写过&UI&方面的东西？”&--&用不着敢不敢，在迅雷，我的确是在用VC写UI。“Delphi编译器优化效率与VC不能比&--&前半句话，你好歹也摆出点实例出”--&这似乎不需要我来摆事实，你自己都摆过不少。“用&Delphi&写的&客户端应用&效率是瓶颈”&--&我从没说用Delphi写桌面应用效率是瓶颈。但是，同样是做程序开发，同样没有瓶颈的情况下。毫无疑问，选择更优的执行效率的开发工具才是个明智的选择。“那你不应不知道企鹅等在&UI&库方面经历了多少的积累才有这样的成果，你曾经呆过的迅雷难道不一样吗？”&--&恰恰相反，没有你想的那么困难。对于迅雷来说，也就1年的时间。“至于你说的高质量产品，Skype&算不算？执行速度慢不慢？而&QQ，体积难道不大？”&--&首先我想你可能应该可以认同，多数情况下，同样的程序用VC开发，程序执行效率要高于Delphi.如果企业主只考虑产品最终最优，他是否应该选择VC，而不是Delphi，即使Delphi的运行效率不差。或者这么说，使用VC做UI的痛苦，对于企业来说不是问题，那只是程序员的问题。企业只需要效率更高的产品。最后，QQ体积那是相当的大，我只想问，同样的程序，换成用Delphi,是否更大？？？“我也认同&C#&很好，但你一边倒的批判就不对了。”--&我根本无意拿C#与Delphi比较。就我的立场来说，我根本不希望Delphi沦落到与C#竞争。然而，现在的事实是C#在大量蚕食Delphi原有的市场。这个过程是发生在你看到想吐的领域：MIS。C#很好的将Web开发与桌面开发结合起来了，在Windows下做MIS，还有什么理由继续使用Delphi?&虽然你我都希望Delphi的竞争对手是C++，然而，EMB显然不是这么想的。从FireADC到完成的RTTI以支持反射开来。Delphi瞄准的仍然是MIS。“确实有部分应用开发方面，C#&取代了&Delphi，而这很大原因是因实在招不到&合适的&”--&招不到合适的Delphi&码农,&你可有想过为何招不到？Pascal曾经是专业必修课。现在还有多少学校开这么门课？学校是迎合市场的。最后，我想说的是，我同样希望Delphi更好，我在QC中提交的BUG，已经有120个，已经修复的有50多个，仍保持Open状态的30多个，我说这些，只想说明我对Delphi的关注可能并不比你少，对新版本也有一定程度的认识，然而，现实却是残酷的。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
如果觉得Delphi过时了，不喜欢Delphi了，&完全不必来这里。你离开Delphi活到很好，Delphi离开你也不会就倒下了。各走各的路罢了，何必回过头来给delphi一脚!楼主发到这里就是&盅祸人心&的
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&sqlnew我记得之前在某个地方看到过，在微软，目前C#的确有一个native化的项目。现在具体去找出处，却找不到了。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&jjwwang&(jjwwang)我目前仍然主要在用Delphi，反而是武大和adelphicoder不是主要工具而已。所以，你弄错了。Delphi有我没我一个样，应该不会因为我说了些不利于Delphi的就倒掉了吧？既然如此，让我说说又何妨？
----------------------------------------------
▲▲▲△△
<font color="#楼：
1)、你说说看，同样的（UI）功能/程序，是否&C++&能实现而&Delphi&不能？是否&Delphi&比&C++&要耗费更多精力，还是相反？我是真的懒得跟你争论关于&UI&这方面的东西。2)、可能是我没说清楚，我的失误。我的本意是指在&客户端（桌面）应用方面，Delphi&在所谓的效率方面几乎没啥。说到底，大家在实际开发中，有多少时候会真的抱怨机器码不够优化？当然，数值密集处理等特殊方面是例外。再，近年来，你可还见过我喋喋不休&Delphi&所谓的优化？技术视点和眼界好歹也要提升吧？Delphi&若不满足要求我就换用合适的，无止境的抱怨有什么意义。3)、你就只看到所谓的执行效率？譬如你在从事的服务器开发，你问问贵司另一个项目部，问问他们同规模的&C++&服务器程序，（全）编译一次要多久。要是按你的理论，C#&之流还能做什么工具/程序，C++&一统码农世界。还&“毫无疑问，选择更优的执行效率的开发工具才是个明智的选择。”……想法不同，不值得争讨。4)、1年的时间就搞个那样的&UI&库你还觉得短？而且完全不是从&0&写的。你觉得同等情况下用&Delphi&会更慢更差？至于企鹅的积累，我可以明确跟你说：积累、演进了很久。5)、“&多数情况下，同样的程序用VC开发，程序执行效率要高于Delphi&”，这话说的，譬如大部分（核心）功能都是调用系统&API，VC&怎么高了？你所推崇的效率最优论，让市面上相当多的应用/系统颜面何存？它们难道不知道用&C++&去开发？你怎能拿（小）部分效率敏感性的程序来这样泛论？再，同样的程序，VC&搞出来&100MB，Delphi&搞出来&105MB，在你眼里有&本质的&差别？6)、这个我认同，所以我也非常反感这些，这也是我不再用&Delphi&的原因之一。7)、你的&Delphi&知识是从学校学的吗？当然你可以拿一堆理由反驳，但请了解，学校教授的课程主要无非是&C/C++&等之类。譬如&PHP,譬如&Python，你有见过（国内）几所学校教授？当然，学校确实会部分程度上迎合市场，但这和我之前所说的是悖论，Delphi&委实悲剧。P.S：叫你小周，不因年龄，是没想到你的想法与意见是如此顽固而且尖锐。当然，就技术方面而言，可能你还是老样子――想法思想基于人的认知和功底。
----------------------------------------------
人生若只如初见
(Flying Wang)
▲▲▲▲△
<font color="#楼：
第一个&30&楼正解。楼主自己都遁了。你们吵吵个屁啊。
----------------------------------------------
▲▲▲△△
<font color="#楼：
@zwjchinazwj：我已很少关心&Delphi&的变化或改进了，偶尔平时还会用一下，毕竟在不少方面还是挺方便的。有些人，在围城里抱怨，殊不知围城外的却也会羡慕围城里的。你对&Delphi&还是那样关心，我很敬佩。但，你对&Delphi&是如此失望，与其这么多抱怨，为何不拓宽下眼界呢。
----------------------------------------------
人生若只如初见
▲▲▲▲▲
<font color="#楼：
我无所谓失望或者不失望。只不过想把我了解信息，我理解的内容反馈一些出来罢了。至于我自己，需要用什么，用它就是。delphi对我来说，也许是围城，也许不是。只不过你年纪比我小不少，也没有家庭因素的困扰。&我没法像你那么洒脱而已。最后，“当然，就技术方面而言，可能你还是老样子――想法思想基于人的认知和功底。”，其实你可以说得更明白一点。可能基于同事一场，你想给我留点面子。其实我无所谓的，我也无须去向谁证明什么。
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
小周&不是亲切的称呼吗？说！你们俩啥关系？
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
&有些人，在围城里抱怨，殊不知围城外的却也会羡慕围城里的。&这句话怎么理解？能详述一下否？
----------------------------------------------
(孤独骑士)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
to&蒲石我不认同你的观点和看法，但是看到你提交的QC超过120个，不禁让我肃然起敬！希望您能继续保持对Delphi的关注。看这么多长篇大论，总结下来就一句话，VC只在少部分情况下执行效率占优，大企业不在乎开发成本和效率，可以继续使用，否则感觉不是很有必要。C#就是拼后台硬，和Delphi作用高度重叠，并且兼顾Web和各种先进的语言思想，所以获得大企业亲睐。其实开发win32本身还是DELPHI更强更方便。另外，关于界面，MLSKIN做界面效果相当好、相当方便。大家自己不会看看吗？达到效果就行，干嘛非得XML？我看VCL代码一段时间后，固然赞叹VCL之巧妙，但是更佩服win32底层效率之强大，才可以让VCL随心所欲的封装。最好一点，我虽然更喜欢Delphi，但是这不妨碍大家也会C#啊，这两者很矛盾吗？我碰到HR说，会Delphi的都会C#..........除了我，见笑了！
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
我可以会&C#，但是我不想学。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&nevergrief&(孤独骑士)很遗憾，恐怕我无法继续报告BUG了。前2天，刚发现2个BUG，已经无法登陆QC了。也在EMB的论坛看到有人提到过，QC让大家看到了Delphi更多不好的一面。二者联系起来，我能得到的结论是：EMB开始进入鸵鸟状态：你们看不到，就没问题。
----------------------------------------------
(乐天无极)
▲▲△△△
<font color="#楼：
半天没来炒成这样。看看主流软件:多数是vc写的。但是就开源项目而言，C#的项目要比delphi多很多成熟的作品。我本意只是想说，delphi的界面易用以及控件的多重优势，会被C#的取代。就想php网页编程热火时，asp几乎没落，但用asp的网站还是大把。只是用的人多寡不一样。一门语言，啥优势都具备时，就必须面临PK筛选。用的人多，决定市场。
----------------------------------------------
相信自己，若自己都不相信，那还有谁可信。
▲▲▲▲▲
<font color="#楼：
谈不上吵，至少我是这样的。我只是表达自己的观点和看法。无论它是浅薄还是无知。我也没有就不同观点攻击过任何人。
----------------------------------------------
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
那回归正题吧，这个erp写着怎么样，完成度怎么样，能改改卖钱吗？
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
(Flying Wang)
▲▲▲▲△
<font color="#楼：
正题就是，此帖子该删除。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我感觉现在局面是delphi盈利模式造成的。例如，和Oracle比较，Delphi用户的是技术人员，Oracle存的是数据，面向的是银行、石油、电信等大客户，数据是公司的命，大公司都要买服务的，所以Oracle发展的很好。Delphi只是前端工具，而且开发工具多，我感觉Delphi盈利会有些问题，假如盈利有问题，就没法吸引太多优秀人才开发和优化delphi,所以造成今日bug满天飞
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
就EMB自己发布的报告看，目前盈利增长还是强劲的。但是就我来看，如果FMX不能真的达到工业化的水平。而又不开拓其他路子的情况下，后续会很危险。如果一个企业从XE2就寄希望FMX，然后XE3&XE4&XE5&XE6乃至XE7，一个一个版本买下来的话，估计已经没有兴趣再花钱买XE8了。
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
每个版本加&1W。国外应该更便宜。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我在等一个稳定的版本，曾买过两个版，也算支持过他们了，现在delphi还没有稳定到让我买的决心，但一直在观察,个人觉得质量是软件的生命
----------------------------------------------
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
大家推荐个delphi开源的erp和楼主这个pk一下。
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
▲▲▲▲▲
<font color="#楼：
最后，多说一句，我从不认为做MIS就垃圾。淘宝的后台也是个超大的MIS。
----------------------------------------------
(还在delphi)
★☆☆☆☆
<font color="#楼：
要看到delphi&xe7的进步，排名都到11了，delphi有希望。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
说到体积，忘了补上1个对比：DelphiXE7&bin目录，按文件大小排序：Id.exe&&&&&&&&&&19&MBcompclang.dll&&&&15&MBFDAdministrator&&15&MBFDExplorer&&&&&&&15&MBbds.exe&&&&&&&&&&14&MBcoreide210.bpl&&&12&MBRESTDebugger.exe&12&MB....==========VS2013&bin目录&&msenv.dll&&&&&&&&9&MBmsvbide.dll&&&&&&5&MBvbdebug.dll&&&&&&3&MBvb7to8.exe&&&&&&&2&MBvb7to8DL.dll&&&&&2&MB...后面的都不超过&2&MB初略统计了下，100个.exe,&.dll，VS只有40&MB&Delphi有350&MB各位看官看了之后，作何感想呢？
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我也感觉程序大了，一个程序，D2007编译后4M，xe编译后8M,xe7要10M,特别是引用Generics相关后，软件尺寸增长得更快,每次都要增长几十K,,但为了开发方便也就用，我猜emb他们不会去优化。现在XE系列随便开发个小程序都要10多M,之前十万行代码编译后也就3、5M
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
所以不到万不得已，我不用泛型。而且我非常反感EMB吧以前classes.pas单元中稳定的TList全改成了TList&T&
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
system.classes的Tlist还在&&&&TList&=&class(TObject)&&private&&&&FList:&TPointerL&&&&FCount:&I&&&&FCapacity:&I&&protected&&&&function&Get(Index:&Integer):&P&&&&procedure&G&&&&&procedure&Put(Index:&I&Item:&Pointer);&&&&procedure&Notify(Ptr:&P&Action:&TListNotification);&&&&&procedure&SetCapacity(NewCapacity:&Integer);&&&&procedure&SetCount(NewCount:&Integer);&&public
----------------------------------------------
(Highflyer)
▲▲▲▲▲
<font color="#楼：
我不禁想起了很多年前的一句话：真正的程序员用&C++，聪明的程序员用&Delphi。如果这是上联，那么下联呢？横批呢？
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&hq200306&我是说，Classes中其他原本使用TList的地方。他们全部改成TList&T&了。例如：&&TCollection&=&class(TPersistent)&&private&&&&FItemClass:&TCollectionItemC&&&&FItems:&TList&TCollectionItem&;&//〈〈〈〈〈〈〈
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
泛型是个好东西，用了，能提高若干倍开发效率，且不担心递错类型,有利于程序可靠，但程序尺寸加大好多，我觉得emb需要去优化这些基础类。经过近年的使用情况来看Delphi的泛型是可靠的，能长时间运行，程序可以连续跑几个月
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&hq0306)&泛型是个好东西，用了，能提高若干倍开发效率&&可是classes.pas是基础类库。他不需要提高若干倍开发效率，classe也不应该被反复修改，classes需要的是稳定和优化，那么classes中的TList&T&有什么必要替换掉TList呢？
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
对于classes等单元，我之前没留意，我只当他们都是可靠的基石。但有个问题，xe-xe7版，我做了些比较，确实每版编译出的程序会大些，且运行慢一点内存多用一点，写代码片段测试又不慢，估计是基础类库变化了。但有些类在多线程快了许多，如:TThreadList在xe7比xe快很多，我现在大多用xe(也是版权问题,xe和D2007是有版权的)，其他版还在观察
----------------------------------------------
(luckyrandom)
▲▲▲▲▲
<font color="#楼：
瞎扯一句：存在就是合理，消失也是合理市场决定一切，DELPHI在桌面守不住，在移动上开拓不了疆土但对桌面RAD，DELPHI还是NO.1但是，就像周杰伦，还是红火过八九十年代有实力的歌手
----------------------------------------------
SQL&SERVER大型网站/ERP性能优化、方案设计QQ:&缘在上海&曾经的Delphier
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
都老大不小了&还在争这个语言好&哪个语言差&到这个时候&就要上升到业务和需求了&数据库才是基石&用什么语言造什么房子&这是年青人的事了
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
&&&&杞人忧天！&&&&我手机App，服务端Restful，windows客户端，都是基于delphi开发。一个UI能说明啥问题，我用Dev开发的界面比他漂亮多。WIN8.1还默认不装&.Net&3.5呢，安装必须用控制命令，普通人怎么懂安装？&&&&水果引发了原生程序热潮，微软又开始跟风。&话说.Net也要编译出原生程序，是一个Exe带一大堆的dll尾巴，还是编译出上百兆的EXE？.Net向下兼容是个问题，原因是微软太激进的语法升级，各种不想要的类库马上丢弃，更致命的是，把基础UI也当成核心。net来更新。再对比下JDK，没把UI当核心SDK，1.6到现在还如此稳定和繁荣。1.7完全兼容1.6。SDK类库小巧玲珑。&&&再看看微软每次发布的漏洞，10个中有六七个和.net有关，，而大部分的都是.Net远程执行代码漏洞。把应用程序的漏洞都当成系统级别的漏洞，微软陷入死循环。&&&&Ssytem32目录下躺满各种&.Net&版本和SP补丁尸体。一个dll，比如GDIPlus.DLL，多达四五个版本。系统环境又垃圾又变得复杂。&&&&微软真搞笑。把.net太神话了更搞笑！&&&&一句话，蛋疼的楼主！
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
▲▲▲▲▲
<font color="#楼：
1.我非常同意tintin1943&(零输好),net部署真不容易，客户的机型，操作系统繁多,从win2000-win7都有，net如何装？叫客户把换新机?2.也同意lsz100&(lsz),几乎应用系统的数据都要进库的，数据库占的比重多一些。但，如果广域网的情况还要个应用服务器，这是delphi的弱项，这需要开发的
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
老外自己DIY的XE7&可穿戴式开发，智能手表。
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
▲▲▲▲▲
<font color="#楼：
to&tintin1943&(零输好)&.Net也要编译出原生程序&&这么表达是有问题的。我们提到的是C#编译成Native的代码&。C#是一种语言，可以有编译器生成中间代码，当然也可以生成Native代码。与.net不存在对等关系。或许C#编译成的Native代码所使用的应用框架不再是.net而是nativenet，就如同C++Builder使用VCL一样。简单来说，语言&和&Application&Framework不能混为一谈。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
&&&&真的是罗哩罗嗦，跟你谈国际接轨你又扯国情！&&&&别人叫你一声小周童鞋，你就感觉到辈分尊卑问题，想的太多了吧？
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
▲▲▲▲▲
<font color="#楼：
我想的多或者少，那是我与他的关系，似乎跟我回你的帖子扯不上半点关系。你不想谈也就罢了，直说就可以了，用不着绕回去对我进行人身攻击。
----------------------------------------------
(与月共舞)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
&&&&没有别的意思，也没攻击的意思，只是你不承认.Net的各种缺点而已。&&&&我只是想说，你们膜拜的微软或C#或VC，，微软这个帝国开始动摇了。&WP&才&4%左右的份额。WIN8.1出来后，WP8.1&beta了一年才发正式版。微软用这个速度开发速度开发移动平台，不作死不会死。&&&&当微软WP受阻时候，.net根基马上动摇起来。新CEO想把桌面，平板和手机统一起来，用经典的话说，只不过几堆垃圾合并成一堆垃圾。&&&&你觉得FMX很差？你对比过&Xamarin吗？UI设计比FMX还差远了。你觉得FMX很大？跨平台的，诸如QT,Xamarin，也是一坨坨的大。谷歌要是同意内置几个FMX的核心RTL&.SO文件，，你看到和JAVA开发的APK相差无几。&&&FMX内资了60多种特效，9种动画。FMX的layout和各种控件都是容器的思想，比VCL和.Net的UI先进不少。尤其是FMX的3D可视化设计，跑在不少的IDE前头。XE7的FMX也优化了不少，尤其是3D。一个用FMX开发游戏告诉我，XE7的FMX&3D&在2K分辨率上已经流畅了，之前的XE6有点卡，效率提升30%左右。EMB还是用心在做事。&&&&classes需要的是稳定和优化，那么classes中的TList&T&&&&&&========&&&&谁说核心的东西就不能动呢？如果有更快更好更健壮的程序，为何不用呢？微软为何不继续使用&.Net&1.0核心呢?&1.X时代，我记得是没窗体文件，直接使用一个&InitComponents&初始化UI。界面和代码不分家。&&&&一句话，为了批判而批判，和“敌人的敌人就是我们朋友”一样，已经丧失了客观性和理性。
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
(Flying Wang)
▲▲▲▲△
<font color="#楼：
顶楼上，然后休息。
----------------------------------------------
(孤独骑士)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
to&tintinFMX还能开发游戏？能透露一点相关信息吗？或者能截几张图就更好啦～to&All不管看法对错，学习蒲石一样给EMB多提几个bug，才是对Delphi最大的帮助啊，光在这里口水战有什么用呢？
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我从没有“不承认.Net的各种缺点”，因为我对C#几近无知。这是实话，绝不讳言。至于windows会怎么样，不在我这次讨论的主题里面。也可能说不出个结果。“你觉得FMX很大？”如果你看了我上面的发帖，你应该不难发现。我根本没把FMX很大拿出来说事。即便我举的例子，都是windows下的VC和DELPHI开发环境中PE文件的大小。如果你要问我，FMX大吗？我的回答是，确实很大。但是由于我知识的局限性，我不知道移动平台其他开发环境，无从比较。我甚至也没有说过FMX效率问题，因为同样的原因，我不知道，我不敢乱说。我只能从一些简单的事实来得出一些结论：1.FMX至今5年，移动应用多如牛毛，可是市面有多少是用FMX开发的呢2.FMX的代码质量，源代码是可以看到的，我有自己的判断。如果这点有不同意见，我们可以再深入讨论。3.FMX所走的模式与Java开发桌面应用并没有太大区别：自己封装一套UI，不使用系统原生UI。那么我们回头看看，Java在桌面到底占有什么样的分量呢？在苹果系统下，放弃苹果自己的UI，全部使用FMX的自绘UI，是否让人有种与系统格格不入的感觉呢？至于说“FMX比VCL和.net的UI先进不少”。我认为这样比较本身都有问题，但不想展开讨论了。“谁说核心的东西就不能动呢？如果有更快更好更健壮的程序，为何不用呢？”TList&T&一定比TList更快更健壮？能让TList&T&更快更健壮就不能让TList更快更健壮？然后，具体分析一下，使用TList&T&的坏处：1.由于使用泛型，不得不引入Generics单元。程序体积变大2.由于TList&T&等泛型容器，对每个T都需要完全展开一次代码，代码迅速膨胀。使用TList&T&的好处：1.使用TList访问Item成员的时候不再需要强制类型转换了，代码看起来更优雅这是以我的知识能得到的结论，就我来看，好处明显无法抵消坏处，这种选择显然是非常不合理的。（如果只是应用层而不是classe这个基础类库使用泛型，显然是可以接受的）“一句话，为了批判而批判，和“敌人的敌人就是我们朋友”一样，已经丧失了客观性和理性。”有人是这样，但肯定不是我
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我还是想回到&Windows下通用桌面软件&这个话题上就我的观点作一点补充。我们可以翻一些&通用桌面软件&来看看QQ&迅雷&360&快播&WPS&等等，这些软件UI通过Delphi这种拖拽方式开发是产生不出来。也就是，这些软件的UI都是自绘的。其开发的工作量都集中在如何绘制里面的组件以及如何响应消息。如何摆设这些组件，连接响应事件对于完成这些组件来说，是微不足道的小事，那么RAD所带来的快速开发的效率已经荡然无存。另一方面，一个TForm上，放1个TButton，然后TButton的点击事件一般是这样的：procedure&TForm1.Button1Click(sender:&TObject)begin按面向对象的观点来看，Button的被点击行为，理应由Button自己处理。与TForm1何干？在C++下，由于没有事件这种类型，通常情况是不得不通过派生Button，将Button的处理函数封装在自己的Button派生类中。这更符合OO思想。而且“事件”还有一些潜在的风险，也许细心人会留意到procedure&of&object这种数据类型的大小是8字节（32位平台），其中4字节是函数地址，这没什么问题，但是另外的4字节就有风险了。如果对象释放时没能适时的断开事件，就可能会出问题。有人会说这是开发者问题，没错，我同意，但是事件与对象之间的关系太隐晦了。使这种错误更容易发生。回到Button1Click不符合OO思想这个话题，其实VCL到是很好的解决了这个问题。那就是TAction，通过给Button绑定Action，避免&生成&Button1Click，同时,Action又封装了行为，这是更好方式。请注意，我这里提这一点并不是全盘否定“事件”所带来的巨大好处，我只是想说明：这种方式也有其缺点。
----------------------------------------------
▲▲▲▲△
<font color="#楼：
快看，灰机都灰走了！各位都歇了吧，一个工具罢了，合理的使用工具就好。
----------------------------------------------
逍遥乎八极之外，虚浮世间以乘天风云马
(Flying Wang)
▲▲▲▲△
<font color="#楼：
某人就是要证明使用&DELPHI&错了。但是，那又如何？我就用，你证明&一万遍，我也还是用。就要鄙视&C++&C#&Java&！
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
To:zwjchinazwj，看你也是老前辈+大牛身份了，在各种帖子里指向RTTI问题，怎么老是拿程序体积和RTTI说事呢？其一，你做病毒木马还是底层汇编？增加1-2MB的体积，会死人吗？你会不会做插件减少体积呢？其二，RTTI你可以关闭，你一句指令即可。会写不？其三，RTTI的好处和便利，估计你是D7党冥顽不灵（即使是用着XE系列，也是写着D7代码的）始终体验不到耦合性很低的好处。如果你做服务器，不用RTTI，估计你得写一大堆重复的代码。我基于&RTTI+Attirbute+RTC&=&动态的Restful，甚至扩展了Restful&API的在线参数帮助，这些都是基于RTTI特性。你用D7试试？其四，泛型你想都不想一口否定了，已经丧失了一个优秀程序猿的底限。如果是其他语言的泛型，你会否定吗？其五，从一个D粉变成D黑，就是因为其他工具看起来很高大上？OOP你也敢说出口？你知道事件赋值几种方式？老拿C++炫耀，你不如做学院派老师，一天到晚考学生的&i++和++i组合!
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
(Flying Wang)
▲▲▲▲△
<font color="#楼：
怎么老是拿程序体积和RTTI说事呢？==========因为他用的是&5&元&GPRS&上网。一不小心流量就超了。
----------------------------------------------
▲▲▲△△
<font color="#楼：
我爱DELPHI，我爱我家....
此帖子包含附件: 大小:273.3K
----------------------------------------------
就怕想不到，没有做不到的
▲▲▲▲▲
<font color="#楼：
看来你的火气越来越大，慢慢来，咱们慢慢说道。其一&上面的例子VC&DELPHI开发环境比较&&VC&100个文件&&40M&&Delphi&100个文件，350MB&我不是空口白牙，信口胡说也不知道你轻描淡写的增加1-2M的是说什么。其二RTTI可以关闭。如果那么容易关闭，我不会这里废这么多口舌。要想关闭VCL中的RTTI，必须重新编译整个VCL，在XE的早期版本的rtl目录中，还提供了BuildWinRtl.dpk，可以自行编译RTL，然而不知从哪个把本开始，直到XE7，你要去编译这个BuildWinRtl.dpk，直接会报告编译器错。注意，不是报告缺少.pas&或者.dcu，而是编译器报告：Internal&Error:&U7276，这是官方提供的dpk.如果这个BuildWinRtl.dpk可以，我一样也懒得废口舌说RTTI的问题。其三想移除RTTI，并不带表我认为RTTI不好。与你猜测的相反，我用很喜欢RTTI，我给们运维组开发的一个读取数据的工具正是用了RTTI来解释数据，达到多个项目组，不同数据结构，都可以使用这个工具解析自己数据的目标。但是，再好的东西也有适用的范围。在不需要RTTI的应用中，移除它只有好处没有坏处。况且即使你的程序也只需要在你的类中展开RTTI，而不需要整个VCL开启RTTI。其四我有一口否定泛型吗？我否定的是classes.pas中不必要的替换。其五1.如果我说错了哪里你可以指出来，我黑不起Delphi.2.事件赋值几种方式&我不确定你指什么，如果有兴趣，可以让我学习学习。3.OOP我为何不敢说？&即使我错了，你指出来，我学习，我为何要不敢说？4.炫耀C++？&你又搞错了，C++我只能算是知道，也就在上家公司正式用了几年，&&至今语法都学得不全。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我支持zwjchinazwj&(蒲石)，我认为一个好应用系统,技术上达到：稳定、可靠、迅速、灵巧、健壮。而希望delphi开发出的系统达到以上情况，而不是相反，变得笨拙、不可靠。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
不要站在自己的角度看别人的问题，产品、团队决定了开发工具。做WEB的不要总认为一切系统都应WEB，连嵌入式的也该用WEB，写服务器的不要认为只该C、C++.......。Delphi本来就定位企业开发的，什么的语言艺术、漂亮界面、体积大小.....。这些都不是重点，重点是开发效率、执行效率，企业讲究的成本、生产力。计算机的发展本来就是为提高人类的生产力的工具，一切违背它思想的都是错误行为，搞艺术、娱乐、学习的除外。
----------------------------------------------
硬盘抽取盒、USB3.0移动硬盘盒..
(Flying Wang)
▲▲▲▲△
<font color="#楼：
某人就是要证明使用&DELPHI&错了。但是，那又如何？我就用，你证明&一万遍，我也还是用。就要鄙视&C++&C#&Java&！
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&fengsoft&(Fs)你的确说道点子上了。我的确站在自己的角度看问题。这点我和adelphicoder有点类似。我不希望Delphi仅仅是个用来写MIS的。更何况写MIS，它都碰到了不小的挑战。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
我觉百花齐放吧，每个人的追求不一样，有些人最求效率、有些人最求美观、有些人无所谓。就如社会，有些人住别墅、有些人住四合院、有些人住公寓、有些人住地下车库、有些人住天桥下也很有满足。如果跳开这苦命的行业，有许多行业不需要费神，也过的悠然自得，也可以买楼、也可以买车，许多大妈还大举买金，一大帮苦逼的ITer
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
大概看了一下那个.net&开源ERP系统，虽然我自己的系统做得不怎么样，但我只能说那是个行业初等品，是一些没有太多经验的公司或人个作的。
----------------------------------------------
硬盘抽取盒、USB3.0移动硬盘盒..
(Flying Wang)
▲▲▲▲△
<font color="#楼：
我觉得&DELPHI&就是个别墅&.NET&就是公寓。&java&就是地下室。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
据说李维经常逛这里，只是不发言。但愿我的这些言论能被李维看到。也不枉我“黑”了Delphi一场
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
李维看的懂，&无心的爱&的简体字不?
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
我经常骂李维，可能我把他骂跑了吧。汉字简化后，护用手，爱有友，灶生火，显明明，龟有甲，笔有毛，宝有玉，众有人，网像形，灭无需水，呼吁有口，号非虎啸，体制为人也是为本，战为占有不宜单人，昼乃日出一尺高，虫不是越来越多是越少越好，而佛仍为佛，神还为神，信还为信，仁还为仁，善还为善，美还为美，福还为福，喜还为喜。h字化後，o用手，塾杏眩^生火，@明明，有甲，P有毛，有玉，\有人，W像形，o需水，呼n有口，非虎[，w制人也是本，占有不宜稳耍乃日出壹尺高，x不是越碓蕉嗍窃缴僭胶茫鹑佛，神神，信信，仁仁，善善，美美，福福，喜喜。化之後，_o吉，o言真2，就说“H”字，见不到就不H了？你爹妈死了见不着面了就从此不算亲属了？
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
源码能下载，控件下载不成了
----------------------------------------------
Delphi爱好者。
▲▲▲▲▲
<font color="#楼：
说了半天，我想，工作是为生计，据说现在中国每户的财产平均400W，请问各位达到了不?
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
楼上已经打算歪楼到政治贴了。不怀好意的不仅仅是楼主，还有&74&楼。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
不要乱说，是经济，没有政治
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
长期存在的各家工具各有优势吧。一无是处的很快就被淘汰了。只是语言不通用，也不能把几十种语言都学一遍吧。如果是个人，可以专注一个工具。如果是团队就要随大流了。我感觉delphi没有中文帮助，是一大缺陷。但是在开始自学编程的时候，还是从vb，vc，delphi中选择了delphi，开发和发布一般程序还是相对容易。c#只是看了一下，毕竟已经熟悉pascal了。ui有多少人在乎？有多少软件是靠ui卖的好？再有型，能赶上图片，网页，3D，全息？功能还是最重要的吧。其次是使用效率和开发效率。使用效率影响不大的话，还是用快速开发工具更有生产力吧。其实delphi的编译器效率还是很高的吧。在意执行效率可以不用vcl，用kol。能做几十k的程序，太小的程序有时候还会被360报病毒。
----------------------------------------------
是爱好，就别苛求太多！
▲▲△△△
<font color="#楼：
在Win系统下，修改一下就能编译出运行于IOS和Andriod的程序，delphi&FMX做的相当不错了，希望FMX越来越稳定,appmethod能成功。对喜欢Delphi的个人而言，与其抱怨Delphi不流行，不如多学几门编程语言，这样心态会好些。不敢想象一个士兵会说，我只用一种武器。个人觉得不管怎样，Delphi很难大面积流行，因为：1，对公司而言，Embarcadero可没有苹果、谷歌、微软那样雄厚的实力。用Delphi将自己的命运跟Embarcadero捆绑，难免让人担心。2，相对于几家免费的编程工具，Delphi太贵啦。3，对新手，delphi&XE的学习资料太少。
----------------------------------------------
(wk_knife)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊好热闹啊
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
楼上，刷屏不道德。
----------------------------------------------
(colin_you)
▲▲▲△△
<font color="#楼：
好久没来盒子上看了，若不是小胡(DelphiCoder)同学的提醒，我可能已经忘了这个论坛了。看到针对Delphi，C#，C++的诸多讨论，以及每个人的不同解，又重新钩起了我对Delphi的怀念。zwjchinazwj&(蒲石)&和&adelphicoder&(无尽愿)&是我的两个前同事，也曾在同一个部门共过事。很佩服你们两位，到如今依然还能这么关注Delphi的发展，尤其是蒲石，我从DelphiXE以后，就不大清楚后面加了哪些东西，只知道越来越庞大。但蒲石不是这样，对每个新出来的版本都很仔细的研究过，有哪些好坏都非常了解，这一点上，我相信很多人都没有异议吧。所以，老周并不是D黑，而是太喜爱Delphi了，希望它发展得好，才能这么深入的了解新版本的特性，而从中又发现了很多问题，这些问题很多是有道理的。在这里我无意于讨论谁对谁错，各持已见这本身没错，但能就事论事最好，带隐喻的人身攻击是不应该的。而对于一些完全无理智的回复，如：不喜欢Delphi的，认为Delphi不好的，就别用，别在祸害人心，充其量只是在丢人现脸。我只想说，你应该是属于脑残粉一类吧，人家在用Delphi工作的时候，你可能还不知在哪里吧？
----------------------------------------------
-colin&and&yoyo
(Flying Wang)
▲▲▲▲△
<font color="#楼：
楼上也是带隐喻的人身攻击
----------------------------------------------
(孤独骑士)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
老周不会是周爱民吧？
----------------------------------------------
(colin_you)
▲▲▲△△
<font color="#楼：
To&wang_80919&(Flying&Wang)对于有理智的讨论，我就事论事对于没有理智的攻击，我就用隐喻的人身攻击都没有理智了，还讨论什么？
----------------------------------------------
-colin&and&yoyo
▲▲▲▲▲
<font color="#楼：
我和周爱民不是一个层次，对他我是高山仰止。to&linzhenqun&(colin_you)&年轻最大资本是可以再来,都跳出去了，就别再掉进来了。我来盛大或许是个错误。不来的话，也许早以不关心Delphi了,但是我既然来了，还用着它，那么我会继续向前，不会回头。有些人无须理会，基本上我都没直接回复，没有太多必要。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
to&hq200306，别瞎跟风，跟你不是一个级别的讨论，你很多帖子总是讨论Unidac更新和升级信息！当年unidac&0.X&版本时候，是我一篇文章推广了Unidac，不知道你那时候在那里。to&zwjchinazwj&(蒲石)，看在武稀松和无尽愿上，不想和你继续纠缠下去。在对待delphi严肃性和客观性，已经没必要和你纠缠不休。你觉得未来是C#天下就请继续吧（再嘲笑下，WIN8抛弃了.NET&3.5（微软不鼓励安装，很难安装），WIN10如果是.NET&5.0，又抛弃哪个版本呢）！
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
(白忙剩人)
▲▲▲▲▲
<font color="#楼：
好热闹,还有几分钟下班.说说我的看法1.执行效率,还是坚持认为只要需要基本上任何native能调用库或允许在线会变得语言都能优化成一致.可以看我博客的汇编1关于优化的论述和之后的测试.所以对我来说,vc&也好delphi也好&执行效率只要愿意和需要都能达到(甚至可以根据的硬件的具体配置进行优化).而无论是什么语言,只要能加载库或在线汇编.2.开发效率,这个对个人来说主要是个人对某个语言的熟练程度和自己内库以及代码资源的积累决定的.当然对新手来说或团队开发来说,这个由多个条件构成,不能一概而论.3.编译后体积,大多数时候我一点都不关心.我比较关心内存占用和内存申请次数；硬盘读取量和次数；网络传输量、连接次数、连接数；数据库传输量连接次数、连接数&4.Tlist和泛型:我基本上从来不是主动使用泛型，始终认为支持指针的语言泛型是多余的。我一直这么使用Tlist&替代任何泛型,(为了方便,我随意粘贴了一段代码),在ctrl+alt+c的帮助下写不了几行代码.但能替代任何泛型并随意控制PBskyThread&=&^RecBskyT&&RecScriptEvents&=&record&&&&Event:&string[40];&&&&Script:&&&&&TBskyScriptEventList&=&class(Tlist)&&private&&protected&&&&function&Get(Index:&Integer):&PScriptE&&&&procedure&Put(Index:&I&Item:&PScriptEvents);&&&&procedure&Notify(Ptr:&P&Action:&TListNotification);&&&public&&&&constructor&C&&&&destructor&D&&&&&function&Add(Item:&RecScriptEvents):&I&&&&property&Items[Index:&Integer]:&PScriptEvents&read&Get&write&P&&&implementation{&TBskyScriptEventList&}function&TBskyScriptEventList.Add(Item:&RecScriptEvents):&Ivar&&P:&PScriptEbegin&&getmem(P,&sizeof(RecScriptEvents));&&FillChar(P^,&sizeof(RecScriptEvents),&#0);&&P^.Event&:=&Item.E&&P^.Script&:=&Item.S&&result&:=&inherited&Add(P);constructor&TBskyScriptEventList.Cbegindestructor&TBskyScriptEventList.Dbegin&&function&TBskyScriptEventList.Get(Index:&Integer):&PScriptEbegin&&result&:=&PScriptEvents(inherited&Get(Index));procedure&TBskyScriptEventList.Notify(Ptr:&P&Action:&TListNotification);begin&&&&if&(Ptr&&&&nil)&and&(Action&=&lnDeleted)&then&&&&begin&&&&&&PScriptEvents(Ptr).Script&:=&&#39;&#39;;&&&&&&Freemem(Ptr,&sizeof(RecScriptEvents));&&&&procedure&TBskyScriptEventList.Put(Index:&I&Item:&PScriptEvents);begin&&inherited&Put(index,&Pointer(Item));
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&tintin1943&(零输好)不知道你的“delphi严肃性和客观性”从哪里来，一发贴就是攻击别人的言辞，你可有认真的谈过技术？罢了，爱骂就骂吧。如果你的回复里能带点技术内容，我也不介意继续谈谈自己看法。如果只是骂人，没有内容，我不想回复。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&bmsr&(白忙剩人)1.从程序员的角度来说我同意这个观点。但放到企业里看，如果2个工具，不考虑其他任何因素，只考虑执行效率，无论效率差距多么小，企业一定选择执行效率高的。如果考虑其他的因素，人员&开发效率，情况就会有所不同。人员这一点，Delphi已经无从谈起。开发效率，这就需要结合具体应用来看了。比如，我现在做服务器程序，开发效率，Delphi无优势可言。那么如果用Delphi做QQ呢?，是否会比VC来的效率高，我的结论是：不会！QQ的UI不是拖拽摆放的。Delphi提高不鸟开发效率。最后，MIS，是否可以提高效率？答案是肯定的。所以，市场上多数用Delphi的是做MIS的。3.体积是问题吗？体积的问题是当你探究体积什么使体积变大的问题后，对这个产品（Delphi）产生了巨大的怀疑。4.曾经我也是这么认为的。现在有不同的看法。我曾经认为，既然都是展开代码，何不有一个专门的辅助工具，直接将模板自动生成成具体代码。
----------------------------------------------
(似水?流年)
▲▲▲△△
<font color="#楼：
作者：&&linzhenqun&(colin_you)&&而对于一些完全无理智的回复，如：不喜欢Delphi的，认为Delphi不好的，就别用，别在祸害人心，充其量只是在丢人现脸。我只想说，你应该是属于脑残粉一类吧，人家在用Delphi工作的时候，你可能还不知在哪里吧？----------to&linzhenqun&(colin_you)&你今天没有吃药吗，出来凑什么热闹。人家没有说你，你进行什么人身攻击啊。病还没好，就继续去呆着。你妈妈在叫你回去吃药。装什么前辈
----------------------------------------------
我爱Delphi，我用Delphi&
▲▲▲▲▲
<font color="#楼：
大家客气点，和气点，就事论事好了，文人相轻显得不够气量。技术问题，在某些人眼里都是雕虫小技。做开发大多是苦命的活，也算一线劳动者，卖点脑力、体力，换点生活费，年轻时有点想法，若干年但你回首时，可能是大海一粒沙，也可能是一粒较大点的沙吧了
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
1、你的救兵同事证明你是老同志时候，满口仁义道德同时，把我群友似水?流年也骂了。你好像也力证和李维也有交情且满腹委屈。姑且认为你是老中医吧（周小船也是老中医）！如果我白发苍苍，我同事甚至叫我小苹果，我也不至于认为不尊敬长辈，同事就是兄弟。可见你很爱鸡冻。爱鸡冻的人总是觉得这个不行，那个不行，围城之外没见过的东西是最好的。程序猿不是老中医，越老越吃香（针对你同事说）！2.您说“因为我对C#几近无知”，却称“未来是C#”的天下，可见有半仙水平。我从不如此张狂，对未知领域保持沉默。我也从不说某个语言是未来天下，或说这个XX亡（VCL，FMX）或那个不行（VCL，FMX）。作为一个程序猿，如此忧国忧民般、杞人忧天搬担心这X亡那个灭绝，或许的或许您（抱歉您的同事说你老同志）不行的时候，，Delphi还继续在人间。我怎么没听到高手武稀松这么忧心忡忡呢？莫非他看过了《程序猿的修养》？3.您说“体积的问题是当你探究体积什么使体积变大的问题后，对这个产品（Delphi）产生了巨大的怀疑。”微软是不是退回到WIN95时代，那个时代WIN95安装后才150MB。一个做稀疏平常的程序猿，去怀疑编译器，RTL，VCL类库，FMX类库，怀疑跨平台进步，得了吧，您手工写出无数串的1和0，根本不用编译器和类库。4.我还是跟武稀松和无尽愿一个观点，，Windows桌面上，最好的工具还是DELPHI，不管你承认不承认。
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
连“白忙剩人”大侠都来了，果断留名。
----------------------------------------------
(colin_you)
▲▲▲△△
<font color="#楼：
to&wuxi15&(似水?流年)不跟你扯些废话，后面不再回，你要叫请继续to&zwjchinazwj&(蒲石)年轻最大资本是可以再来,都跳出去了，就别再掉进来了。我来盛大或许是个错误。不来的话，也许早以不关心Delphi了,但是我既然来了，还用着它，那么我会继续向前，不会回头。----------实际上，Delphi现在还是我写一些辅助工具的首选，无他，VCL太方便，编译速度真心快，自己也比较熟悉，所以，要完全放弃Delphi大概是不大可能的，只不过我现在仍然用的是Delphi2007，XE以后所增加的那些垃圾体积让我更确定，Delphi越来越强调“快速”而不强调“品质”，就像李维每次都鼓吹可以节省多少时间，让老板多高兴之类的，我觉得这是一个错误的方向，让Delphi越来越臃肿，市面上新出什么技术就支持什么，搞得好像什么都支持，实际上什么都支持得不好。to&bmsr&(白忙剩人)你那个关于TList泛型的例子，确实在Delphi无泛型之前是一个很经典&的用法，我们原来也经常这样做，但有了泛型之后，几十行代码简化为一行，这反倒是证明了泛型之有用，我完全想不出在有泛型的情况下，还要去这样写的理由。
----------------------------------------------
-colin&and&yoyo
(Highflyer)
▲▲▲▲▲
<font color="#楼：
做桌面开发，我首选&Delphi，如果界面较复杂，我会使用&FMX，这东西自定义界面太爽了。服务器方面我一般选择&C#，和&Delphi&客户端结合也没遇到什么问题。至于文件大小，就好比如果你工作很有能力，谁会在乎你的体重是&100斤还是&200斤呢？大家还是别争了，各类工具各种语言各有千秋。适合自己的就是最好的。大家看我的行文，英文、数字和汉字之间都有空格，标点符号也是一个不落。这是十多年做程序写文档练出来的，哈哈。各位好好学习，在各自喜欢的技术路线路上逐日精进吧。好好工作，赚到钱改善生活就好了。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
好火的帖子，赶紧留个名，还没到100
----------------------------------------------
DIOCP官方社区|MyBean官方社区
(咏南中间件)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
今天逛广州购书中心，只见C#书一堆，VB书一堆，VC书一堆，VF的书都有好些，二级考试还有VF的。DELPHI的书在哪里？终于在角落里找到了有且只有的一本《DELPHI范例大全》。人心市场之向背尽然！诸位又何必争执。
----------------------------------------------
咏南中间件&QQ：
(似水?流年)
▲▲▲△△
<font color="#楼：
to&linzhenqun&(colin_you)该干麻干麻去，没人理你，别自作多情，该吃药的吃药。别以为老提盛大，武大什么的，就以为自己牛。不知道。长江后浪推前浪，前浪干嘛去了……。、我是菜鸟，我研究你们所说的落没的Delphi去了
----------------------------------------------
我爱Delphi，我用Delphi&
(colin_you)
▲▲▲△△
<font color="#楼：
&tintin1943&(零输好)在你冷嘲热讽的言语当中，看似言之凿凿，实则明眼人一看，人品之高低立马就分出来了，蒲石就事论事，而你则是不断的用各种冷言冷语在进行攻击。另外，我不是什么救兵同事，此之前我与蒲石已经好久没有联系了，整个贴子看下来，他基本上是针对很具体的问题在讨论，而如你这样的人呢，基本上就是各种嘲讽，也不想想你到底明白他在说什么没有，一棍子就打下来。如果你能从具体的问题说出个道理来，我就服你，不然，你也只是夸夸其谈而已。针对你说的几个点，前面是在攻击人，没什么好说的，后面2点。3。&编译器，RTL，VCL类库，FMX类库，跨平台这些都是进步，都是好东西，但好东西不能怀疑吗？代码就在那里，当你有兴趣去一究他的实现，却发现有些东西做得不够好，提出来有什么不对吗？4。&你的观点没有人说你什么，你真的那么需要人承认吗？而我也有发表我意见的权利：Delphi曾经是一个轻灵的工具，可惜现在被他们搞得太臃肿了，很多人所觉得的好，大概是早期Delphi所留下来的宝贵的东西。
----------------------------------------------
-colin&and&yoyo
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
有个人打算做微信营销，就在微信朋友圈卖东西，开始的时候完全没有人搭理他，但他每天坚持上货、拍照、修图发到朋友圈，坚持了3个月，功夫不负有心人，终于有了回报：所有的人，都把他拉黑了。
----------------------------------------------
DIOCP官方社区|MyBean官方社区
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
To&linzhenqun：1、大概是早期Delphi所留下来的宝贵的东西。====从你说D2007是最好的宝贝说起，就知道你没用过泛型，unicode，新RTTI，匿名函数，新动态数组语法，FMX，EMB的努力和进步，不是Borland能比拟的。Borland时代落寞和EMB的进步，不可同日而语。一个程序猿停止了追新，还有资格评论新产品新本身吗？2.我冷嘲热讽也好，你是直接骂人还似乎仁义道德。您的人品很好吧？您的蒲石似乎不喜欢同事叫他童鞋呢3.你同事讲了啥技术，不就是说程序很大，很讨厌RTTI，以及故作高深的事件讲解？在另外帖子还喷RTTI。做一个严谨的程序猿，没研究过C#就预言天下第一，没深入RTTI就说肥硕无用。我写代码14年从没见过如此张狂的程序猿。4.你可以怀疑，但张嘴就说这个不行那个不行，好像说得他做的比EMB架构师还好。您的蒲石可以怀疑VCL,FMX，我们就不能怀疑您的蒲石？不想再争论！两位盛大的高手！！
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
▲▲▲▲▲
<font color="#楼：
to&linzhenqun不必再争了。to&tintin1943&(零输好)你不同意我的观点，摆事实说就好了。有必要骂街么？你就一直很纠结我对adelphicoder对我称呼，那我告诉你，我不喜欢说话含糊其词。想对我有什么评价或者看法直接说，不必绕湾子，我也不介意任何人说我技术垃圾。我的确就是个普通的做应用的。但是，否定我的看法我需要看到具体的讨论，而不是因为说我技术垃圾就直接否定我所有看法。这我无法接受。
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
我也不想再争论，对于RTTI和泛型上，小有体会而已，但已经跟你没共同语言，何必再做具体争论呢？从没说过一个脏字，也从没说你技术垃圾只是说你太张狂而已！稀疏平常本意是指大家都不做高大上的编译器或人造卫星。或许真的高手都是性情中人吧。盛大从不缺乏高手，或许老夫聊发少年狂。但这个已经不重要了，因为我不想讨论谁或是某个语言天下第一。到此为止！不想再讨论！！！晚安，两位盛大高手！
----------------------------------------------
不喧哗&自有声&心静&思远&志行千里
(白忙剩人)
▲▲▲▲▲
<font color="#楼：
to&linzhenqun&(colin_you)请把以下结构泛型化(不要求一条语句实现),并实现排序查询&等功能,实际应用比这复杂的多的是.recxx=record&s:&func:&aclass:T&arr:array&of&somerecend还有没有几十条语句,ctrl+c&和ctrl-v&或者自己些个tools模版比固定的那些写泛型并不多谢什么代码.灵活性根本没的比,以后功能想怎么改就怎么改.那一有的泛型更本就做不到.
----------------------------------------------
(colin_you)
▲▲▲△△
<font color="#楼：
bmsr&(白忙剩人)关于你说的更复杂的应用，用你上面所举的继承的确是一种方式，不过也有另一种方式，就是组合，即在外面包装另一个类，那么recxx可能就被封装在里面，如：type&&TMyXXX&=&class(TObject)&&private&&&&FMyXXX:&TList&PRecXXX&;&&public&&&&function&Search(const&name:&string):&PRecXXX;&&&&procedure&S&&而Search和Sort就是实际的上层逻辑了，可以根据你的需求去写。当然你用的继承一样是可以实现的，只不过继承的结果把TList的所有方法都暴出来了，即外部是可以任意操作的，除非你把很多方法都重写一遍。而实际上你的需求跟泛型并不冲突，因为那是业务逻辑，而泛型是一种基本组件，你可以用它来实现你的业务，同时也可以减少Get,Put等重复性的代码。所以我认为泛型是很有用的。
----------------------------------------------
-colin&and&yoyo
(Flying Wang)
▲▲▲▲△
<font color="#楼：
第一个&87&楼正解。第二个&87&楼，没书看，去台湾买。买不起，就偷，偷书不算偷。偷都偷不到，就是你自己的问题了。各位注意，骂人的好像是我，你们不要冤枉好人。
----------------------------------------------
(Flying Wang)
▲▲▲▲△
<font color="#楼：
某人就是要证明使用&DELPHI&错了。但是，那又如何？我就用，你证明&一万遍，我也还是用。就要鄙视&C++&C#&Java&！
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&bmsr&(白忙剩人)对于TList，我的看法和你接近，不用泛型也可。但是，泛型不止TList.如果有多个泛型参数，另外配合上泛型约束。可以构造真正意义上的泛型算法。这就不容易通过普通方式完成了。以帮助中的例子来说：TFoo&T:&ISerializable,&IC&V:&IComparable&有了泛型约束，T&V的类型差不多可以等同于已知的。
----------------------------------------------
▲▲▲▲▲
<font color="#楼：
to&linzhenqun&(colin_you)type&&TMyXXX&=&class(TObject)&&private&&&&FMyXXX:&TL&&public&&&&function&Search(const&name:&string):&PRecXXX;&&&&procedure&S&&&&property&Items[Index:&Integer]:&PRecXXX;&&不用泛型，直接封装好强制转换，用起来也一样舒心。
----------------------------------------------
(truekbcl)
▲▲▲▲△
<font color="#楼：
请把以下结构泛型化(不要求一条语句实现),并实现排序查询&等功能,实际应用比这复杂的多的是.recxx=record&s:&func:&aclass:T&arr:array&of&somerecend----------用STL吧，很简单的完成了你的需求。不过delphi这样非图灵完备的泛型，确实做不到STL那样的效果，需要接口的支持，而且还是侵入的。本来图灵完备的泛型是设计的利器，而delphi、c#、java，它们的泛型基本就是一个替换器，价值不算太大。
----------------------------------------------
(colin_you)
▲▲▲△△
<font color="#楼：
to&zwjchinazwj&(蒲石)可能这个例子确实不能体会泛型的好处，因为指针是可以强制转换的。那么假设元素是TMethod呢，这个结构占了8个字节，如果用bmsr&(白忙剩人)的方法：首先，是要写这些重复性的代码，如Put，Get等等。其次，是每个元素要GetMem，对于Size比较小的结构，似乎不要GetMem更好。诸如这样的需求，另一个例子是Map类，在Key类型比较多变，可能是string，也可能是integer，如果不用泛型也是挺麻烦的，当然原来我们是有一个基础容器框架，麻烦之处就是对于每种类型，都要继承一下然后覆盖几个方法。
----------------------------------------------
-colin&and&yoyo
(wk_knife)
▲▲▲▲▲
盒子活跃会员
<font color="#楼：
华丽的分隔符来了――――――――――――――――――――――――――――――－－－－－－－－－－瞅得眼晕！Flying&Wang，看在本家份上！我帮你分隔一下！
----------------------------------------------
(似水?流年)
▲▲▲△△
<font color="#0楼：
楼上，这是在打酱油啊。大牛出没，我等小辈只能躲在角落
----------------------------------------------
我爱Delphi，我用Delphi&
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#1楼：
RTTI真是个好东西，希望EMB继续深耕，所有基础类都动一下刀子更好，没RTTI就没MVCXE。
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
▲▲▲▲▲
盒子活跃会员
<font color="#2楼：
mvcxe看不出比其它WEB开发的&优点。
----------------------------------------------
相信自己，善待友人。
(kylixfans)
▲▲▲▲▲
盒子活跃会员
<font color="#3楼：
楼上别歪楼，MVCXE讨论请移步：
----------------------------------------------
MVCXE中国首个DELPHI&MVC&WEB框架:
▲▲▲▲▲
<font color="#4楼：
做Delphi应用开发要醒醒，不要在茶杯里游泳，拉奈：甲骨文创始人埃里森买下的美丽岛屿，#p=A9IB0CQL5FVH0009
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#4楼：
老讨论这个有意思吗？从DELPHI出来就和VC争，现在又和C#争，争来争去DELPHI还是那个DELPHI。没有一个平台支持DELPHI实属不易啊。在这个拼爹的时代，你看OBJECT-C靠苹果，VC++和C#靠微软，JAVA靠ORECAL和安卓，DELPHI靠谁啊？
----------------------------------------------
相信自己，善待友人。
▲▲▲▲▲
盒子活跃会员
<font color="#5楼：
需求决定未来，讨论的这些都是高级语言，估计在Windows被取代之前，或更抽象的语言产生之前，这些高级语言还是会并存的，即使他们的开发公司倒掉。楼上认为Linux靠谁？
----------------------------------------------
是爱好，就别苛求太多！
▲▲▲△△
<font color="#6楼：
叼你妈的，这帮人怎么那么有空！
----------------------------------------------
▲▲▲▲▲
<font color="#7楼：
如果大家真有空，给我这样的新手写点实例学学到是不错
----------------------------------------------
▲▲▲▲▲
盒子活跃会员
<font color="#8楼：
这到时真的&给新手写点资料吧
----------------------------------------------
▲△△△△
<font color="#9楼：
讨论越热烈越说明delphi的生命力没人踢一条死狗对吧入行十多年，一不小心就把自己的命运和delphi绑在了一起，现在看到了希望，一起加油
----------------------------------------------
分享研究Delphi&Android开发过程中的点点滴滴，一起努力促进Delphi的Android开发繁荣
登陆以后才能回复
Copyright & 2CCC.Com
版权所有 页面执行70.3125毫秒