分享
 
 
 

对主流技术的分析和总结

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

BBS 水木清华站 - 软件开发 - CPlusPlus版(进版画面 | 添加到收藏夹 )

CPlusPlus(C++程序设计语言) 版

版主 poplay1 Cray ilovecpp

在线 8 人 文摘区 | 精华区 | 版内查询

令狐冲精华区搜索引擎 搜索范围 全站 CPlusPlus版

精华区文章阅读

发信人: flypen (找工作:(), 信区: CPlusPlus

标 题: 对主流技术的分析和总结(转载)

发信站: BBS 水木清华站 (Wed Mar 19 16:29:09 2003)

对主流技术的分析和总结 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推出,开发工具中第一次出现了成熟的、被广泛应用的Au

to Code Completion技术;Java推出;ASP技术开始盛行,Windows DNA技术被理解和接受;

标准C++诞生;Visual C++6.0 推出;J2EE规范推出。

成为一个程序员对我而言并不顺利,因为我不是科班出身。我入门的程序语言是FoxBASE

,这让我一直对FoxBASE有种特殊的感情,我也正是通过Visual FoxPro3.0转写Windows程

序的,如果没有它,我也许就不会成为一个程序员了。后来,在大学期间接触到了InterD

EV,那是个写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 和del

ete就可以了吗?有没有考虑一个对象存放在容器中的情况?)……诸如此类,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还提供了丰富

的类库帮助你解决应用问题——因为它是面向应用的语言,它为你提供了多线程标准、JD

BC标准、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》把这些智

慧摆在了我们的面前。但是这件东西用起来估计不会有人觉得很舒服,如果你一直在用Ja

va、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虽然是几乎所有的企业应用程序开发人员都知道的一个名词,但我相信Win

dows 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,可见它的意义,但CO

M为了照顾那些低级的语言居然抛弃了这个特征——产生的结果就是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++本身的错,而是静态编译的错),当Ja

va出现的时候,很多问题已经不存在了。你不需要一个头文件,因为Java的字节码是自解

释的,它说明了自己是什么样子的,可以做什么事情,不像C++那样需要一个头文件来解释

这些事情;也不需要事先了解对象的内存结构,因为内存是在运行的时候才分配的。

如果我们现在再回过头来解决COM要解决的问题,你会怎么做呢?首先你会不再选择C++这

种语言来实现代码的“二进制”重用,其次,你会把所有的语言编译成同样的“二进制”

代码(实际上,应当说是字节码),这显然是更聪明的做法,从前COM试图在源代码的级

别抹平二进制层次的差异,这实际上是让人在做本来应当由机器做的事情,很愚蠢是吗?

但他们一直做了那么多年,而且把这个痛苦带给了整个计算机世界——因为他们掌握着事

实的标准,为了用户,为了利润,为了能够在Windows上运行,尽管你知道你在做着一个很

不聪明的事情,但你还是做了。

COM技术为了照顾VB这个小兄弟和实现统一二进制世界的野心,实在浪费了太多的精力。首

先,落后的东西的消亡是必然的,就象C、Pascal在应用领域的消亡一样,Basic一点一点

的改良运动是不符合历史潮流的做法,先进的东西和落后的东西在一起,要么先进的东西

被落后的东西拖住后腿,要么是同化落后的东西,显然我们更愿意看见后者,现在Basic终

于被现代的计算机语言同化了。其次,统一二进制世界好像不是那么简单的事情,而且也

没什么必要,微软的COM技术奋战了10年,现在也只有他自己和Borland支持,.Net终于放

弃了这个野心。这一切终于要结束了。过去J2EE高歌猛进地占领着应用开发的领地,COM在

这种进攻面前多少显得苍白无力。现在微软终于也有了可以和J2EE一较长短的.NET,对于

开发人员来讲,基于字节码的组件的二进制重用现在是天经地义的事情;你不用再为了能

够以类方式发布组件做那么多乱七八糟的事情,因为现在所有的东西本来就是类了;实现

软件开发的分工也很自然,你是专业人员,就用C#吧,你是应用开发人员,你喜欢用VB.N

et,你就用吧,反正你们写的东西最终都被翻译成了一样的语言(其实我觉得这一点意义

不大,因为一些不那么好用的语言被淘汰是正常的事情,C风格成为程序设计语言的主流风

格,肯定是有它的原因的,语言的统一其实是大势所趋,就象中国人民都要说普通话一样,所?br /> 晕揖醯肑ava不支持多语言算不上缺点——本来就是一种很好看很好用的语言了,为什么要

把简单问题复杂化呢?)。

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 weave

r)这一类的东西。而且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的应用程序不是很顺利地就可以移植到Webspher

e上的,反过来也一样。但.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战略》

--

************

如果生活的曲线是这样: ──────────── 。

※ 来源:·BBS 水木清华站 smth.org·[FROM: 61.149.1.192]

[返回顶部] [刷新] [同主题模式] [普通模式] [版内查询]

来这个版的人常去的其他版面: [VisualC][Programming][NetResources][Java][NewSoftware][LinuxApp][Love]

[返回首页] [上级目录] [根目录] [令狐冲精华区搜索] [返回顶部] [刷新] [返回]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有