VB 诽谤铁证！

引言

本文旨在反驳最近在 CP 上发表的一篇文章中提出的谬论。虽然没有明确说明，但毫无疑问，该文提出了一个隐含的论点，即 C# 是更优越的编程语言，其论据的前提是使用 VB 语言会导致软件系统质量低劣。而这个前提的前提又是，VB 语言的 RAD（快速应用开发）起源及其对除主流软件学术界支持的编程范式之外的各种编程范式的支持，“损害”了使用该语言的程序员的思维，从而使他们生产的软件质量低于其 C# 同行。简单来说，作者认为，使用 VB 语言本身会降低程序员实现优雅软件解决方案（即严格类型化和面向对象的解决方案）的能力，因为该语言为开发者提供了过多的“选项”。

当然，这个论点从头到尾都是完全错误的，甚至其前提也是谬误，并且没有考虑到软件开发中最重要的方面：商业！此外，尽管这篇文章写得辞藻华丽，乍一看似乎可信，但毫无疑问，它充满了谬误、矛盾，以及最糟糕的——谎言。这是一个典型的非正式说服性论证的例子，它更多地依赖于修辞而非事实来陈述和辩护一个观点。最终，这篇文章是 Visual Basic 诽谤的最佳（如果不是最好的话）范例之一。

本文不试图争论哪种语言更优越，因为任何“严肃”的尝试无疑都是徒劳的。相反，本文的意图是否定那篇文章用来支持其结论的各种前提。

VB 文化——关乎商业，而非计算机科学

该文章如此描述 VB 文化：

“Visual Basic 的文化是 90 年代的文化：快速构建，大肆宣传，卖出去，不用担心明天故事是否还站得住脚，甚至根本不用担心它是否站得住脚。”

的确，毫无疑问，Visual Basic 的文化首先是关于商业，而不是计算机科学。它是关于在预算内按时把工作做好。应用程序的另一端，即最终用户，从来不关心他们每天使用的软件的内部工作原理。最终用户不会根据系统的设计方式或实现语言来评判系统。最终用户从不欣赏一个优雅软件系统背后所有的辛勤工作，他们唯一关心的是软件能以友好的方式完成手头的任务。这正是 VB 程序员多年来取得成功和主导地位的地方，他们中的许多人也因此获得了丰厚的回报，当然这是理所当然的。当 C++ 程序员向老板展示 UML 图时，VB 程序员向老板展示的是带有各种花哨功能的工作原型。当财务副总裁询问系统设计和实现需要多长时间时，C++ 程序员估计至少需要一年时间。当问到 VB 程序员同样的问题时，他们回答说最多一个月。当许多 C++ 程序员成为过度架构的受害者，导致要么延迟交付要么从未交付时，许多 VB 程序员却能按时或提前交付。可以肯定地说，从纯粹的软件工程角度来看，用 Visual Basic 开发的普通产品，其质量不如用 C++、Delphi 或 Java 开发的同样产品。然而，毫无疑问也可以得出结论，用 Visual Basic 开发的普通产品是按时交付的，而用 C++、Delphi 或 Java 编写的同等商业应用程序则肯定不是！在商业世界里，幕后发生什么并不重要，VB 程序员多年来已经认识到这一事实并采取了行动，由于对公司利润产生了积极影响，他们得到了丰厚的回报，这当然是理所应当的！典型的 VB 程序员知道商业驱动技术，而典型的计算机科学家知道，或者至少愿意相信，技术驱动商业。一个软件解决方案是否使用最优雅、最受推崇的软件开发实践来设计和实现，这与任何企业的利润最大化目标完全无关，就像使用最差实践来设计和实现解决方案一样。事实是，软件系统的“如何实现”从商业角度来看是完全无关紧要的，当然从最终用户的角度来看也是如此。当然，一个非常有效的反驳论点总是说，开发不良的软件从长远来看可能会增加产品的长期维护成本，这无疑会对利润产生负面影响。的确如此，然而，一个企业的长期成功往往取决于其短期采取的行动。此外，当开发不良的软件真正成为阻碍企业实现其利润最大化目标的问题时，程序员从来不会被问到：“修复它困难吗？”而是总是被告知：“去做！”

那么必须问一个问题，软件的价值是什么？首先，软件是一种最终产品，与其他任何消费品，比如汽车，没有区别。汽车本身没有价值；它的价值是由产品的需求曲线决定的，即消费者对它的估值。例如，一辆宝马是德国汽车工程的杰作；然而，如果客户不愿意购买这辆车，也就是说，如果这辆车的需求曲线在价格和数量为零时完全无弹性，那么所有精良的工程最终都变成了有成本无收益，也就是亏损。同样的基本价格理论经济学原理也适用于软件。软件没有内在价值；它的价值是最终用户使用软件所获得利益的函数。不是软件的设计、使用的语言或程序员的技能水平使软件有价值。软件消费者，即最终用户，才是最终决定一个软件是有价值还是毫无价值的人。如果它能以用户友好的方式按时完成工作，那么它就是有价值的；否则，就不是，尽管它的设计和实现可能最为优雅。总有商业阶梯上更高层的人，最终用户向他们报告业务活动，而这些活动正是由于商业软件解决方案的奇迹而大大便利。员工只关心完成他们的工作，并让上级知道他们各自的业务活动已经成功完成。最终用户从来不会打电话给帮助台抱怨说应用程序 X 不工作，因为它不是以严格类型化的面向对象方式实现的。相反，最终用户总是因为任何其他原因打电话给帮助台，从软件中的实际错误到纯粹的无知。最终用户无知的一个典型例子是，技术支持电话另一端的用户说：“程序不工作！我无法输入任何数字”。嗯，也许是 Num Lock 键的问题？的确，用户总是试图将他们在使用软件时遇到的任何问题归咎于软件，大多数时候这些问题与软件本身无关，而是不当使用或错误数据导致的结果，但肯定不是软件内部设计或实现的结果。根据我个人的经验，我从未接过一个客户支持电话，不幸的是我接过很多，其中用户说：“程序使用了全局变量，因此我无法使用它！”如果真是这样就好了，这样我们就可以根据客户反馈向管理层提出论证，禁止这种糟糕的编程实践。然而，在现实世界中，也就是在商业世界中，客户会抱怨任何其他事情，但绝不会抱怨软件的内部机制。

该文章在定义 VB 文化时提出的另一个关于 VB 的误解如下：

“在 Visual Basic 之前，应用程序开发语言被认为是复杂的，并且仅限于熟练程序员的领域。Visual Basic 语法简单，它使几乎任何有几个小时时间的人都能学会如何创建简单的应用程序。” 

虽然这完全是真的，但它完全没有区分旧的 BASIC 编程语言和承载该语言的开发环境，而是反复使用“语法”一词来指代整个 VB。首先，语法只是支配编程语言文法的一套规则。说 VB 的语法使 VB 成为一门糟糕的语言，就等于说编译器用来解释构成 VB 语法的系列标记的逻辑是糟糕的。在大多数情况下，用“语法”一词来指代一种语言的特性集或扩展是可以原谅的，无论说这话的人是否具有正式的编程背景。然而，由于作者正在进行攻击，并像样地尝试列举 VB 的弊端，并且作者将自己归类为“计算机科学家”，因此必须指出“语法”一词的有时错误的用法。第二，也是更重要的一点，语言，即 BASIC，只是故事的一半，另一半是开发环境的“可视化”外观方面，这是使 VB 开发如此难以置信地容易的主要贡献因素，谢天谢地！的确，BASIC 编程语言是计算史上最简单、最直观的编程语言，它使用与表达本文相同的标记来表达软件系统。然而，说 BASIC 本身使开发基于 Windows 的系统变得容易是完全错误的，任何一个略懂 VB 和 C++ 的普通程序员都知道这一点。毫无疑问，在没有可视化外观，即窗体设计器的帮助下，用 VB 构建任何类型的基于 Windows 的应用程序比用 C++ 要困难得多！显而易见的原因是，在 C++ 中，对于每个需要的库，一行代码就能让程序员包含该库公开的所有函数，然后可以直接调用，而在 VB 中，你必须在使用之前为每个库声明每一个函数，更不用说通过 VB 调用 Win API 时涉及的所有其他繁琐细节了，这个过程几乎与当前的 PInvoke 过程相同，但更困难。此外，鉴于 .NET FCL 提供的所有功能，与 Win API 打交道的需要已经呈指数级下降。

该文章对 VB 文化的总结严重未能考虑到 RAD 的商业重要性，而是将 RAD 斥为使 VB 成为一门糟糕语言的因素之一。然而，毫无疑问，正是 Visual Basic 开发环境提供的 RAD 外观使这个工具对企业来说具有难以置信的价值。重申一遍，软件系统本身并无价值，也就是说，它们的底层设计和实现并不是决定其净值的因素。客户，也只有客户，才是为任何软件产品贴上最终价格标签的人。确实，作者缺乏许多计算机科学家所缺乏的东西：健全的商业判断力！在作者看来，一个软件产品的价值是其设计和实现的函数，而事实上，这个函数只表达了存在于专业程序员脑海中的现实，这种现实在典型的商业环境中是找不到的。毕竟，追求设计和实现最优雅的软件系统，即完美的软件系统，是作为系统程序员的我们的天性。然而不幸的是，公司的利润不能总是等待这种完美的实现。商业应始终优先于计算机科学，也就是说，计算机科学绝不应优先于商业。再次强调，一个企业的长期成功往往取决于其短期采取的行动，并且，绝不应该为了架构而牺牲交付。

矛盾的比较点：C#

使该文章的论点如此矛盾的是，它使用 C# 编程语言作为比较点，即作为区分好程序员和坏程序员的决定性因素，好像 C# 语言和开发环境以某种方式强制学习各种编程主题，如作者引用的内存管理和线程，而事实上它们恰恰相反。

首先，文章对 VB RAD 环境的批评是矛盾的，即它如何诱使程序员偏离软件开发的理想原则，但同时对 C# RAD 环境却只字未提，而 C# RAD 环境在模仿 VB 的 RAD 外观方面做得很好，并且随着后续版本的发布越来越好。任何一个在 VS.NET 2005 开发环境中玩过 C# 2.0 的人都会欣赏那些从 VB 复制过来的生产力特性。编辑并继续（EC）就是一个典型的例子。这个特性难道不违背软件开发的健全原则吗？具体来说，它难道不会导致一些可能不会立即被注意到的副作用，但可能在稍后的某个单元测试中导致逻辑错误吗？EC 是不是文章所描述的那些对优雅系统开发有害的 VB RAD 特性之一？确实是；然而，谁在乎呢！获得的生产力无疑超过了所产生的任何成本。程序出错，VS 在错误发生点中断，程序员当场修复错误，程序继续运行，VB 生产力的故事就这样继续下去。然而，如果按作者的论点来看，那么这些出现在 C# 开发环境中的特性，即“可视化”特性，也必将对 C# 程序员的思维产生负面影响。这里所暗示的滑坡谬误是显而易见且极其荒谬的！的确，C# 只是故事的一半，另一半是从 VB 复制过来的“可视化”方面；毕竟，它是 Visual C#，而不仅仅是 C#。再次，文章的商业判断力非常值得怀疑，至少可以说是这样，鉴于其对 RAD 的消极态度，作者想必是用记事本开发 .NET 系统的。这是什么情况？难道现在 2005 版的 C# 的智能感知（Intellisense）不也是像 VB 那样不区分大小写了吗，尽管 C# 是一种源自 C 的语言，因此是区分大小写的？再次，VB 的 RAD 特性正在缓慢但肯定地侵入 C# 开发环境的各个方面，其影响在所有其他开发环境中也同样明显。现在的问题是，这些特性对于高级系统开发者来说是坏消息吗？要回答这个问题，必须先问另一个问题，快速轻松地开发软件本身是件坏事吗？当然不是！为什么？因为这是关乎商业，而不是计算机科学！最终用户不会像我们专业程序员看到我们优雅的系统运行时那样感到激动。

其次，作者对 Visual Basic 命名空间的邪恶描绘是矛盾的。根据作者的说法，这个功能鼓励程序员在系统开发问题上走捷径，并且永远不应该使用，尤其是在大型项目中。这是一个矛盾的结论，因为 FCL（框架类库）又如何使解决问题的过程变得更困难呢？当然不会！FCL 是一个优美的面向对象的外观，它位于 Win API 之上，使程序员不必了解 Windows 操作系统的内部工作原理。例如，FCL 如何使编写多线程应用程序成为一个学习 Windows 操作系统如何处理线程的过程？嗯，它不会！相反，它使这个过程看起来几乎微不足道。世界上没有一个 C# 程序员需要对 Windows 的内部工作有任何程度的熟练度才能让一个程序运行起来，这确实遵循了 Visual Basic 的真正精神。PInvoke 是为那些非常罕见的情况准备的，即需要调用 Win API 来执行 FCL 没有提供类型的任务。这当然与 .NET 之前的开发模型形成鲜明对比，在那个模型中，任何类型的高级 Windows 功能都需要几十个 Win API 调用，这是一个像我这样的普通 VB 程序员非常熟悉的故事。作者关于开发外观是邪恶的，并且会导致劣质软件产品的论点，与他认为 C# 是更优越语言的观点完全矛盾。毕竟，CLR、CTS 和 FCL，也就是 .NET 本身就是一个开发外观。此外，没有 .NET 的 C# 什么都不是，就像没有 COM 的 VB6 什么都不是，没有 .NET 的 VB.NET 什么都不是。再次，文章的商业判断力完全是可耻的，更准确地说是根本不存在。按照作者的话来说，这意味着 C# 程序员永远不应该使用 lock 语句，因为 lock 语句是将代码块标记为临界区的简单方法。简直荒谬！VB 已经有近 20 年的历史了，这段历史的大部分（如果不是全部的话）都存在于 Visual Basic 命名空间中。要求一个 VB 程序员忽略 Visual Basic 命名空间，就像要求一个水管工忽略他过去 20 年来用来完成工作的得心应手的工具集一样。工具就是工具，有正确的使用方法，也有错误的使用方法，与 .NET 提供的工具没有什么不同。天哪，根据作者的说法，即使是像 .NET 和 COM 这样的垃圾回收环境也会让程序员变笨，但具有讽刺意味的是，C# 和 VB 一样，是一种内存托管语言，也就是说，它不需要担心堆分配和清理。即使在 COM 时代的 VB 程序员也必须担心内存泄漏，尽管程度远小于 C++ 程序员，因为 COM 用于实现垃圾回收的引用计数系统在涉及来自不同 COM 服务器的对象之间的循环引用时会失败，而 C# 程序员由于 GC 的工作方式永远不会面临这个问题，谢天谢地！那么问题来了，一个 C# 程序员需要对堆分配有多少了解才能让一个程序运行起来？完全不需要，谢天谢地！这会使 C# 程序员比他们的 C++ 程序员差吗？当然不会！此外，文章不断赞美 Delphi 和 Java，将这些语言称为 C# 的祖先和 C# 优越编程文化的直接贡献者。再次，必须问一个问题，在使用这些开发环境时，对内存管理和线程等问题的关注程度有多高，以至于这些关注已经传播到 C# 文化中？Java 程序员上一次需要担心释放堆是什么时候？是不是很矛盾？这似乎与一个观点截然相反，即为什么 C++，例如，在文章定义 C# 文化时从未被提及，好像 C++ 与描绘 C# 文化优于 VB 文化（至少在编程方面）的观点完全无关。难道 C++ 不是唯一真正迫使程序员理解软件开发底层细节的语言吗？

目的：诽谤 VB

毫无疑问，该文章的目标是诽谤 VB。虽然没有明确说明，但地球上任何人在读完这篇文章后都不会对 VB 留下好印象。这是一个典型的非正式说服性论证的例子，即乍一看，鉴于其表达的语气，它看起来很有说服力，但仔细检查后却完全是谬误，然而不幸的是，不是每个人都有时间或知识来意识到这一事实。处于招聘职位或决定语言选择职位的人很容易受到作者提出的谎言和误解的影响，因为它们的呈现方式使其看起来是真实的，而正是这种对行业的恶意故意影响使这篇文章如此具有破坏性。许多合格的 VB 程序员将被那些对编程一无所知的人拒绝，通常是 IT 管理类型的人，仅仅因为他们轻信了文章的话。许多面临在 VB 或 C# 之间做出抉择的开发团队会选择 C#，当然不是因为它是一门更好的语言——这只是个人或商业偏好的问题——而是因为作者提出的谬误论点。例如，也许文章在讨论 VB 过渡到 .NET 时所宣扬的最具破坏性的谎言如下：

“由于 Visual Basic 引擎架构的底层限制而强制执行多年的缺乏继承和多态性的问题，通过完全抛弃旧引擎得到了克服。”

确实，任何读到上述谎言且对 VB 一无所知的人都会自动做出错误的假设，认为在 .NET 之前使用 VB 是不可能实现面向对象应用程序的。当然，这个说法离事实有十万八千里，因为自从 COM 时代以来，VB 就已经可以构建面向对象的应用程序了。的确，在 .NET 出现之前，VB 缺乏实现继承，但说实现继承是开发优雅面向对象系统的必要条件是绝对不正确的。自从 VB 成为一种基于 COM 的语言以来，它就一直支持接口继承，并结合包含和委托，其结果是非常优雅和灵活的面向对象的系统，这些系统真正符合 GOF（四人帮）“优先使用对象组合而非类继承”的经验法则。毫无疑问，.NET 之前的 VB 缺乏许多语言特性，但自 COM 时代以来，它从未缺乏创建高性能面向对象应用程序所必需的手段。此外，关于作者认为 VB 从未支持过多态性的信念——当然是另一个谎言——进一步加深了人们的怀疑，即作者不仅对 VB 一无所知，而且很可能对 COM 也一无所知！必须问一个问题，鉴于作者对 VB 语言提出的所有负面断言，他对 VB 有多少了解？好吧，据作者说

 

“在 90 年代的其余时间里，我使用 VB（以及其他语言），并建立了一家名为 Think Software 的公司，专门从事 VB 解决方案，并雇佣了 13 名 VB 编码员。”

 

嗯？作者声称拥有多年的 VB 经验，却做出刚才提到的那样的断言，特别是关于多态性和继承的断言？的确如此！作者写了整整一篇文章批评 VB 程序员缺乏面向对象知识，然而在与 VB 打了多年交道之后，更准确地说，在用 VB 建立了一整个企业之后，他甚至不知道 VB 自 1990 年代以来就一直支持面向对象范式。太离谱了！毫无疑问，作者属于他自己所说的 80% 的差劲 VB 程序员！虽然更有可能的是，这篇文章是故意撒谎，这一事实让人不禁思考，像作者这样的人怎么可能批评 VB 的文化，却对它一无所知。诽谤！就是这样！这种事时有发生，但这位作者更进一步，将诽谤巧妙地放在一篇写得很好的文章里，并将其发布在一个对整个软件行业高度可见的网站上。此外，仅仅是 .NET 之前 VB 完全基于 COM，就像今天 C# 完全基于 .NET 一样，这一事实就明显表明 VB 必须支持多态性！听说过臭名昭著的 IUnknown 接口的人请举手。就像今天在 .NET 中每个类型最终都派生自 Object 类型一样，昨天在 COM 时代，每个类型都派生自 IUnknown 接口，因此这些 COM 类型的实例通过此接口访问，以更新相应的引用计数。多态性的实际应用！让软件开发界和消费界知道，该文章对 VB 的看法不过是，嗯，谎言。实在没有更客气的说法了。

 

作者明确提出的另一个对 VB 的批评与 VB 支持脚本编程风格这一事实有关，在这种风格中 1) 不需要声明变量 (Option Explicit Off)，2) 不需要显式地将类型从一种形式转换为另一种形式，而是所有转换都在运行时进行 (Option Strict Off)，以及 3) 不需要知道在编译时对引用变量调用的成员是否确实是对象接口的一部分，而是在运行时确定 (Option Strict Off, Late Binding)。在作者看来，由各种形式的 Option 语句启用的各种编程范式会使程序员偏离健全的软件开发原则，因为他错误地认为软件本身就有价值。的确，VB 是一门完全关乎选项的语言：你想做什么，就怎么做！VB 听从程序员的命令，而 C# 则是程序员的指挥官。文章没有意识到这些选项对于 VB 非程序员和 VB 程序员来说是多么宝贵。为什么注册会计师琼·迈尔斯（Joan Meyers, CPA）需要担心类型转换，而她只想快速构建一个地址簿呢？嗯，她不应该担心；相反，她应该专注于把账目做好，因为毕竟她是一名会计，而不是程序员，而 VB 当然不会歧视任何一方，而是欢迎各种背景、学科和技能水平的程序员。为什么我必须为我使用的每一个 COM 库分发一个 COM 可调用包装器，仅仅为了调用一个 COM 对象的-两个方法？这需要为包装器添加一个额外的引用，外加一个需要包含在安装中的额外文件？为什么我必须在 C# 中经过额外的步骤来使用反射以实现后期绑定行为，从而避免这些分发问题？为什么？嗯，用 VB 我就不必，也永远不必，除非有压倒性的商业理由这样做。后期绑定是 VB 实现多态性的最古老的方式，即与 Smalltalk 中可用的经典多态性相媲美的多态性！毫无疑问，从纯粹而狭隘的系统角度来看，这些各种编程风格并不理想，这也是作者对软件的唯一观点，但从商业角度来看，这些特性是无价的，因为它们为程序员和非程序员提供了巨大的生产力。乔需要成为一名机械师才能更换他车辆的机油吗？乔需要有正式的计算机科学背景才能编写个人网站吗？不！这个论点是荒谬的，因为它在做出特性 X 总是坏的概括时完全没有考虑上下文。商业世界是动态的，资源总是有限的，决策需要在今天而不是明天做出，程序员并非总是可用，商务人士经常需要扮演双重角色，其中一个是程序员角色，遗留系统存在并且必须考虑在内，商业因素的清单还在继续。说软件总是需要以方式 X 开发而不考虑商业上下文，就是不理解软件在商业环境中扮演的角色，这是程序员中非常普遍的一种失败，毫无疑问，该文章的作者就是其中之一。

的确，至少可以说，所提出的论点是完全矛盾的，只是一系列无知程序员的谬论咆哮，他们相信商业世界与他们成长的计算机科学课堂形式相同。毫不奇怪，这些高素质的工程师多年来被许多自学成才的 VB 程序员所取代，他们可能没有那张挂在壁炉上方的计算机科学文凭，也没有生产出最优雅的系统，但更重要的是，他们生产了对企业来说真正重要的东西：能工作的系统，用户友好的系统，以及按时交付的系统，句号！你说设计模式？如果有足够的时间去识别它们，当然可以！否则，就忘了它吧！你说严格类型？只有当相关人员是真正的专业程序员时，在这种情况下，一个简单的项目设置就可以确保强制执行严格类型；否则，任何普通个人都不应该担心显式地将字符串转换为数字。的确，让世界放心，VB 完全关乎选项，并欢迎所有技能水平的程序员！权力归于程序员，而不仅仅是归于编译器！鉴于作者对松散类型语言的负面看法，那么 XSLT，例如，一定是一门糟糕的语言！毕竟，XSLT 也有内置的类型转换机制，所以如果这让 VB 变得糟糕，那么这也让 XSLT 变得糟糕。然而，更有可能的是，作者对 VB 持有双重标准，也就是说，只有在谈论 VB 时才是不好的；对于其他语言，就没问题了。

C# 文化——COM 和 C++ 呢？

在描述 C# 文化时，作者不断提及 Hejlsberg，提及 Java，提及 Delphi，但为什么不提及 COM 或 C++ 呢？是的，COM，微软在 90 年代承诺将实现的技术，现在又承诺 .NET 将实现同样的事情。是的，COM，C++ 程序员非常熟悉的技术。还有，为什么不提 C++？例如，泛型，.NET 的下一个大事件，是基于 C++ 的哪个特性？哪种语言实际上迫使程序员理解操作系统的内部工作原理？难以理解的是，在描述 C# 文化时，COM 甚至一次都没有被提及，尽管作者对基于组件的技术结构的所有赞美都是由于 COM 而变得流行的。是不是很矛盾？就好像过去 10 多年的 COM 开发从未存在过，因此对 .NET 和 C# 的发展没有零影响。哇！

具体的谎言

根据该文章

 

具体论点 1：“80% 的 C# 程序员是优秀的，而 80% 的 VB 程序员是不优秀的。这并不是说每个用 VB 编程的人都比每个用 C# 编程的人技能差。这是说 (a) VB 的语法和语义旨在吸引技能较低的程序员，并且结合上面探讨的其他因素，这创造了一种由技能较低的程序员组成的文化；以及 (b) 因为 VB 的语法和语义使得更难避免常见的编程错误，从而更难编写出好的程序。”

具体论点 3：“雇佣一个普通的 C# 程序员比雇佣一个普通的 VB 程序员成本更高。这是因为普通的 C# 程序员比普通的 VB 程序员更好，这是因为 (1)。”

基本上，作者得出的结论是，C# 程序员比 VB 程序员成本更高，仅仅因为前者的技能优于后者。的确，这个结论是正确的，即平均而言，VB 程序员的成本低于 C# 程序员。然而，这个结论的前提是完全错误的。再次，文章认为商业世界是由计算机科学驱动的，而事实上它是由经济学驱动的。这里起作用的是简单的价格理论经济学原理。举例说明： 

在供给方面，VB 程序员的数量远多于 C# 程序员，也就是说，VB 程序员的供给曲线比 C# 供给曲线更靠右。在其他因素不变的情况下，这导致 C# 程序员的均衡价格更高。在需求方面，C# 无疑是一款伟大的产品，自 .NET 诞生以来及之前一直被微软大肆宣传。在 .NET 1.0 beta 2 发布之前，书架上就堆满了 C# 的书籍；然而，在 .NET beta 2 之前，至少据我所知，只有一本 VB.NET 的书存在，这清楚地表明了微软当时的营销努力方向。因此，对 C# 的需求增加了，也就是说，C# 的需求曲线比 VB 的需求曲线更靠右。再次，在其他因素不变的情况下，这导致 C# 的均衡价格更高。所有这些都是产品生命周期中发生的正常商业活动。就像 VB3 在 93 年成为最流行的开发平台一样，今天所有的炒作都围绕着 C#，尽管随着更多 C# 程序员的诞生，市场力量很快就会稳定下来。作者愿意相信 C# 本身就是一个更好的产品，因此 C# 程序员的成本更高。再次强调，这不是关于计算机科学，而是完全关于商业和经济学。

具体论点 7：“在不久的将来，优秀的 VB 程序员将比 C# 程序员少。这是因为许多优秀的 VB 程序员正在转向 C#。这部分是因为他们更喜欢这种语言，但主要是因为他们更喜欢这种文化。随着文化分离变得更加明显和自我强化，它将加速，直到几乎没有优秀的 VB 程序员留下。”

人们转向 C# 首先是出于已经陈述的原因，即围绕该语言的所有炒作，并且确实因为它无疑是一款漂亮的产品，具有 1) 零向后兼容性和 2) 受益于之前语言（包括 VB）过去经验（好的和坏的）的优势。的确，作者引用的属性和事件等组件构造，以及其他如内部访问修饰符等，自 COM 时代以来就一直是 VB 的原生特性，尽管作者很可能不知道这一点，原因已经很明显了。的确，C# 采取了同样的基于组件的路线。你问 foreach？再次，这只是另一个自 COM 时代以来一直是 VB 原生部分并且被 C# 复制的语言扩展。为什么不断提及这个所谓的“C# 文化”。我问，什么文化？C# 出现才几年，所以如何能清楚地定义它的文化超出了我的理解。此外，增加其多样性的是，各种各样的人都在使用 C# 进行开发，包括许多那些“差劲”的 VB 程序员。如果你在 CP 上读过 C# 文章，之后让你怀疑这些作者当初是怎么成为 C# 程序员的，请举手。当然，导致转向 C# 的另一个更令人不安的因素是对 VB 的诽谤，就像作者在他的文章中提出的那样。

具体论点 8：“平均而言，VB 程序员对优秀的面向对象、分布式、松散耦合的应用程序设计和开发的了解少于 C# 程序员。这是因为他们的语言不支持这些概念，所以他们的文化在没有这些概念的情况下成长起来。虽然现在 VB 支持这些概念，但由于文化惯性，它们的采纳速度比 C# 文化慢。”

作者再次在此撒谎，声称在 .NET 之前 VB 不支持面向对象编程的概念。当一个论点的前提实际上是一个谎言时，该前提就会自动被否定，因此论点本身也会被否定。否定后件式（Modes Tolens）！我相信作者，鉴于其声称的“CS”背景，会理解这里的意思，因为任何一个像样的 CS 课程都包括一门符号逻辑课。此外，文章在做出所有这些断言时，没有一处提到“按比例”这个词。如前所述，VB 程序员的数量远高于 C# 程序员。此外，这些 VB 程序员中有很大一部分不是程序员！他们是商务人士、业余爱好者等等，在确定平均水平时不应该被算作程序员。的确，平均而言，VB 程序员对面向对象的了解较少，不是因为语言，而是因为 VB 程序员的数量比 C# 程序员多得多。你不能拿苹果和橘子比较！

使 VB 变得邪恶的因素

根据该文章

“VB 默认允许支持后期绑定。虽然可以用 ‘Option strict’ 关闭它，但文化是通常让它开着。这导致了许多难以捕捉的错误。C# 的绑定总是早期的。”

将这一点普遍应用于所有支持后期绑定的语言，就等于说自版本 4 以来的 Delphi 是一门糟糕的语言。是不是很矛盾？毕竟，Shaw 在他的整篇文章中都赞扬 Delphi 遵守严格的软件开发标准，尽管为什么后期绑定总是一种不好的做法，如果不考虑上下文的话，至少是值得怀疑的，但这并不奇怪，因为文章中 80% 的断言都是值得怀疑的。然而，作者很可能不会普遍应用这一原则，而是对 VB 有双重标准，只适用于 VB。此外，VB 开发环境并没有配备一把十二号口径的霰弹枪来强迫开发者关闭严格类型。这只是 VB 程序员和 VB 非程序员可以使用的众多选项之一。一个简单的项目设置就可以打开或关闭严格类型。就这么简单！程序员根据周围的上下文做出这个决定，而不是编译器。

“VB 支持可选参数。尽管 VB 开发者经常将此列为优势，但这是一种劣势，因为可选参数的使用削弱了调用者和方法之间的契约，让开发者可以放松分析并侥幸过关，直到 bug 悄然而至。[注：C# 的 param 数组构造与可选参数不同]”

将这一点普遍应用于所有支持可选参数的语言，就等于说 C++ 和 Delphi，仅举几例，是糟糕的语言。是不是很矛盾？毕竟，作者在整篇文章中都赞扬 Delphi 遵守严格的软件开发标准，尽管为什么可选参数本身就是不好的，至少是值得怀疑的，但这并不奇怪，因为文章中 80% 的陈述都是值得怀疑的（我必须重复我自己）。的确，方法组比可选参数更清晰，至少在我看来是这样，但这只是风格问题。此外，最近 CP 不是有一个民意调查问了这个问题吗？如果我没记错的话，没有压倒性的多数赞成或反对可选参数。最后，如果它们存在，也没有什么坏处；程序员决定如何处理它们。

“VB 支持传统的 VB 函数，引用 Microsoft.VisualBasic.dll。这些函数中许多都很慢，应该全部避免，转而使用 .NET 框架。然而许多 VB 程序员仍然使用它们。在新的 VB 项目中，这个危险的命名空间是默认包含的。”

鉴于作者完全缺乏商业判断力，更准确地说，是那种在开发系统时从不走捷径、总是重新造轮子的冲动，这样的评论无疑是意料之中的。的确，如果作者面临确定表达式 X 是否可以归类为数值表达式的问题，作者宁愿通过编写自己的函数来重新造轮子，而不是简单地调用 VB 的 IsNumeric 函数。毫无疑问，在性能至关重要的情况下，确实不应该使用其中一些函数，但作者更喜欢含糊其辞，使用“许多”这个词，而不给出任何具体的例子，好像读者真的会花时间自己去做性能分析一样。当然，这永远不会发生，相反，大多数读者会轻信作者的话，因为它们措辞如此雄辩。永远不要忘记，在软件开发中，每件事都有其时间和地点，而且，优秀的程序员是那些能明智地使用他们的工具并利用他们所拥有的一切的人。枪越多越好。

“VB 允许用不同名称的方法实现接口，使其混乱且难以找到实现。C# 则不然。”

看来作者在制定这个列表时，只是闭着眼睛随机挑选了两种语言之间的一些差异，而不考虑它们与他试图表达的观点的相关性。的确，对于像我这样喜欢声明式类型编程构造的人来说，这一点是 VB 胜出的地方，尽管最终这只是个人观点的问题，就像整个 VB vs C# 的辩论只是偏好或商业的问题一样。然而，这篇文章至少应该有起码的体面，提供一个代码示例来说明这一点，即名称映射如何优于声明式接口实现。一个从未写过一行 VB 代码的 C# 程序员，在至少没有看到代码的情况下，如何能客观地决定哪种风格更好呢？最后，C# 程序员只会轻信作者的修辞评论。此外，我问作者，一个接口成员和实际用于实现该接口成员的成员之间必须存在什么共同点？真的是两个成员的名称必须相同吗？还是两个成员必须有相同的签名？谢天谢地，VB 在 COM 中抛弃了那种名称映射式的接口实现方式！

“结论”

根据该文章

“如果一个组织满足于编写平均质量的软件，并且拥有平均水平的 VB 开发者，那么切换到 C# 可能没有任何好处。”

究竟组织中的谁来决定所使用的软件是低质量、平均质量还是高质量？换句话说，这样的判定是如何做出以及由谁做出的？程序员还是最终用户？如果真的进行了切换，平均质量的软件和平均水平的 VB 开发者团队如何自动变得更高质量？假设该组织不满足于编写平均质量的软件，那么该企业应该采取什么行动？软件的商业价值真的是其设计和实现的函数吗？当然不是！

“如果一个组织拥有一支出色的 VB 团队并希望继续改进，那么继续使用 VB 会有真正的危险。危险在于程序员会为了 C# 的机会而离开。一旦哪怕只有一个顶尖开发者这样做，团队向旧 VB 文化的极化可能会加速，从而加速人员流失。”

对于任何类型的开发，无论是高级开发还是普通开发，继续使用 VB 绝对没有任何危险。相反，VB 是一款出色的工具，已经存在并将继续存在多年，任何选择其中之一的企业都应该根据商业因素而非计算机科学因素来做决定。出色的程序员是那些能够适应周围环境的人，如果环境需要用 C#、VB、C++、Delphi 或任何其他编程语言编程，那就去做！企业不必担心你的 VB 程序员会为了涉及 C# 编程的职位而离开，而应该担心一个显而易见的事实，即如果跳槽到街对面的公司能带来更高的薪水，程序员就会离开。再次强调，这从来不是关于计算机科学，而总是关于商业。

“拥有一支出色 VB 团队的组织应该切换到 C#。出色的 VB 团队学习新语法将毫无问题，所以没有危险。然后，该团队将在未来几年中收获 C# 语法、语义和文化带来的好处。”

拥有一支出色 VB 团队的组织不应该切换到 C#，除非有商业原因需要这样的改变。否则，组织应该继续使用 VB 进行开发，并利用其投资。C# 语法不提供任何商业利益，VB 语法或任何其他编程语言的语法也不提供。对于配备了出色开发团队的任何组织来说，语法是无关紧要的，因为如果它确实是一支出色的团队，就应该能够处理任何语言的语法。此外，在未来几年，我们才能定义 C# 文化到底是什么；现在，任何这样的判定都为时过早。VB 和 C# 都是用于 .NET 开发的出色工具，选择其中之一应该基于商业环境，而不是 CS 环境。如果商业环境不倾向于任何一种语言，就问问你的开发者他们用什么会感觉更舒服。如果选择了 C#，很好。如果选择了 VB，那也很好。

最后的总结性思考

如果你处于招聘职位，请务必批判性地分析那些试图定义为什么语言 X 比语言 Y 更好的文章。很可能存在对语言 Y 的偏见，因此得出的任何结论都不会是客观的。不要相信我，而要相信一位智者：

Bjarne Stroustrup

“几位审稿人要求我将 C++ 与其他语言进行比较。我决定不这样做。因此，我重申了一个长期且坚定的观点：语言比较很少有意义，更少是公平的。对主要编程语言进行好的比较需要比大多数人愿意付出的更多的努力，需要广泛应用领域的经验，需要严格保持超然和公正的观点，以及一种公平感。我没有时间，而且作为 C++ 的设计者，我的公正性永远不会完全可信。”

“我还担心一种我反复观察到的现象，即在诚实的语言比较尝试中。作者们努力保持公正，但却因专注于单一应用、单一编程风格或程序员中的单一文化而无可救药地带有偏见。更糟糕的是，当一种语言比其他语言更为人熟知时，会出现一种微妙的视角转变：众所周知语言的缺陷被认为是次要的，并提出了简单的变通方法，而其他语言中的类似缺陷则被认为是根本性的。通常，在不太知名的语言中常用的变通方法，做比较的人根本不知道，或者因为在更熟悉的语言中不可行而被认为不令人满意。”

“同样，关于众所周知语言的信息往往是完全最新的，而对于不太知名的语言，作者们依赖的是几年前的信息。对于值得比较的语言来说，将三年前定义的语言 X 与最新实验性实现中出现的语言 Y 进行比较，既不公平也无信息量。因此，我将我对 C++ 以外语言的评论限制在一般性和非常具体的评论上。”

“话虽如此，我认为 C++ 是各种人群和应用的编程语言中的最佳选择。”

最后，请记住，商业永远是第一位的，学术只是其后的考虑。