标题 * 对主流技术的分析和总结* bjhua（原作） 关键字 COM J2EE .NET C# C++ Java Delphi VCL MFC 一、引言 1 我为什么要写这篇文章 1 我的故事 2 要涉及的话题 3 二、正文 3 2.1 程序设计语言 3 2.2 桌面应用程序框架 5 2.3企业应用程序框架 6 2.4 COM技术 7 结论 9 闲话 10 给入门程序员的建议 10 印度的软件业 11 附录 11 对主流技术的分析和总结 myemail: bjhua@etang.com 一、引言 我为什么要写这篇文章 首先，我要限定我文章的范围，我讨论的问题局限于桌面应用开发领域和企业应 用开发领域，所以我的结论并不适用于整个软件开发界，比如我说C语言已经退出 历史舞台，这对于写嵌入式系统的人和编写操作系统内核的人来说显然是错了。 我写这篇文章的目的主要是： * 简单的介绍并评价当前主流技术 * 比较当前的主流技术 * 预计技术的演变 如果你想做程序员或者已经是个程序员，你可能会面对这些困惑： * 学什么语言呢？Delphi、C++、VB、Java、C#、PHP、Python? * 选择什么开发工具呢？Delphi、VC、C++Builder、JBuilder? 当你已经入了门，有了一定的基础之后（可能已经通晓了几种语言），你会面临 进一步的困惑： * MFC和VCL之间是什么关系？ * J2EE到底是什么？.Net到底是什么？两者有什么本质的区别，我应该学习哪一个呢？ * COM那么复杂，为什么很多地方都用到它？我必须学习它吗？ 如果是作为一个软件公司，如果不是那么大，如果你的公司还没有一个真正的技 术上的灵魂人物，那么你也会面临同样的困惑。技术问题纷繁复杂，让你不知所 从，而且真正的精通每一项技术都需要巨大的时间和人力的投入，你怎么办？选择 哪种技术作为公司的主流技术呢？选择的方向是否正确是个关乎你的公司的生死存 亡的问题。 你面临着这些困惑吗？如果是，那么请让我试着为你拨云见日。 我的故事 在我上大学之前，我从没见过计算机。大学的时候，正是Dos和FoxBASE的年代， 也正是计算机软件开发世界几件伟大的事情发上的时候：(Windows3.1、Borland C++ 3.1、Visual Basic 1.0 的推出也是伟大的事情，但那时候我还不知道计算机 为何物)Widnows95推出，并开始应用；Visual Basic 5.0推出，开发工具中第一次 出现了成熟的、被广泛应用的Auto Code Completion技术；Java推出；ASP技术开 始盛行,Windows DNA技术被理解和接受；标准C++诞生;Visual C++6.0 推出；J2EE 规范推出。 成为一个程序员对我而言并不顺利，因为我不是科班出身。我入门的程序语言是 FoxBASE，这让我一直对FoxBASE有种特殊的感情，我也正是通过Visual FoxPro3.0 转写Windows程序的，如果没有它，我也许就不会成为一个程序员了。后来，在大 学期间接触到了InterDEV，那是个写ASP程序的开发工具，还有Java，也是那时候 接触的，当时有点盲目崇拜的意思（我想我喜欢Java的一个原因可能是刚开始学C 的时候很受挫折）。毕业之后，我就是凭借着自己写的一个ASP网站找到了自己的 第一份工作——说来惭愧，我从来也没有成为一个C程序员。我真正的熟悉Java是在 我翻译了一本Java数据结构的书和写了一套完整的GIS系统之后（说起此事，我要 感谢一下我的公司，但因为这些故事与本文的主题无关，所以这里就不多说了）。 再后来，我自己学习了标准C++和COM技术。 有点像履历表了是吗？提到这些，我只是希望作为读者的你能够了解一下我的知 识体系，从而能够知道我大概要讲些什么；同时也希望你能够原谅我可能犯的错误 ——我在这里说的话，并不一定就是最后的结论，虽然“共同探讨”这个词几乎是粗制 滥造的书的作者专用语了，但我在这里引用它是真诚的，我愿意看到你的反馈。 要涉及的话题 在开始文章的正题之前，我先大概地介绍这篇文章将会涉及到哪些知识。如果你 是初学者，希望你不要被吓倒，这虽然是一篇技术文章，但我不会过多的讨论技术 细节，如果你不懂我说的这些东西，也没关系，我本来就希望通过我的文章帮助你 做出一个选择，不再走很多人已经走过的弯路，你这要记住结论就可以了，随着你 知识的增长，以后你会渐渐明白；如果你已经通晓了这些技术或其中的大部分，那 么我相信读了这篇文章你会有一些另外的收获。 主流的程序设计语言： C++、Delphi(Object Pascal)、Java、C# 桌面应用程序框架：MFC、VCL、QT、Java AWT\SWING、.Net 企业应用程序框架：Windows DNA（ASP、COM、COM+）、J2EE、.Net Framework 开发工具：Visual Basic、Delphi、Visual C++、C++ Builder 、Visual C# 二、正文 好了，现在让我们开始我的正文吧。 首先，我来完成这篇文章的第一个目标：介绍并评价当前主流技术。我指的今天 的主流技术是： * 程序设计语言：C++\Delphi（本来应该是Object Pascal，但为了简单，我就语 言和工具混为一谈吧）\Java\C#(虽然他刚刚推出，但因为微软为之倾注了大量心 血，一定会成为一种重要的开发语言) * 桌面应用程序框架:MFC\VCL * 企业应用程序框架:Windows DNA\J2EE\.Net * COM技术：我单独提出这项技术，是因为它无法简单的被视为语言、桌面应用程 序框架或企业应用程序框架，它与这些都有关系。 2.1 程序设计语言 2.1.1 C++ 语言的演进最初要从二进制代码和汇编说起，但那太遥远了。我们就从面向过程的 语言说起吧（包括Basic\C\Fortran\Pascal）。这种面向过程的高级语言终于把计 算机带入了寻常的应用领域。其中的C语言因为它的简单和灵活造就了Unix和 Windows这样的伟大的软件。面向对象的语言是计算机语言的一个合乎逻辑的进 化，因为在没有过多的影响效率、简单性的前提下提供了一种更好的组织数据的方 法，可以程序更容易理解，更容易管理——这一点可能会引出不同意见，但事实胜于 雄辩，C++终于让C语言的领地越来越小，当今还活着的计算机语言或多或少的都具 备面向对象的特征，所以这一点并不会引起太多困惑。C++的成功很大程度要归因 于C，C++成为它今天的样子是合乎逻辑的产物。因为在面向过程的时代，C几乎已 经统一天下了。今天著名的语言象Java\C#都从C借鉴了很多东西，C#本来的意思就 是C++++。 其实C++曾经很有理由统一面向对象程序设计语言的天下来着，但可惜的是，C++ 太复杂了。即使是一个熟练的程序员，要你很清楚的解释一些问题你也会很头痛。 举几个还不是那么复杂的例子来说： 对=的重载\成员转换函数\拷贝构造函数\转化构造函数之间有什么区别和联系呢？ 这样定义一个类成员函数private: virtual void MemFun() = 0; 是什么意义呢？ int (*(*x(int))[4])(double); 是什么意思？ 还有其他的特征，比如说可以用来制造一种新语言的typedef和宏（虽然宏不是C+ +的一部分，但它与C++的关系实在太密切了），让你一不小心就摔跤的内存问题 （只要new 和delete就可以了吗？有没有考虑一个对象存放在容器中的情况？）…… 诸如此类，C++是如此的复杂以至于要学会它就需要很长的时间，而且你会发现即 使你用C++已经好几年了，你还会发现经常有新东西可学。你想解决一个应用领域 的问题——比如说从数据库里面查询数据、更改数据那样的问题，可是你却需要首先 为C++头痛一阵子才可以，是的，你精通C++，你可以很容易的回答我的问题，可是 你有没有想过你付出了多大的代价呢？我不是想过分的谴责C++，我本人喜欢C++， 我甚至建议一个认真的开发普通的应用系统的程序员也去学习一下C++，C++中的一 些特性，比如说指针运算\模板\STL几乎让人爱不释手，宏可以用几个字符代替很 多代码，对系统级的程序员来说，C++的地位是不可替代的，Java的虚拟机就是C++ 写的。C++还将继续存在而且有旺盛的生命力。 2.1.2 Java和C# Java和C#相对于C++的不同最大的有两点：第一点是他们运行在一个虚拟环境之 中，第二点是语法简单。对于开发人员而言，在语法和语言机制的角度可以把Java 和C#视为同一种语言。C#更多的是个政治的产物而不是技术产物。如果不是Sun为 难微软的话，我想微软不会费尽心力推出一个和Java差不多的C++++，记得Visual J++吗，记得WFC吗？看看那些东西就会知道微软为Java曾经倾注了多少心血。而且 从更广泛的角度来说，两者也是非常相似的——C#和Java面对的是同样的问题，面向 应用领域的问题：事务处理、远程访问、Web service、Web页面发布、图形界面。 那么在这一段中，我暂且用Java这个名字指代Java和C#两种语言——尽管两者在细节 上确实有区别。 Java是适合解决应用领域的问题的语言。最大的原因Java对于使用者来说非常简 单。想想你学会并且能够使用Java需要多长时间，学会并且能够使用C++要多长时 间。由于Java很大程度上屏蔽了内存管理问题，而且没有那么多为了微小的性能提 升定义的特殊的内容（比如说，在Java里面没有virtual 这个关键字,Java也不允 许你直接在栈上创建对象，Java明确的区分bool和整型变量），他让你尽量一致的 方式操作所有的东西，除了基本数据类型，所有的东西都是对象，你必须通过引用 来操作他们；除了这些之外，Java还提供了丰富的类库帮助你解决应用问题——因为 它是面向应用的语言，它为你提供了多线程标准、JDBC标准、GUI标准，而这些标 准在C++中是不存在的，因为C++并不是直接面向解决应用问题的用户，有人试图在 C++中加入这些内容，但并不成功，因为C++本身太复杂了，用这种复杂的语言来实 现这种复杂的应用程序框架本人就是一件艰难的事情，稍后我们会提到这种尝试—— COM技术。渐渐的，人们不会再用C++开发应用领域的软件，象MFC\QT\COM这一类的 东西最终也将退出历史舞台。 2.1.3 Delphi Delphi是从用C++开发应用系统转向用Java开发应用系统的一个中间产物。它比C++ 简单，简单的几乎象Java一样，因为它的简单，定义和使用丰富的类库成为可能， 而且Delphi也这么做了，结果就是VCL和其他的组件库。而另一方面，它又比运行 于虚拟环境的java效率要高一些，这样在简单性和效率的平衡之中，Delphi找到了 自己的生存空间。而且预计在未来的一段时间之内，这个生存空间将仍然是存在 的。可以明显的看出，微软放弃了这个领域，他专注于两方面：系统语言C++和未 来的Java(其实是.Net)。也许这对于Borland来说，是一件很幸运的事情。如果我 能够给Borland提一些建议的话，那就是不要把Delphi弄得越来越复杂，如果那 样，就是把自己的用户赶到了C++或Java的领地。在虚拟机没有最终占领所有的应 用程序开发领域之前，Delphi和Delphi的用户仍然会生存得很好。 2.2 桌面应用程序框架 目前真正成功的桌面应用程序框架只有两个，一个是MFC，一个是VCL，还有一些 其他的，但事实上并未进入应用领域。遗憾的是我对两个桌面应用程序框架都不精 通。但这部不妨碍我对他做出正确的评价。 2.2.1 MFC MFC（还有曾经的OWL）是SDK编程的正常演化的结果，就象是C++是C的演化结果一 样。MFC本身是一件了不起但不那么成功的作品，而且它过时了。这就是我的结论。 MFC凝聚了很多天才的智慧——当然，OWL和VCL也一样，侯捷的《深入浅出MFC》把这些 智慧摆在了我们的面前。但是这件东西用起来估计不会有人觉得很舒服，如果你一 直在用Java、VB或者Delphi，再回过头来用MFC，不舒服的感觉会更加强烈。我不 能够解释MFC为什么没有能够最终发展成和VCL一样简单好用的桌面程序框架，也许 是微软没精力或者没动力，总之MFC就是那个样子了，而且也不会再有发展，它已 经被抛弃了。我有时候想，也许基于C++这种复杂的语言开发MFC这样的东西本身就 是错误的——可以开发这样的一个框架，但不应当要求使用它的人熟悉了整个框架之 后才能够使用这个系统，但很显然，如果你不了解MFC的内部机制，是不太可能把 它用好的，我不能解释清楚为什么会出现这种现象。 2.2.2 VCL 相比之下VCL要成功的得多。我相信很多使用VCL的人可能没有像MFC的用户研究MFC 那样费劲的研究过VCL的内部机制。但这不妨碍他们开发出好用好看的应用程序， 这就足够了，还有什么好说的呢？VCL给你提供了一种简单一致的机制，让你可以 写出复杂的应用程序。在李维的Borland故事那篇文章中曾经说过，在Borland C++3.1推出之后Borland就有人提出开发类似C++ Builder一类的软件，后来竟未成 行。是啊，如果C++Builder是在那个时候出现的，今天的软件开发领域将会是怎么 样的世界呢？真的不能想象。 也许再过一段时间，这些都将不再重要。因为新生的语言如Java和C#都提供了类 似于VCL的桌面应用程序框架。那个时候，加上Java和C#本身的简单性，如果他们 的速度有足够块，连Delphi这种语言也要消失了，还有什么好争论的呢？只是对于 今天的桌面程序开发人员来说，VCL确实是最好的选择。 2.3企业应用程序框架 2.3.1 Windows DNA Windows DNA的起源无从探究了。随着.Net的推出，事实上Windows DNA将成为历 史的陈迹。Windows DNA虽然是几乎所有的企业应用程序开发人员都知道的一个名 词，但我相信Windows DNA事实上应用的最广泛的是ASP而不是COM+。真正的COM开 发有多少人真正的掌握了呢，更不要提COM+(我有必要解释一下：COM+是COM的执行 环境，它提供了一系列如事务处理、安全等基础服务，让应用程序开发人员尽量少 在基础架构设计上花精力)——当然我这里指的COM开发不是指VB下的COM开发，所以 要这么说，是因为我觉得如果不能理解用C++进行COM开发，也就不能真正的理解 COM技术。如果以一种技术没有被广泛理解和应用作为失败的标志，那么Windows DNA实际上是失败了，但这不是它本身的错，而是基于C++的COM技术的失败造成 的。多层应用、系统开发角色分离的概念依然没有过时。 2.3.2 J2EE J2EE是第一套成功的企业应用程序开发框架。因为它把事务处理、远程访问、安全 这些概念带入了寻常百姓家。这种成功我认为要归因于Java的简单性。Java的简 单，对于J2EE容器供应商来说一样重要。开发一个基于Java的应用服务器要比基于 C++的更容易。而且由于Java的简单性，应用系统开发者出错的机会也会少一些， 不会像C++的开发者那样受到那么多挫折。开发基于Java的企业应用系统的周期会 更短，这恐怕是不容争辩的事实。不论如何，是J2EE让事务处理、远程访问、安全 这些原来几乎都是用在金融系统中的概念也被一般的企业用户使用并从中获得利益。 2.3.3 .NET .Net有什么好说的呢？其实，它不过是微软的J2EE。事务处理、安全、远程访 问，这些概念在.Net中都找得到。更有力的说明是，微软也利用了.Net实现了一个 Pet Store。所以，.Net与J2EE几乎是可以完全对等的。但微软确实是一家值得尊 敬的公司——我指从技术上，象Web form这种东西，我相信很多Web应用开发者都梦 想过甚至自己实现过，但Sun却一直无动于衷，而且似乎Borland也没有为此作过太 多努力，好像有过类似的东西，但肯定是不怎么成功——Borland已经很让人敬佩 了，我们也许无法要求太多。 2.4 COM技术 COM应当是个更广泛的词汇，其实我觉得AxtiveX、OLE、Automation、COM+都应当 提及，因为如果你不理解COM，上面的东西你是无法理解的。而且，我只是想说明 COM是一种即将消亡的技术，仅仅说说COM的复杂性和他的问题就够了，所以不会提 及那些东西。 为什么会出现COM技术？COM的根本目标是实现代码的对象化的二进制重用，进而实 现软件的组件化、软件开发工作的分工。这要求他做到两点：第一，能够跨越不同 的语言，第二，要跨越同一种语言的不同编译器。COM技术为这个目标付出了沉重 的代价，尤其是为了跨越不同的编译器，以至于无论对于使用者而言还是开发者而 言，他都是一个痛苦的技术。但幸运的事，这一切终归要结束了。 让我们从这个目的出发看看COM为什么会成为它现在的样子。 其实COM不是什么新玩意，最初的DLL就是重用二进制代码的技术。DLL在C的年代可 能还不错，但到了C++的年代就不行了。原因在于如果你在.h文件中改变了类定义 （增加或者减少了成员变量），代码库用户的代码必须重新编译才可以，否则用户 的代码会按你的旧类的结构为你的新类分配内存，这将产生什么后果可想而知。这 就是为什么通过接口继承和通过接口操作对象成为COM的强制规范的原因，能够通 过对象的方式组织代码是COM的重要努力。 那么著名的IUnknown 接口又是怎么回事呢？这是为了让使用不同编译器的C++开发 人员能够共享劳动成果。首先看QueryInterface，因为COM是基于接口的，那么一 个类可能实现了几个接口，而对于用户来说，你又只能通过操作接口来操作类，这 样你必须把类造型成某个特定的接口，使用Dynamic_cast吗？不行，因为这是编译 器相关的，那么，就只好把它放在类的实现代码中了，这就是QueryInterface的由 来。至于AddRef和Release，他们产生的第一个原因是delete这个操作要求一个类 具有虚析构函数（否则的话，他的父类的析构函数将不会被调用），但不幸的是不 同的编译器中虚析构函数在vtbl中的位置并不相同，这就是说你不能让用户直接调 用delete，那么你的COM对象必须提供自己删除自己的方法；另外的原因在于一个 COM对象可能作为几个接口在被用户同时使用，如果用户粗暴的删掉了某个接口， 那么其他的接口也就不能用了，这样，只好要求用户在想用一个接口的时候通过 AddRef通知COM对象“我要使用你了，你多了一个用户”，而在不用之后要调用 Release告诉COM对象“我不用你了，你少了一个用户”，如果COM对象发现自己没有 用户了，它就把自己删掉。 再看看诡异的HRESULT，这是跨语言和跨编译器的代价。其实，异常处理是物竞天 择的结果——连一直用效率作标榜的C++都肯牺牲效率来实现这个try-catch，可见它 的意义，但COM为了照顾那些低级的语言居然抛弃了这个特征——产生的结果就是 HRESULT。我们可以看看他是多么愚蠢的东西。首先，我们要通过一个整数来传递 错误信息，通过IErrorInfo来查找真正的错误描述，本来在现代语言中一个try- catch可以解决的问题，现在我们却需要让用户和开发者都走很多路才能解决，你 怎么评价这个结果？其次，由于这个返回计算结果的位置被占用了，我们不得不用 怪异的out参数来返回结果。想想一个简单的 int add(int op1,int op2)在COM中 竟然要变成HRESULT add(int op1,int op2,int *result)，我不知道你对此作何感 想。而且由于COM的方法无法返回一个对象而只能返回一个指针，为了完成一个简 单的std::string GetName()这一类的操作，你要费多少周折——你需要先分配一块 内存空间，然后在COM实现中把一个字符串拷贝到这个空间，用完了你要删掉这个 空间，不知道你是否觉得这种工作很幸福，反正我觉得很痛苦。 还有COM为了照顾那些解释性的语言，又加入了Automation技术，你有没有为此觉 得痛苦？本来一个简单的方法调用，现在却需要传给你一个标志变量，然后让你根 据这个标志变量去执行相应的操作。（这一点我现在仍然不明白，为什么解释性的 语言需要通过这个方式来执行一个方法）。 “我受够了，我觉得头痛”，你会说，是啊，我想所有的人都受够了，所有这些因素 实际上是把COM技术变成了一头让人无法驾驭的怪兽。人对复杂事物的掌控能力终 究是有限的，C++本身已经够复杂了， COM的复杂性已经超出了我们大部分人的控 制能力，你需要忍受种种痛苦得到的东西与你付出的代价相比是不是太不值得了？ 我们学习是为了解决问题，而现在我们却需要为了学习这件事情本身耗费太多的精 力。这些痛苦的东西太多了，我在这里说到的，其实只是一小部分而已。计算机技 术是为人类服务的，而不是少数人的游戏（我想COM技术可能是他的设计者和一部 分技术作者的游戏），难道我们愿意成为计算机的奴隶吗？通过一种过于复杂的技 术抛弃所有的人其实等于被所有的人抛弃，这么多年中选择J2EE的人我相信不乏高 手，你是不是因为COM的过于复杂才选择J2EE的？因为它可以用简单的途径实现差 不多的目标——软件的“二进制”重用、组件化、专业分工（容器开发商和应用开发商 的分工）。事实上，你是被微软所抛弃的，同时，你也抛弃了微软。 现在让我们回来吧，我把你带进了COM的迷宫，现在让我把你领回来。再让我们看 看COM到底想实现什么目标，其实很简单，不过是代码的二进制重用，也就是说你 不必给别人源代码，而且你的组件可以象计算机硬件那样“即插即用”。我们回过头 来看看Java，其实，这种二进制重用的困难是C++所带来的（这不是C++本身的错， 而是静态编译的错），当Java出现的时候，很多问题已经不存在了。你不需要一个 头文件，因为Java的字节码是自解释的，它说明了自己是什么样子的，可以做什么 事情，不像C++那样需要一个头文件来解释这些事情；也不需要事先了解对象的内 存结构，因为内存是在运行的时候才分配的。 如果我们现在再回过头来解决COM要解决的问题，你会怎么做呢？首先你会不再选 择C++这种语言来实现代码的“二进制”重用，其次，你会把所有的语言编译成同样 的“二进制” 代码（实际上，应当说是字节码），这显然是更聪明的做法，从前COM 试图在源代码的级别抹平二进制层次的差异，这实际上是让人在做本来应当由机器 做的事情，很愚蠢是吗？但他们一直做了那么多年，而且把这个痛苦带给了整个计 算机世界——因为他们掌握着事实的标准，为了用户，为了利润，为了能够在 Windows上运行，尽管你知道你在做着一个很不聪明的事情，但你还是做了。 COM技术为了照顾VB这个小兄弟和实现统一二进制世界的野心，实在浪费了太多的 精力。首先，落后的东西的消亡是必然的，就象C、Pascal在应用领域的消亡一 样，Basic一点一点的改良运动是不符合历史潮流的做法，先进的东西和落后的东 西在一起，要么先进的东西被落后的东西拖住后腿，要么是同化落后的东西，显然 我们更愿意看见后者，现在Basic终于被现代的计算机语言同化了。其次，统一二 进制世界好像不是那么简单的事情，而且也没什么必要，微软的COM技术奋战了10 年，现在也只有他自己和Borland支持，.Net终于放弃了这个野心。这一切终于要 结束了。过去J2EE高歌猛进地占领着应用开发的领地，COM在这种进攻面前多少显 得苍白无力。现在微软终于也有了可以和J2EE一较长短的.NET，对于开发人员来 讲，基于字节码的组件的二进制重用现在是天经地义的事情；你不用再为了能够以 类方式发布组件做那么多乱七八糟的事情，因为现在所有的东西本来就是类了；实 现软件开发的分工也很自然，你是专业人员，就用C#吧，你是应用开发人员，你喜 欢用VB.Net，你就用吧，反正你们写的东西最终都被翻译成了一样的语言（其实我 觉得这一点意义不大，因为一些不那么好用的语言被淘汰是正常的事情，C风格成 为程序设计语言的主流风格，肯定是有它的原因的，语言的统一其实是大势所趋， 就象中国人民都要说普通话一样，所以我觉得Java不支持多语言算不上缺点——本来 就是一种很好看很好用的语言了，为什么要把简单问题复杂化呢？）。 COM不会在短期内死去，因为我估计微软还不会马上用C#开发Office和Windows的图 形界面部分，但我相信COM技术退出历史舞台的日子已经不远了，作为一般的开发 人员，忘了这段不愉快的历史吧——你将不会在你的世界里直接和COM打交道。 若干年以后，我想COM也许会成为一场笑话，用来讽刺那种野心过大、钻牛角尖的 愚蠢的聪明人。 结论 说了很多，应该是有个结论的时候了。我似乎做了一件冒天下之大不韪的事情， 因为我评价了主流技术，还要试图进行比较，好像某个名人说过：“C++Builder也 好，Visual C++也好，能在市场上立足，肯定都是有自己的过人之处的，而且一个 人精通数种开发语言、数种开发工具是不可能的事情”，言下之意就是说你不要对 这些东西妄加评论，但怎么可以不评论？好像高手都不屑于说哪种语言好、哪种语 言坏，我不知道什么时候形成了这种风气。简单地说C++比Java好或者Java比C++好 显然是愚蠢的行为，但如果让你用Java写驱动程序，用C++开发一个MIS系统是不是 愚蠢的行为呢？显然更愚蠢。我想，作为一个独立的能思考的人，外界的东西对你 而言总是有好有坏，而且你的生命有限，你还要享受你的生活，所以你必须做出选 择。所以，起码评价这些东西对我自己而言是正确的——只要我有能力评价，那我就 说出我的评价吧。 对于计算机语言来说，未来真正重要的语言只有三种C++、Java和C#。 C++将更适合于专业的计算机公司编写图形界面系统（比如KDE）、虚拟机（比如 Java虚拟机或者.Net运行环境）、杀毒软件或者其他的盒装软件（比如说 Photoshop、Dream weaver）这一类的东西。而且C++适合程序员做学习之用，能对 C++有一定理解的程序员往往也应该能更深刻的理解Java、C#，这有助于编写更好 的软件。 如果是开发为客户定制的应用系统Java、C#是更好的选择。包括桌面应用和Web应 用。至于其他的语言比如VB.Net其实并没有太大的意义。 Delphi在未来一段时间将继续存在，而且活得不错。最重要的原因在于，第一它有 一套丰富的组件库，第二它效率相对算高的，第三它简单。如果虚拟机的执行效率 赶不上Delphi，它就有存在的理由，但从过去的Visual J++来看，微软的虚拟机做 得确实可以很好，加上.Net的组件库和C#的简单性并不差，所以从长远来看Delphi 可能不那么乐观。 其实上面的比较也包含了桌面应用程序框架的比较。在现在来说VCL无疑最好的， MFC已经退出历史舞台。.Net中所带的桌面应用程序框架将最终统一桌面应用领域 （但不包括微软和Borland这样的专业公司，因为他们要作出最好用而且效率最高 的软件）。至于Java中所带的桌面应用程序框架，实在让人哭笑不得。这个结论的 变数是.Net运行环境的执行效率。如果.Net中的虚拟机象Java的一样，那微软就倒 霉了，它等于放弃了桌面应用开发工具领域，但根据微软在Visual J++上的成就和 他推广.Net的背水一战的驾式，.Net在桌面领域失败的可能性不大（但不是没有， 起码基于COM的技术在企业应用领域几乎可以说是全军覆没）。 在企业应用程序框架领域，最终只有J2EE和.Net可以决一雌雄。我没有提到 CORBA，它也可以算是企业应用程序框架，但他的声势和J2EE或者.NET实在不能同 日而语，而且最重要的是只有Borland一家大公司支持它（SUN、IBM、BEA、 Borland支持J2EE，微软就不用说了），所以就不详细说他了。 那么最终谁会赢呢？我想微软赢的可能性大一些。这样说可能让很多人不快，而且 IBM的厉害也是有目共睹的。但这并不是纯技术问题，就象Windows NT蚕食Unix的 领土那样，那时候微软也是孤军作战。J2EE的问题在于第一：混乱，第二，价高。 我相信很多人都对这两点有过不快的经历。你知道写给Weblogic的应用程序不是很 顺利地就可以移植到Websphere上的，反过来也一样。但.Net就不一样了，那是微 软一个人的作品，根本不存在移植的问题。如果J2EE阵营不想败在这一点上，有三 个办法，第一种就是通过制定统一的标准彻底消灭移植问题，第二种是开发一种好 用的部署工具（不能象JBuilder那么大、那么慢：），屏蔽不同的应用程序容器之 间的区别，第三种，也是最不可能的，就是J2EE阵营有人能够一统天下。显然，这 三种解决办法都不太现实。 第二点价高，这是SUN、IBM、BEA、ORACLE传统，也是它们一直让微软的进攻屡屡 得手的软肋。我一直不太能明白他们的西就为什么那么贵。这样想一想：微软的 .Net SDK白送给你，BEA的Weblogic一个CPU的License两万，如果你两种技术都 会，如果你给客户的系统报价一样，你选哪种开发技术？这一点实在让人觉得无可 奈何。J2EE有的东西，.Net也有（除了不能跨平台），技术上的细微差别在巨大的 价格差异面前还有什么意义呢？ 当然，SUM、IBM这些大公司也不是等闲之辈。就象Windows NT没有消灭Unix一样， J2EE应当会像Windows NT和Unix的共存一样和.Net共存，只是我想.Net恐怕会占上 风。 闲话 说完了该说的技术问题，说说闲话吧。有的话放在心里觉得不说出来不舒服，且让 我一吐为快:) 给入门程序员的建议 不知道我在学计算机的时候是不是走了弯路。但我想如果让我重新开始学写程序 的话，我会采用一些不同的办法。如果你也正在想成为一个程序员，这些也许会对 你有帮助。 我觉得可能大概要分几个阶段，第一个阶段应该是找一门简单的语言入门，比如 Java或者C#都应该比较合适，选一本简单的带例子的书（最好不要太厚），按部就 班的把书学完。这时候可能还有些懵懵懂懂，但没关系，可以开始做个小小的软件 了，重要的事你要自己用那种语言的方式想思考，如果有项目做，当然更好。之 后，你会觉得有点感觉了。如果你象我一样不是科班出身的，接下来应当补习一下 计算机专业的课程，我觉得最重要的是数据结构——那些东西你可能永远都不会自己 做，C++中有漂亮的STL，Java中也为你实现了大部分东西，但我觉得真的有必要学 习那些内容，这会加强你用计算机语言思考问题的能力。在进一步，如果你的入门 语言不是C++，那你可以补习一下C++，尽管你可能永远都不会用C++开发程序。C++ 在现在的计算机世界就象是普通话一样，而且它能让你很容易的理解其他语言中难 以理解的问题。 学完了C++，那你应当就已经不是一个初级程序员了，欢迎你进入计算机软件开发 的世界。 印度的软件业 我记得好像在CSDN上看见过一篇文章，极力的鼓吹印度的软件业。而且我记得他 好像说过一句很刻薄的话“我们公司那些B大的和T大的，一个一个特别牛，牛得看 不见人……做起界面极尽奇迹淫巧之能事……”，诸如此类，总之认为程序员只有象印 度的高中生那样乖乖的、懂得UML、会看Function Specification才算是真正的程 序员。我当时觉得很不舒服。我想这个人应该不是B或T大的——哦，别误会，我也不 是——但我觉得好像B大的T大的人没象他说的那样。而且我不明白为什么中国的软件 业为什么一定要向印度看齐？作为一家公司，你想获取商业利润，学习印度无可厚 非，你大可以找一大堆高中生培训成编程蓝领（我没有轻视高中生的意思，我相信 有很多“高中生”在技术领域取得的成就是让我望尘莫及的），但你不应该因此就把 有血有肉有个性的程序员扁得一钱不值。说实话，所谓的编程蓝领不过是工厂里面 的装配工，如果有一天工厂里面换了自动化的设备，这些人就全成了废人！而你要 知道并不是这些装配工发明了自动化机器。我想这种话用不着多说，子曰“过犹不 及”，你可以喜欢变成蓝领，但不要把问题推向极端，把问题推向极端往往就会犯 错误。我们中国可以在某种程度上学习印度，但好像我们更应该学习美国——只是我 们现在没那么富裕——可是微软也不是从一开始就是这样一个伟大的帝国的，IBM也 一样。 附录 参考书目 阅读如下图书有助于理解本文内容。而且这些书都是好书，值得一读。 * 《标准C++宝典》 * 《C++编程思想》 * 《深入浅出MFC2e》 * 《COM技术内幕》 * 《COM本质论》 * 《Java编程思想》 * 《精通EJB》第二版 * 《J2EE编程指南》 * 《Delphi 6开发人员指南》 * 《C#宝典》 * 《微软 .Net战略》 对该文的评论 fmscole/(2003-1-7 23:07:13)/ 辛苦了，不过再过一年或许你的想法会反过来，如果这一年你还在认真钻研的话 SunLi/(2003-1-7 9:50:41)/ 不错，值得一读，不过太长了，我没有耐心看完。看得出作者在软件设计领域有很 深的功底。无论怎样，能静下心来写出这么长的文章已是不错的了。谢谢 longbow74/(2003-1-7 9:10:26)/ 建议刚毕业的程序员都读一读,不过我还有个更好的建议,就是别做程序员,要是有 其它选择的话 longbow74/(2003-1-7 9:08:47)/ 建议刚毕业的程序员都看一看,但我还有个更好的建议,就是别做程序员,要是有别 的选择的话 andyx/(2003-1-7 8:08:50)/ 写的好！ whatkindu/(2003-1-6 22:37:54)/ cool,太cool了,cool毙了.谢谢bjhua的文章,不过C#哥们还是在忧郁中. zw84611/(2003-1-6 22:36:56)/ “MFC已经退出历史舞台”了？ zw84611/(2003-1-6 20:32:47)/ aaa zw84611/(2003-1-6 20:32:21)/ “MFC已经退出历史舞台”了？ firingme/(2003-1-6 19:46:34)/ 哈哈…………原来不止我一个人不会COM阿~！呵呵…… 幸好要过时了 liuwei89/(2003-1-6 17:33:55)/ 这是一个普通程序员写的东西，一看就亲切，我喜欢。最讨厌所谓的专家之类的东西！ liuwei89/(2003-1-6 17:33:26)/ 这是一个普通程序员写的东西，一看就亲切，我喜欢。最讨厌所谓的专家之类的东西！ liagl/(2003-1-6 17:15:47)/ 我觉得.NET和J2EE太慢又不灵活，所以界面程序我用Delphi写，高性能模块我用VC 写，Web服务我用Java写，中间用TCP/IP通信，业务逻辑用商用数据库强大的存储 过程实现。是比较麻烦，我也是被避的，我开始做企业开发的时代还没有J2EE和 .NET，好处是系统速度快(都还达不到用户的要求)，缺点是软件蓝领们很难维护程 序，我提倡大家不要完全跟着外国公司走，否则我们自己的软件技术永远都在别人 后面。 liagl/(2003-1-6 17:09:49)/ 我觉得.NET和J2EE太慢又不灵活，所以界面程序我用Delphi写，高性能模块我用VC 写，Web服务我用Java写，中间用TCP/IP通信，业务逻辑用商用数据库强大的存储 过程实现。是比较麻烦，我也是被避的，我开始做企业开发的时代还没有J2EE和 .NET，好处是系统速度快(都还达不到用户的要求)，缺点是软件蓝领们很难维护程 序，我提倡大家不要完全跟着外国公司走，否则我们自己的软件技术永远都在别人 后面。 liagl/(2003-1-6 17:09:35)/ 我觉得.NET和J2EE太慢又不灵活，所以界面程序我用Delphi写，高性能模块我用VC 写，Web服务我用Java写，中间用TCP/IP通信，业务逻辑用商用数据库强大的存储 过程实现。是比较麻烦，我也是被避的，我开始做企业开发的时代还没有J2EE和 .NET，好处是系统速度快(都还达不到用户的要求)，缺点是软件蓝领们很难维护程 序，我提倡大家不要完全跟着外国公司走，否则我们自己的软件技术永远都在别人 后面。 liagl/(2003-1-6 16:48:04)/ 我的程序人生观是与垄断作坚决斗争，何况J2EE和.NET慢得象蜗牛。所以界面我用 Delphi写，高性能模块我用VC写(象GIS系统上的最优路径，成千上万的点、多边形 的复杂运算，VC都慢)，Web服务用Java，各部分之间用TCP/IP通信，对了说少了业 务层，用存储过程，即强大效率又高(最长的存储过程我写了5页，累啊，差不多到 我的极限了，看来我的资子还是...唉)。 总之我觉得，完全跟着外国公司走我们的软件技术太不可靠了。 williy/(2003-1-6 16:39:46)/ 呵呵。。。写了这么多一定很累！辛苦了辛苦了！ 感谢！！！！！！ williy/(2003-1-6 16:39:25)/ 呵呵。。。写了这么多一定很累！辛苦了辛苦了！ 感谢！！！！！！ javanew/(2003-1-6 16:32:35)/ 你好象很牛哦 :O alanon99/(2003-1-6 15:41:49)/ 学习中,收藏! alanon99/(2003-1-6 14:54:08)/ 学习中, 收藏! alanon99/(2003-1-6 14:51:52)/ 学习中, 收藏! lixinwyh/(2003-1-6 13:23:39)/ 又看到有人在批评mfc所以忍不住说两句：）你有真的仔细看过mfc吗？mfc是最符 合windows api用法的封装，我开始用的delphi，后来用的bcb，当我看到mfc和 windows api的时候根本就看不明白怎么回事，因为vcl都封装成了自己的东西。而 且vcl有的东西封装到了底层，改起来非常困难。而且什么都要可视化，有的东西 叫人难以忍受，偶恨透了vcl的这种可视化。mfc要被淘汰了，这句话微软也没有说 过吧，mfc也有大量的第三方的类库，只是国内很少有人提到。所以不要人云亦 云，还是要自己多了解以后在发表评论。 c++的stl确实是个很好的东西，这是我最喜欢c++的地方：） 另外的说到c++做mis，用c++builder是件很容易的事情，mfc应该也不难（我没做 过，只是看了看书）。 vcnewer/(2003-1-6 12:37:42)/ 有点豁然开朗的感觉，　 佩服作者 tonytan/(2003-1-6 12:07:41)/ 见解虽不深刻，但我同意 andyx/(2003-1-6 11:54:23)/ 好！！！ hsb0307/(2003-1-6 11:18:10)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 hsb0307/(2003-1-6 11:15:04)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 hsb0307/(2003-1-6 11:13:21)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 hsb0307/(2003-1-6 11:12:28)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 andyx/(2003-1-6 11:12:26)/ 谢谢你这篇文章，让我有豁然开朗的感觉。 或许会有很多人会对你这篇文章里的某些观点有不同的意见， 但是不妨碍我从中得到了很多的收获！ hsb0307/(2003-1-6 11:12:06)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 hsb0307/(2003-1-6 11:11:37)/ 我觉得VCL、MFC、COM、J2EE、.NET都是解决方案，他们的其中一个目标是解决软 件复用问题。 VCL解决了源代码级的软件复用问题 COM解决了机器码级的软件复用问题 源代码→win32应用程序→windowsOS 但二者都没有解决根本问题：将类编译为机器码，而且能在源代码中直接使用类的 属性与方法。 我们期待能将类编译为机器码，而且能在源代码中直接使用类的属性与方法，VCL 与COM都不能解决，毕竟源代码与机器码之间跨度太大，他们互不认识，于是更好 地解决方案：J2EE、.NET出现了，这二者引入了虚拟机的思想，在源代码与机器码 之间加入了虚拟机这一层，源代码→中间语言→虚拟机→windowsOS，实现了软件复用 问题。但引入了虚拟机，降低了效率。以后肯定还有更好地解决方案。 amstrongest/(2003-1-6 10:54:14)/ 第一给我留言的冲动 好文 caimouse/(2003-1-6 10:40:00)/ 开发所有应用程序,还是C++最快,有两方便,一个是效率,一个是速度. 如果想写服务器的,用VC,C++BUILDER. 如果写客户应用程序的话用C++BUILDER,可以说开发来程序比JAVA要快多了. 用C++BUILDER,四个人用四个月就开发100 0000元项目. andyx/(2003-1-6 10:38:48)/ 如饮甘露！！！ andyx/(2003-1-6 9:46:30)/ 如饮甘露！！！ andyx/(2003-1-6 9:37:17)/ 如饮甘露！！！ andyx/(2003-1-6 9:36:58)/ 如饮甘露！！！ andyx/(2003-1-6 9:36:06)/ 如饮甘露！！！ headzg/(2003-1-6 9:23:52)/ 看来你对delphi的确是不懂！对于不懂的东西不要妄加评论 headzg/(2003-1-6 9:23:42)/ 看来你对delphi的确是不懂！对于不懂的东西不要妄加评论 iwad/(2003-1-5 19:40:49)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ iwad/(2003-1-5 19:40:43)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ iwad/(2003-1-5 19:40:38)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ iwad/(2003-1-5 19:40:19)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ iwad/(2003-1-5 19:39:46)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ iwad/(2003-1-5 19:39:21)/ 作者的论点非常精辟，论述得相当精彩。尽管我也是一年前才明白这些道理，但我 还是看了两遍！说句实在话是想挑点毛病的，可是最后不得不对作者肃然起敬。看 来是不是科班出身不要紧，要紧的是有没有学过科班的课。我上数据结构课的时候 总是睡觉，现在想起来真是要吐血啊！决定狂补！ freebird9/(2003-1-5 19:13:53)/ 该如何讲呢,首先,楼上的dx应该是个技术大拿,分析的透彻痛快! 谈一下俺的几个观点: com虽然比较复杂,但是现在有一些技术(比如atl)可以在一定程度上面屏蔽底层的 复杂,不过要注重效率复杂性肯定比较高.只不过许多情况下效率的问题不是很突 出,因此俺使用vb作的组件运行的还是满不错的.但是一些涉及与系统相关的功能比 较多的组件还是非得使用atl不可. com虽然技术上面比较复杂,但是体现的思想却是比较先进的(姑且这么说吧),就是 面向接口编程,其实说白了就是调用函数不是根据函数名字而是根据在vtable中的 偏移量而已.这个思想在c++中就是虚函数.而java则更进一步,把接口作为其语言的 一部分.在java的世界里面程序员可以非常快乐的使用接口,而不用知道下面到底是 如何实现的.但这对于c++程序员来说好像是一种无知的快乐. 使用java很容易与"模式"连接起来,而且现在越来越多的人都认识到模式的重要性, 这应该是一个好现象,因为对于程序员来说能够跳出语言的羁绊而上升到模式的高 度,其技术水平是一个相当大的提高.使用java来体现模式的思想的确非常有优势, 在这个过程中语言的影响比较轻. mfc的复杂应该也是ms无奈之举,桌面级的应用对性能的要求近乎苛刻,因此使用各 种极端得手段来达到目的也有其道理.俺用过永中office,java写的,在1G的机器上 面的速度大概就类似p166上面跑office.还有使用java写的类似winamp的mp3播放 器,除了能够播放mp3外其它照winamp差的太多了.俺曾经用过Sun的Forte,整个界面 全部是使用awt作出来的,深刻的印象就是"慢".等到回到Vs中竟然有一种如释重负 的感觉.Java发展了这么多年,真正可用的像样些的IDE环境仍然难找,许多人竟然以 使用记事本 来开发程序自夸.估计他们掌握了如何使用机器码编写程序会更 加快乐.计算机的发展应该是越来越方便,能够让机器替我们作尽可能多的无聊的工 作,就象俺的Vs中的Visual Assistant一样替我记住那些成百上千的api. 关于java现在好像主要应用在J2EE中,现在好像只要标明自己的项目是基于j2ee的 立马就会高人一等,不过俺见到的大部分都是基于asp+sqlserver的"档次低"的项 目,基于j2ee的很少见到.可能有人会说基于j2ee的都是"大项目"主要用在银行电信 等.可是要知道象这样的恐龙级单位一般的公司是不可能插手的,而且这样的单位会 要求你进行长期的服务,不过这也是好事,你可以不用学习其它的东东,就一口吃定 他了.基于ms体系的项目一般比较"小"比较灵活,开发部署一般比较快,而且对于这 一个级别的应用来说安全性足够了.其实也无所谓,只要有money就行.说到安全性稳 定性,业界统一认为ms<unix,只是对于一般级别的应用而言ms的安全性和稳定性 还是过得去的,俺们的一个项目中的sql服务器连续运行了一年仍然完好,而另一个 项目的sql不到半年服务就启动不了了,过去才知道原来是"管理员"弄了个盗版光盘 塞到光驱而且autorun,然后就...如果这是个unix的机器而且不要使用xwindows,估 计这个管理员连打开光驱都办不到!这可能也是unix比windows稳定的一个原因. 俺们现在的项目都是基于ms的技术,有很多是在com+上面完成的,j2ee也看过一些, com+和j2ee中很多内容都是类似的,不过感觉如果转向j2ee开发成本太高,而且对于 俺们作的这些"小项目"体现不出什么优势. "Java之战SUN再次挫败微软,Sun的圣诞礼物：微软需在Windows嵌入Java"---看到 这样的消息俺对Sun有种说不出的感觉,如果非要说出来的话,两个字:"恶心"!虽然 作为商业竞争各种下流的作法都可能出现,比如ms挖人墙角等等,但是Sun的如此作 法简直与街头的地痞无赖没有分别了.竞争归竞争,在推动技术的进步方面俺认为 Sun远远不及ms! 一些胡言乱语,见笑了. fortune999@eyou.com win32c/(2003-1-5 17:00:08)/ C#更多的是个政治的产物而不是技术产物。如果不是Sun为难微软的话，我想微软 不会费尽心力推出一个和Java差不多的C++++ 老大 ，专业点OK! win32c/(2003-1-5 16:58:29)/ C#更多的是个政治的产物而不是技术产物。如果不是Sun为难微软的话，我想微软 不会费尽心力推出一个和Java差不多的C++++ 老大，专业点OK！ dragon2002/(2003-1-5 16:13:51)/ 为什么对linux 极其应用不做平论???? dragon2002/(2003-1-5 16:11:09)/ good zhuyanwei/(2003-1-5 14:26:16)/ 先尝试一下,,..csdn的页面实在是不敢恭维。。。。 zhuyanwei/(2003-1-5 14:24:57)/ 先尝试一下能否评论 Flwu/(2003-1-5 13:31:43)/ 我怎么那么不喜欢Java dockbar/(2003-1-5 13:01:26)/ 有些内容 但不多。 观点过于偏激 我个人不大喜欢这种文章。 呵呵 dockbar/(2003-1-5 12:58:00)/ 有些内容 但不多。 观点过于偏激 我个人不大喜欢这种文章。 呵呵 McwoLF/(2003-1-5 12:42:37)/ KAO,把我想说的都说了！ spdia/(2003-1-5 12:29:41)/ 不错，有见地。尤其是说java是面向应用的语言，恰到好处。 McwoLF/(2003-1-5 12:09:49)/ COM部分评的很精彩！ McwoLF/(2003-1-5 12:07:28)/ COM部分评的很精彩！ McwoLF/(2003-1-5 12:04:50)/ COM评的很精彩！ McwoLF/(2003-1-5 11:57:51)/ COM部分讲的很精彩 McwoLF/(2003-1-5 11:57:19)/ COM部分讲的很精彩 leowangyu/(2003-1-5 11:05:37)/ delphi不会消失的,2003年即将推出的delphi.net版本将全面兼容vcl和net framework,例如,在实现xml方面,vcl和net framework都提供了一套基于dom的方 案,这给程序员以更多的选择性,并且还有更多的专业公司,提供源码级的解决方案, 比如turbo power的xmlpro,,,, 如果要我来选择,未来方向肯定是.net 如果delphi真能向他说承诺的那样,提供完全的.net支持 我仍旧会选择delphi,而不是c# dujianyong/(2003-1-5 10:44:27)/ 一派糊言！ dujianyong/(2003-1-5 10:43:45)/ 糊语乱语！ freebird9/(2003-1-5 10:07:38)/ 该如何讲呢,首先,楼上的dx应该是个技术大拿,分析的透彻痛快! 谈一下俺的几个观点: com虽然比较复杂,但是现在有一些技术(比如atl)可以在一定程度上面屏蔽底层的 复杂,不过要注重效率复杂性肯定比较高.只不过许多情况下效率的问题不是很突 出,因此俺使用vb作的组件运行的还是满不错的.但是一些涉及与系统相关的功能比 较多的组件还是非得使用atl不可. com虽然技术上面比较复杂,但是体现的思想却是比较先进的(姑且这么说吧),就是 面向接口编程,其实说白了就是调用函数不是根据函数名字而是根据在vtable中的 偏移量而已.这个思想在c++中就是虚函数.而java则更进一步,把接口作为其语言的 一部分.在java的世界里面程序员可以非常快乐的使用接口,而不用知道下面到底是 如何实现的.但这对于c++程序员来说好像是一种无知的快乐. 使用java很容易与"模式"连接起来,而且现在越来越多的人都认识到模式的重要性, 这应该是一个好现象,因为对于程序员来说能够跳出语言的羁绊而上升到模式的高 度,其技术水平是一个相当大的提高.使用java来体现模式的思想的确非常有优势, 在这个过程中语言的影响比较轻. mfc的复杂应该也是ms无奈之举,桌面级的应用对性能的要求近乎苛刻,因此使用各 种极端得手段来达到目的也有其道理.俺用过永中office,java写的,在1G的机器上 面的速度大概就类似p166上面跑office.还有使用java写的类似winamp的mp3播放 器,除了能够播放mp3外其它照winamp差的太多了.俺曾经用过Sun的Forte,整个界面 全部是使用awt作出来的,深刻的印象就是"慢".等到回到Vs中竟然有一种如释重负 的感觉.Java发展了这么多年,真正可用的像样些的IDE环境仍然难找,许多人竟然以 使用记事本 来开发程序自夸.估计他们掌握了如何使用机器码编写程序会更 加快乐.计算机的发展应该是越来越方便,能够让机器替我们作尽可能多的无聊的工 作,就象俺的Vs中的Visual Assistant一样替我记住那些成百上千的api. 关于java现在好像主要应用在J2EE中,现在好像只要标明自己的项目是基于j2ee的 立马就会高人一等,不过俺见到的大部分都是基于asp+sqlserver的"档次低"的项 目,基于j2ee的很少见到.可能有人会说基于j2ee的都是"大项目"主要用在银行电信 等.可是要知道象这样的恐龙级单位一般的公司是不可能插手的,而且这样的单位会 要求你进行长期的服务,不过这也是好事,你可以不用学习其它的东东,就一口吃定 他了.基于ms体系的项目一般比较"小"比较灵活,开发部署一般比较快,而且对于这 一个级别的应用来说安全性足够了.其实也无所谓,只要有money就行.说到安全性稳 定性,业界统一认为ms<unix,只是对于一般级别的应用而言ms的安全性和稳定性 还是过得去的,俺们的一个项目中的sql服务器连续运行了一年仍然完好,而另一个 项目的sql不到半年服务就启动不了了,过去才知道原来是"管理员"弄了个盗版光盘 塞到光驱而且autorun,然后就...如果这是个unix的机器而且不要使用xwindows,估 计这个管理员连打开光驱都办不到!这可能也是unix比windows稳定的一个原因. 俺们现在的项目都是基于ms的技术,有很多是在com+上面完成的,j2ee也看过一些, com+和j2ee中很多内容都是类似的,不过感觉如果转向j2ee开发成本太高,而且对于 俺们作的这些"小项目"体现不出什么优势. "Java之战SUN再次挫败微软,Sun的圣诞礼物：微软需在Windows嵌入Java"---看到 这样的消息俺对Sun有种说不出的感觉,如果非要说出来的话,两个字:"恶心"!虽然 作为商业竞争各种下流的作法都可能出现,比如ms挖人墙角等等,但是Sun的如此作 法简直与街头的地痞无赖没有分别了.竞争归竞争,在推动技术的进步方面俺认为 Sun远远不及ms! 一些胡言乱语,见笑了. fortune999@eyou.com spdia/(2003-1-5 2:34:22)/ 佩服有见地，尤其说java是面向应用的语言，简直是点睛之笔。 spdia/(2003-1-5 2:27:20)/ 有见地，佩服。尤其是说java是面向应用的语言，真是恰到好处的评价。 freebird9/(2003-1-4 23:30:43)/ 该如何讲呢,首先,楼上的dx应该是个技术大拿,分析的透彻痛快! 谈一下俺的几个观点: com虽然比较复杂,但是现在有一些技术(比如atl)可以在一定程度上面屏蔽底层的 复杂,不过要注重效率复杂性肯定比较高.只不过许多情况下效率的问题不是很突 出,因此俺使用vb作的组件运行的还是满不错的.但是一些涉及与系统相关的功能比 较多的组件还是非得使用atl不可. com虽然技术上面比较复杂,但是体现的思想却是比较先进的(姑且这么说吧),就是 面向接口编程,其实说白了就是调用函数不是根据函数名字而是根据在vtable中的 偏移量而已.这个思想在c++中就是虚函数.而java则更进一步,把接口作为其语言的 一部分.在java的世界里面程序员可以非常快乐的使用接口,而不用知道下面到底是 如何实现的.但这对于c++程序员来说好像是一种无知的快乐. 使用java很容易与"模式"连接起来,而且现在越来越多的人都认识到模式的重要性, 这应该是一个好现象,因为对于程序员来说能够跳出语言的羁绊而上升到模式的高 度,其技术水平是一个相当大的提高.使用java来体现模式的思想的确非常有优势, 在这个过程中语言的影响比较轻. mfc的复杂应该也是ms无奈之举,桌面级的应用对性能的要求近乎苛刻,因此使用各 种极端得手段来达到目的也有其道理.俺用过永中office,java写的,在1G的机器上 面的速度大概就类似p166上面跑office.还有使用java写的类似winamp的mp3播放 器,除了能够播放mp3外其它照winamp差的太多了.俺曾经用过Sun的Forte,整个界面 全部是使用awt作出来的,深刻的印象就是"慢".等到回到Vs中竟然有一种如释重负 的感觉.Java发展了这么多年,真正可用的像样些的IDE环境仍然难找,许多人竟然以 使用记事本 来开发程序自夸.估计他们掌握了如何使用机器码编写程序会更 加快乐.计算机的发展应该是越来越方便,能够让机器替我们作尽可能多的无聊的工 作,就象俺的Vs中的Visual Assistant一样替我记住那些成百上千的api. 关于java现在好像主要应用在J2EE中,现在好像只要标明自己的项目是基于j2ee的 立马就会高人一等,不过俺见到的大部分都是基于asp+sqlserver的"档次低"的项 目,基于j2ee的很少见到.可能有人会说基于j2ee的都是"大项目"主要用在银行电信 等.可是要知道象这样的恐龙级单位一般的公司是不可能插手的,而且这样的单位会 要求你进行长期的服务,不过这也是好事,你可以不用学习其它的东东,就一口吃定 他了.基于ms体系的项目一般比较"小"比较灵活,开发部署一般比较快,而且对于这 一个级别的应用来说安全性足够了.其实也无所谓,只要有money就行.说到安全性稳 定性,业界统一认为ms<unix,只是对于一般级别的应用而言ms的安全性和稳定性 还是过得去的,俺们的一个项目中的sql服务器连续运行了一年仍然完好,而另一个 项目的sql不到半年服务就启动不了了,过去才知道原来是"管理员"弄了个盗版光盘 塞到光驱而且autorun,然后就...如果这是个unix的机器而且不要使用xwindows,估 计这个管理员连打开光驱都办不到!这可能也是unix比windows稳定的一个原因. 俺们现在的项目都是基于ms的技术,有很多是在com+上面完成的,j2ee也看过一些, com+和j2ee中很多内容都是类似的,不过感觉如果转向j2ee开发成本太高,而且对于 俺们作的这些"小项目"体现不出什么优势. "Java之战SUN再次挫败微软,Sun的圣诞礼物：微软需在Windows嵌入Java"---看到 这样的消息俺对Sun有种说不出的感觉,如果非要说出来的话,两个字:"恶心"!虽然 作为商业竞争各种下流的作法都可能出现,比如ms挖人墙角等等,但是Sun的如此作 法简直与街头的地痞无赖没有分别了.竞争归竞争,在推动技术的进步方面俺认为 Sun远远不及ms! 一些胡言乱语,见笑了. fortune999@eyou.com freebird9/(2003-1-4 23:27:44)/ 该如何讲呢,首先,楼上的dx应该是个技术大拿,分析的透彻痛快! 谈一下俺的几个观点: com虽然比较复杂,但是现在有一些技术(比如atl)可以在一定程度上面屏蔽底层的 复杂,不过要注重效率复杂性肯定比较高.只不过许多情况下效率的问题不是很突 出,因此俺使用vb作的组件运行的还是满不错的.但是一些涉及与系统相关的功能比 较多的组件还是非得使用atl不可. com虽然技术上面比较复杂,但是体现的思想却是比较先进的(姑且这么说吧),就是 面向接口编程,其实说白了就是调用函数不是根据函数名字而是根据在vtable中的 偏移量而已.这个思想在c++中就是虚函数.而java则更进一步,把接口作为其语言的 一部分.在java的世界里面程序员可以非常快乐的使用接口,而不用知道下面到底是 如何实现的.但这对于c++程序员来说好像是一种无知的快乐. 使用java很容易与"模式"连接起来,而且现在越来越多的人都认识到模式的重要性, 这应该是一个好现象,因为对于程序员来说能够跳出语言的羁绊而上升到模式的高 度,其技术水平是一个相当大的提高.使用java来体现模式的思想的确非常有优势, 在这个过程中语言的影响比较轻. mfc的复杂应该也是ms无奈之举,桌面级的应用对性能的要求近乎苛刻,因此使用各 种极端得手段来达到目的也有其道理.俺用过永中office,java写的,在1G的机器上 面的速度大概就类似p166上面跑office.还有使用java写的类似winamp的mp3播放 器,除了能够播放mp3外其它照winamp差的太多了.俺曾经用过Sun的Forte,整个界面 全部是使用awt作出来的,深刻的印象就是"慢".等到回到Vs中竟然有一种如释重负 的感觉.Java发展了这么多年,真正可用的像样些的IDE环境仍然难找,许多人竟然以 使用记事本 来开发程序自夸.估计他们掌握了如何使用机器码编写程序会更 加快乐.计算机的发展应该是越来越方便,能够让机器替我们作尽可能多的无聊的工 作,就象俺的Vs中的Visual Assistant一样替我记住那些成百上千的api. 关于java现在好像主要应用在J2EE中,现在好像只要标明自己的项目是基于j2ee的 立马就会高人一等,不过俺见到的大部分都是基于asp+sqlserver的"档次低"的项 目,基于j2ee的很少见到.可能有人会说基于j2ee的都是"大项目"主要用在银行电信 等.可是要知道象这样的恐龙级单位一般的公司是不可能插手的,而且这样的单位会 要求你进行长期的服务,不过这也是好事,你可以不用学习其它的东东,就一口吃定 他了.基于ms体系的项目一般比较"小"比较灵活,开发部署一般比较快,而且对于这 一个级别的应用来说安全性足够了.其实也无所谓,只要有money就行.说到安全性稳 定性,业界统一认为ms<unix,只是对于一般级别的应用而言ms的安全性和稳定性 还是过得去的,俺们的一个项目中的sql服务器连续运行了一年仍然完好,而另一个 项目的sql不到半年服务就启动不了了,过去才知道原来是"管理员"弄了个盗版光盘 塞到光驱而且autorun,然后就...如果这是个unix的机器而且不要使用xwindows,估 计这个管理员连打开光驱都办不到!这可能也是unix比windows稳定的一个原因. 俺们现在的项目都是基于ms的技术,有很多是在com+上面完成的,j2ee也看过一些, com+和j2ee中很多内容都是类似的,不过感觉如果转向j2ee开发成本太高,而且对于 俺们作的这些"小项目"体现不出什么优势. "Java之战SUN再次挫败微软,Sun的圣诞礼物：微软需在Windows嵌入Java"---看到 这样的消息俺对Sun有种说不出的感觉,如果非要说出来的话,两个字:"恶心"!虽然 作为商业竞争各种下流的作法都可能出现,比如ms挖人墙角等等,但是Sun的如此作 法简直与街头的地痞无赖没有分别了.竞争归竞争,在推动技术的进步方面俺认为 Sun远远不及ms! 一些胡言乱语,见笑了. fortune999@eyou.com WANGYISE/(2003-1-4 20:52:22)/ 很精采 我同你一样是非科班毕业 现正在进阶中（学习C++和计算机专业知识）努 力中.......! qwedcxza/(2003-1-4 18:22:01)/ 算得上一篇有用的文章 开发应用领域,这个领域本身就很广,若简单分为企业应用和民用,问题就立刻显露 了,JAVA 等物的关键问题就是只考虑技术,忽略了产品,首先一个产品可不可能完全 只用解释型语言就开发出来,然后,这样的产品,能出品作为民用吗?这其中的缘由恐 怕只有真正做产品的人才能了解. 其次, COM 正是为适应产品需要而产生的( 并不赞同 COM 是很复杂的,其复杂性恐 怕多是由于资料缺少,再加上某些低质量的教材造成的,只要能说清楚一切,没有什 么事情真正算得上复杂), COM 的主要目的虽然只是为了重用,但带来的利益可不只 是重用. xuanyun/(2003-1-4 17:05:26)/ 写得很不错，内容不论，光是平和谦虚的文风就是好久没见到的了。 bbao/(2003-1-4 16:08:35)/ 能把文章写得这样长而有条理不是那么容易的。 作者能不能给“企业应用开发领域”下一个准确的定义呢。总是有人用这个词，我却 懵懵懂懂的。 bbao/(2003-1-4 15:34:43)/ 能把文章写得这样长而有条理不是那么容易的。 作者能不能给“企业应用开发领域”下一个准确的定义呢。总是有人用这个词，我却 懵懵懂懂的。 bbao/(2003-1-4 15:33:52)/ 能把文章写得这样长而有条理不是那么容易的。 作者能不能给“企业应用开发领域”下一个准确的定义呢。总是有人用这个词，我却 懵懵懂懂的。 bbao/(2003-1-4 15:25:39)/ 能把文章写得这样长而有条理不是那么容易的。 作者能不能给“企业应用开发领域”下一个准确的定义呢。总是有人用这个词，我却 懵懵懂懂的。 bbao/(2003-1-4 15:23:57)/ 能把文章写得这样长而有条理不是那么容易的。 作者能不能给“企业应用开发领域”下一个准确的定义呢。总是有人用这个词，我却 懵懵懂懂的。 MarsSoft/(2003-1-4 14:42:59)/ 你不是刚毕业不久就是工作时间长了，人秀逗了。尽说些胡话。 classfactory/(2003-1-4 14:02:02)/ 呵呵，迄今为止还没有人敢说精通上面提到的所有技术，所以多数人的评论都只是 从某些角度出发得到的。Anyway，算是不错的文章，对newbie算是大补了。 发表评论 *你还没有登录：*昵称:　密码:　*免费注册* 评论： ------------------------------------------------------------------------ 网站简介 - 广告服务 - 网站地图 - 帮助信息 - 联系方式 百联美达美公司 版权所有 京ICP证020026号 Copyright © CSDN.net, Inc. All rights reserved