.NET语言的选择

.NET语言的选择

导 读：每个组织迁移到.NET将选择采用哪种.NET语言。微软提供了四种语言：C#, VB.NET, 可管理的C++和 JScript。本文简要的讨论了我们关于这些语言和哪种语言将被使用的看法。
原文出处：http://www.dotnetdan.com/articles/misc/LanguageChoice.htm

　　每个组织迁移到.NET将选择采用哪种.NET语言。微软提供了四种语言：C#, VB.NET, 可管理的C++和 JScript。本文简要的讨论了我们关于这些语言和哪种语言将被使用的看法。

　　简而言之，我们相信C#将占据主要的市场份额；JScript是没有竞争力的；C++将被忽视，VB.NET显现出对市场的准备不足。

　　失败者

　　JScript

　　我们希望JScript在很少用户的基础上结束它的使命。现在很少有关于这方面的资料而且在.NET论坛中也不大有关于JScript的内容。它已经不是主流了。不要在把钱投到这项技术上，放弃它才是最明智的。

　　可管理的C++

　　C++，即使它新的可管理的形式也将渐渐的被忽视。当越来越多的开发者趋向于语法清晰的语言，例如JScript, Java, VB.NET和C#, 使用C++ 的圈子越来越小。另一个C++ 面临的问题是他不能作为一种教学语言。无疑，尽管如此，有经验的C++开发者将继续使用它的能力，模板，多重代码的继承性和决定性的最终确定。其余的人都能轻松的应付。

　　胜利者们

　　在这里确切的说应该是胜利者。因为我们相信C# 是唯一的真正的胜利者。VB.NET处在尚无人支持的境地。

　　C#具有相当的优势

　　大多数专业的软件开发者，即使独立开发微软平台，如今也将采用一些Java语言中的形式。

　　Java相对于C++和VB6较有利。他去处了许多C++ 中的语法特性而没有丝毫降低它的功能（因此C++的开发者转向使用Java是非常容易的）。它在支持面向对象的工具方面要优于VB6。

　　Java以其清晰的面向对象的语法结构和巨大的类库在大多数主流的具有生产性的语言中占据了最高地位。正是由于这个原因，许多擅长面向对象技术的C++ 和 VB 开发者开始向Java转移。

　　C# 为那些原本不支持微软的人转向使用微软的开发工具提供了依据。实际上它和Java是一致的，只不过在它们的不同之处，C# 更显示出了它无可厚非的优越性。此外，它是一种ECMA标准的语言，因此它提供了跨越多平台的潜在能力。

　　严肃的讲，开发者想要微软的最有生产能力和主流的.NET语言，C# 是最明智的选择。

　　VB.NET孤立无助

　　还剩下VB.NET。我们仍旧对微软为什么仅仅使VB.NET成为一个更复杂的C# 而提出疑问。也许这两门语言的历史背景是知道这个转变的关键，但是我们要讨论的是技术方面的问题而不是市场的问题。

　　无疑，VB.NET已经成长到一个新的阶段。它现在已经成为了面向对象俱乐部中快速成长的一员。但是现在谁关心它呢？也许是一群对其不满的人和非面向对象的程序员，但他们将立刻得到它。随着C#的产生，VB.NET看上去更象是个过时的产品，而不是改进。

　　DecHand代码生成器能在VB.NET或C#中生成代码。如果你选择VB.NET选项，你会得到一个文件，它和C#实现同样功能，但却要比C#生成的文件大33% 左右。读某人用VB.NET编写的的代码时，冗长的语句会带来很多麻烦。当我们把这和前面所提到的原因结合起来时，我们只能希望有经验的面向对象的开发者应该喜欢C# 胜过VB.NET。

　　那么什么样的市场会丢掉VB.NET呢? 目前的市场却使软件公司仅使用VB来作为开发工具,并造就了一大批VB爱好者.不幸的是,说实在话VB.NET并不是为这些人所开发的。

　　从VB6移植

　　只用VB编写程序的工作间可能正期望从VB6更新到VB.NET，而且能象现有的VB升级一样容易。不幸的是，他们可能会遭到严酷的打击。尽管已经有一种工具可以自动完成操作过程，但升级到VB.NET仍然会累人的多。

　　正如我们上面提到的，VB.NET是一种面向对象的语言，而VB6不是。问题在于，如果你不按照面向对象的方式思考，而许多机构也正是这样做的，你就无法体会到VB.NET转换经历的乐趣。因为这不仅仅是一个结构，而是一种范例的转变，而这种转变是很昂贵的。很多组织可能会觉得如果他们想改变思维方式，他们不如改变语言。如果VB.NET被很快淘汰掉，也没什么可惊讶的。

　　过去曾经辉煌而如今孤寂的爱好者

　　最终的市场分割造就了爱好者。对他们而言，VB6是一种可选择的语言。它提供了简单而功能强大的工具来构建简单的应用程序包括GUIs。

　　VB.NET不是这么简单的。正像我们前面说过的那样，它是一种功能强大的面向对象的语言。但对于一般的爱好者来说，他们不想也不需要了解‘-isms’和面向对象领域中的抽象事务。他们只想把一项任务尽快完成，而忽略我们某些专业人士所要求的精细之处。

　　为此，过不了不久这些VB爱好者可能不会再继续使用VB6，或者他们对其不再报有太大的希望了。

　　VB.NET的未来

　　上述注解仅仅是公开发布的.NET BETA版信息的一小部分。当我们看到最终的.NET的产品距离现在还有相当一段长时间，微软会采用它们当中的一些去生产隐藏着VB.NET复杂性的 Visual Studio.NET特性的产品。我们只能翘首以待。我们对此不能做什么，只能相信他们能作到，为了发展，让我们给微软以传统的爱护，这样他们就会更加努力的去做。

　　关于运行时间的执行

　　如果你看到这里与你所想的相差甚远，你可能会问“性能怎样？”，当你在决定用哪一种语言来更快的完成一项产品时，这是每一个人所自然而然所要问的。

　 毫无疑问.NET完全排除了那些标准。

　　为了去理解为什么.NET 语言运行会一样快（或慢），我们需要去看一下编译程序，或正好是两个阶段的编译程序。

　　第一阶段发生在你用Visual Studio按Ctrl-Shift-B键时。在这一点上，执行一个编译，你的语言编译器正在创建中间语言（IL）。第二阶段发生在你运行了应用程序时。第二阶段有时被看作是JIT编译（我们会觉得奇怪，但是我们不能解释）。它为特别使用CPU而使用了IL和产生本土代码。

　　微软对第一阶段编译的IL而产生的代码并不乐观。相反，他们开始扩展他们所有的能力去优选第二阶段IL---本土代码编译。他们这样做是为了使语言的不可知的原因。所有的.NET语言在运行时间的执行上是一样的。

　　关于调试和编译者的支持

　　Visual Studio.NET提供了同样复杂的调试和编译者使用所有语言的工具。当在Managed C++译码时你不会看到更细节的东西，例如，与其他的语言相比。你可以达到你所希望达到的深度。同样，自动完成的方法也适用于其他语言。

　　总结

　　如果你想找到更安全的办法，那就使用C#。我们肯定现在VB.NET的功能如此强大，而且C#更是如此，选择它你不会后悔的，因为我们已经向你清晰地描述了它的生产性能。