|
百万程序员的苦恼－选择VB.NET还是C#(2) 如果你抓住这些你应该Mid 或者 CInt功能不放，而最终认为这就是VB.NET强于C#的证据，你最好去看看Microsoft.VisualBasic namespace。你将在那里发现大部分VB.NET内部命令和应用功能。这些功能在namespace中被保存之后，任何CLS兼容的语言都能使用他们，就像列表A中所显示的那样。这些例子削弱了我们的争论，不是吗？
更好捆绑的支持就是不支持
“VB.NET与COM实体的捆绑支持更好一些。”我也只是看到了一点点而已，并且我决定再也不在支持方面作任何推理。从我迄今为止所观察到的，这不是真的。C#和VB.NET必须采用runtime callable的包装以及等量的源代码来执行一个早期的实体。同样地，执行一个晚期的实体也需要相同数量的代码。
VB.NET使用IDE中的后台编译
如果你不能找到其他的认为VB的开发环境好的例子，你至少不得不承认它的源代码编辑是很有特点的。你能一边打字一边字面上排除你的代码的错误。麻烦就是那些很弱智的编译错误信息框总是弹出来，并且如果你把你的喇叭声音开得过大的话，报错的嘀嘀声也许会吓到你。
Visual Studio.NET避免了这种惊吓，直到你修改完成，并且处理了一些消极的错误，提示系统经过了微软的改进：他会在那些错误语句的下面打上弯弯曲曲的下划线。
VB.NET背景编译程序/句法检验器非常复杂，而且很客气地指出你的错误。从某些方面看，它能更准确地告诉你如何修改你源代码中的错误。当C#有它自己的语法检查器，并且可以查出括弧的匹配，计算圆括弧的多少，显示丢失的分号，但是它还是不能像VB.NET那样使用简单。再继续讨论这两种语言的优越性确实会让我心烦的，不过微软的话确实是一个真理，那就是所有的.NET语言都是平等建立的。那些主张C#优于VB.NET的人（反之亦然）和那些攀比工资的开发者们一样错了。
我要强调的是，那些有远见的技术公司不再会去寻找具有某种开发语言经验的程序员，而是去寻找那些有.NET类库开发经验的程序员。因此我劝你不要过分的担心自己的选择到底是什么：随便找一个你觉得有兴趣学的语言，认真地学好他的框架结构就行了。
如果你最终认为我是错的，并且市场也不要求你一定要选择一种语言，那你就尽管嘲笑我吧。
|
