.NET断想
2020-02-03 15:55:43
供稿：网友
.net断想
荣耀 2002秋
“遗留软件”和“遗留程序员”是阻碍.net普及的最大阻力。另外一个阻力（听起来有点庸俗:)）是目前的windows操作系统没有预装.net框架。运行.net应用，你需要另外安装.net框架，这多少都有点麻烦。com为何会在极短的时间内迅速取得成功，windows内建了com基础设施不能不说是原因之一。
微软当然比谁都清楚这一点，所以，“windows .net”系列操作系统，必然指日可待。
假如你对此观点不以为然，不妨看看corba在windows平台上命运。当然了，这只是原因之一，而且，我说过，这个原因有点俗:)
不过在此也要纠正一个谬误。不在少数的程序员以为，在访问以asp.net技术创建的web网页（.aspx）的客户端机器上，也必须安装.net框架，这个概念是错误的。道理其实很简单 — 服务端总是返回生成的html。
无论微软如何宣称，无论.net如何支持多种语言，都不会影响“c#是.net最佳语言拍档”。
但在相当长的一段时间内，visual basic .net或许反而会比c#占有更多的用户。原因并不复杂 — 现有的visual basic程序员为数众多 — 尽管今天的visual basic .net早已不是从前的visual basic了。
visual basic程序员过渡到visual basic .net，可能要比c++或java程序员过渡到c#困难得多。
.net框架由通用语言运行时（common language runtime，clr）和.net框架类库构成。.net在操作系统之上又加了一层抽象，.net本身并不是操作系统。
为什么有那么多的人憎恶微软？这很让人费解。无论哪家公司，倘能取得微软这样的成就，都是了不起的。无论谁坐到了微软的位置上，估计都会这样。
憎恶微软的人，要么是微软的竞争对手，要么是非微软阵营的狭隘的开发人员，要么啥也不是，纯粹人云亦云，瞎起哄。
无论你多么憎恶微软，无论你怎样不喜欢.net，假如你是一名“面向微软”的开发人员，学习掌握.net只是早晚的事。
假如你是一名windows开发人员，纵然你从来都不打算使用.net技术进行实际软件开发工作，想对.net完全免疫也是不可能的，你至少得知道它究竟是怎么一回事儿。
今后若干年内，.net和java将会形成分庭抗礼之势。两大阵营各有支持力量，只有在竞争中彼此学习互补，才能共同前进。任何一方都很难一口吃掉对方。
在软件开发世界，单极世界难免霸道，绝对不会长久；两极世界的平衡很难长时间维持，容易被打破；多极世界是丰富多彩了，但无疑将会成为开发人员的灾难，因为异质技术的整合，从来都是一场噩梦。
java已经占据了大片地盘，在微软支持下，.net将会最大限度地把pre.net开发人员拉向自己的怀抱。在这个过程中，或许有人逃到java阵营，但人数不会太多。道理很简单，假如你是一名微软技术开发人员，学习.net所要花费的功夫，无论如何都不应该超过学习java所要花费的功夫。
在从微软pre.net技术过渡到.net过程中，肯定会淘汰掉一些无法与时俱进的开发人员，这是正常现象。在技术进步的过程中，每一次创新，抱残守缺者总是会被毫不留情地抛弃。
自然选择，物竞天择。
有多少人会使用managed c++？数目应该不会太乐观。相当一部分c++程序员往往会有某种没来由的优越感，对任何非c++的东西不屑一顾，大有万般皆下品，唯有c++高的感觉。在这些c++程序员的眼里，managed c++已经算不上c++了，或者说，充其量，managed extensions for c++不过是微软对c++打的一个.net补丁而已。
每一个严格符合.net框架的语言的程序，最终都将被转换为msil代码（当然啦，有些语言只是提供了同clr-based代码交互的能力，并不真的生成msil），但这并不意味着使用不同的.net语言编写的功能相同的代码，将会转换成同样的msil代码。编译器的质量会有差别，生成的msil代码的质量也肯定会存在差异。
非微软的.net语言据说已有两打之多，但它们很难成为主流。某些第三方.net语言的现实意义，不过是提供了一种将现有代码移植到.net之上的途径而已，另外一些仅仅具有学术研究方面的价值。
我不知道究竟会有多少人在.net上使用perl或者python，尽管今天它们的拥趸的确不在少数。我只能肯定delphi（object pascal）应该是个例外。
能否成为主流.net语言，主要取决于：是否有足够多的“遗留软件”，是否有足够多的“遗留程序员”，是否有足够好的ide，是否有实力足够雄厚的组织提供强力支持。
向来只有微软自己的技术才能和微软的技术最佳匹配，com就是一个例子。com无疑是pre.net时代最成功的跨语言机制，但这种技术在跨微软自己的语言（确切地说，是开发环境），比如从visual c++跨到visual basic以及相反时，表现还好，跨到了别的语言（开发环境），比如说delphi，就会暴露出这样或那样的问题。
但愿类似的情况不会发生在.net身上，但愿遵循cls的语言果真可以完美无缝地互操作，就象微软自家生养的.net语言一样:)
web services技术并非微软独创，也不是由.net带来的，但仍然有相当一部分人误以为它是伴随微软.net而来的技术。微软推广技术（概念）的功夫，由此可见一斑。
别误会，.net compact和.net框架可以说是很不一样的东西。.net compact并不是从.net框架中简单地砍掉一些东西之后的精简版，否则.net compact也不会比.net框架晚交货那么长时间。
asp.net应用程序，就是.net应用程序。普通asp开发人员过渡到asp.net的痛苦，比起从visual basic过渡到visual basic .net所要承受的痛苦（快乐？），不会少到哪里去。
ado.net是一种革命性的技术，尽管无可否认，它从borland借鉴了许多数据存取技术，但ado.net对xml技术的支持，目前无疑处于领先地位。
我希望速度不要成为web services被广泛应用的阻力。在荣耀编写的一个测试应用中，整合来自不同厂商的web services的应用效果是令人惊讶的，不过，这个应用速度之慢，同样出人意料。
或许基于web（wan）的分布式计算，迫使我们不得不作出速度上的妥协，就象我们可以容忍（并且已经习惯）浏览器应用比传统windows gui应用来得慢一样。
.net框架应用或许会比那些windows dna应用运行得慢，不过，我们真正应该关心的问题并非是这些应用到底能运行多快，而是它们是否足够快，快到可以满足用户业务处理的要求。
java的成功已经提供了这些证据。尽管java代码一般来说要比本地代码来得慢，但它还是足够快了，许多组织都非常成功地使用了这种技术。因此，对于.net速度上的担心，完全是多余。按照微软自己的说法以及第三方提供的一些测试数据，.net至少比目前版本的java来的更有效率。
毕竟，硬件的品质也在不断提升。
