📄 9511.html
字号:
<html>
<head>
<title>Hardcore 独立宣言 Part I</title>
</head>
<body bgcolor="#FFFFFF" vlink="#808080">
<center>
<h1>Hardcore 独立宣言 Part I</h1>
</center>
<hr size=7 width=75%>
<hr size=7 width=75%><p>
Posted by <a href="mailto:mrposts@ms24.hinet.net">AKL</a> on January 23, 1999 at 03:52:51:<p>
In Reply to: <a href="9498.html">一篇文章请大家参考。(Say Goodbye to the Hardcore Visual Basic)</a> posted by 小吴 on January 22, 1999 at 13:05:38:<p>
Hardcore 独立宣言 Part I By Bruce McKinney,Translated By AKL<br> <p> 置身于一连串的人为事件中，程式员需要能解开把他和某种语言绑在一起的束缚，为了顾及与自己持有不同意见的人的最起码尊重，他不得不对迫使自己异于他人的原因有所宣告。<p> 随着 Visual Basic 6 的来临，我必须终止我与它的合作关系，很不幸地，我那一本「Hardcore Visual Basic」第一、二两版的忠实读者们，我对不起你们！<p> 现在我的一些忠实读者们可以指出我正企图自毁长城。我的书在第二版时有一些瑕疵，由于太过明确了，以致于我在Visual Basic团队上一些最好的程式码开始枯竭。我倒是希望我能有时间去写下一版的书，但我没有。虽然书的背面大肆渲染着： ” 也许我写了够多的Visual Basic已经好一阵子了，短期内不会再写另一本书。 ”<p> 当然，在你已经培蕴出一个专家的声誉后，要放弃一个语言不是那么容易的。你会不断地收到来信、堆积如山的Bug，时时刻刻都会有人要你做相关的提供与建议。如果你如此了解一种语言，有的时候你会对它抱有梦想，诱使你对它再作挣扎。我就是这么被诱惑的。这是一个关于最后一次尝试与轰轰烈烈结束的故事。<p> 同时也是想把最后的话讲完，关于对Visual Basic的热情、我的道歉、Bug修正、一些建议和一点点的技术资讯。最后，它也将充满一群新读者的空洞，他们意外地发现书上文字的主人(从VB6提供的MSDN CD中)，而不是程式码，虽然那不他们的错。<p><br> 这个故事将有所启示，纵使是对于那些仍有意为了享受公认好处而受制于Visual Basic人。<p>＜＜ 一趟 Delphi 之旅如何地确认了我的偏好与对Visual Basic的失望 ＞＞<p> 1997年的秋天，我做了一趟边塞之旅并探望了Delphi。早在1983年的时候，Turbo Pascal原是我第一个编译式语言的路线。当我对Visual Basic的不满日益加深后，我决定回到Pascal的怀抱，看看它是如何地在Delphi中成长。你可看见我在1998年4月一份Delphi刊物中的实验结果。既然那篇文章的读者里没有几个是订阅该杂志的，我就概略地阐明两项重点： ”Visual Basic使简单的事情更简单；Delphi却使难的事情变简单了 ”<p>＜＜ 如果你如此了解一种语言，有的时候你会对它抱有梦想，诱使你对它再作挣扎 ＞＞<p> 我的Delphi文章中重新实作了在第十一章讨论的『File Notification Server』(以下简称「档案通知伺服器」)，"File Notification"，在640页。两个版本的档案通知伺服器的功能都一样，但是它们的实作方式有一个不小的差别。Delphi 在Client 端的程式中与Server端Hook的方式比Visual Basic简单得多了。在实作方面，VB确实在定义类别与介面上有一点儿优势。档案通知资料的储存体在两种语言中都不难实作。但是，在 Delphi 的实作中证明了它在「Server端如何被启动与关闭」上有着强而有力的优势。<p><br> 在Visual Basic中，并没有文件说明如何取得Client端连接的数目－好让你知道最后的一个Client端已经结束连线，使你可以后续做一些清理的工作然后关闭程式。我必需使用一些API和复杂的引用(连线)计算方案。Delphi 的精灵则替你的元件产生预设的讯息回圈，如果它所执行出来的东西不是你想要的，你可以用自己的程式码取代它－我就是这么做的。我的回圈提供一个等待通知事件的地方，并从Delphi的公用「COM伺服物件」的 ObjectCount 属性来检查 Client 数目。在我的Delphi文章中，我概述了这两种语言之间孰为可取：VB容易开发，并使用简单的Automation物件，它藉由隐藏细节来达成目标。一旦你走向更为复杂的Automation问题时，你会发现这些细节并不像它们当初看起来的那样无关紧要。你会想要看清并控制它们。如果你够聪明的话，你常可以迂回刺探，绕过VB的限制。但是在Delphi中，你通常可以直接解决问题，而用不着一些诡异的方式。<p><br> 这听起来像是Delphi赢了，但实际上我比较喜欢Visual Basic的模型。「简单的东西就让它简单一点」对我来说更为重要。我不在乎刺探不寻常的东西。我的问题在于一个程式语不能胜任于它的合同。当然，不论是Delphi或VB，它们都没有随品附上什么白纸黑字的合同。不过，以下是从它们的历史、文件、特徵、和市场角度来看，我如何解释它们的承诺：<p>Delphi合同：藉由精灵、函数库和继承机制的使用，我们将在枯燥无味的「图形介面程式与元件( COM或其它方面 )建立」上替您完成百分之八十的工作。我们将提供更复杂但更标准的手段，让你去做剩下的百分之二十。<p>Visual Basic合同：我们将以你看不见的方式替你完成百分之九十五「图形介面程式与COM元件建立」的枯燥工作，剩下的百分之五要靠你们自己。<p> Visual Basic的大部份都在黑盒子里。它确实有用，但除了推断与测试之外，你无法知道结果。Delphi就是个用生啤酒彩妆的盒子。如果你花点儿时间，你就可以看穿玻璃盒子后的秘密，发现它是如何运作的以及如何去扩展它。面对这两份合同，程式员或许可以合理地选择其一。我比较倾向于Visual Basic，然而，我不再相信 VB 会实现它的承诺。<p><br>＜＜为什么我会对我最喜欢的语言感到疲倦＞＞<p> 我喜欢Visual Basic是因为它隐藏了细节。如果你曾用 C 写过一个最简单的Windows程式，你就会知道在你什么程式码都还没写之前，每个Form的身后就都已经有了一个所谓的「讯息回圈」和数量多得难以置信的程式码。自这么多种语言宣称它们具有RAD环境特质的日子以来，年轻的程式员就无法了解1987年Visual Basic是多么革命性地在首次现身时震惊了程式设计的世界。<p> Visual Basic建立 Form 的模式是我当初评估所有新特质时的标准。我在Form里面摆了一个布林值的叙述当做测试。「在Visual Basic中，使用某一项特质就像建立与使用 Form 一样容易」－ 那是在 Visual Basic 1 时所设立的标准，而这正是我所期待的标准应具有的特质。让我们来试试看！<p>”在Visual Basic中，建立控制项就和建立Form一样容易 ”－理论上来说没错，但实际上却不是如此！你可能如建立Form 一样简单地建立了一个 UserControl，并开始加入属性、方法和事件，但它不是一个实际可用的Control。你还要用精灵去委派属性和方法。「以精灵代劳」这项技巧是取自Visual Basic的模仿者－如Delphi。虽然精灵在「state-of-the-art」的程式撰写环境中分为两种路线，而Visual Basic是最广泛为人接受的一种路线，但是Visual Basic并没有把这项技巧实现得很好。<p>”在Visual Basic中，物件导向的程式设计就像 Form 一样简单 ”－就第一层面来说是没错，但是当你想要在你的类别中加上一些进阶特性时就不行了。VB在物件导向概念(诸如Friend与Static成员)的实作上，有着一个愚蠢的大漏洞，使得它只剩下 "以物件为导向" 而不具有『继承』或『Constructors』(译注：Constructor是C++等 "低阶" 物件导向程式语中用来初始化物件的机制)。<p>”在Visual Basic中，建立COM物件就像建立Form一样容易”－大多数的时候里没错！Visaul Basic已经在隐藏COM机制上替我们完成了惊人的工作，某些Visual Basic的程式员还会抱怨它在替元件产生GUID与回朔相容性的维护上的太过于自动了。(译注：这一句话很重听！)当你闯入一个 "环状参照" 时(注：这里所谓的 "参照" 指的是物件的Reference)，事情相当可能变得混乱不堪。非但如此，委派的动作需要一大堆程式码，即使它的模版可以轻易地被自动建立。不过VB在COM的部份，它做得还不错！<p><br>”在Visual Basic中，以最新出品的界面来建立程式就像建立Form一样 ”－ 绝对不是！那些实现流行特质的Control像TreeView、ListView、ToolBar、CoolBar、和有图像的ComboBox，都是随便用几个不怎么恰当的属性页来搪塞的便宜货。直到现在都还很难在Menu中加入图形，即使是很普遍的小图示也难以处理。你得在NameSpace中巡览，才能建立档案检视器或Shell Extension。(译注：NameSpace是一种延伸作业系统的机制，当一个程式或元件符合某种COM规格的要求，并可以提供某一类型的服务时，它可以向Windows 注册为OS界面的一部份，也就是所谓的ShellExtension。例如：桌面上 "非档案" 的图示，以及我的电脑视窗中 "非磁碟机" 的Icon，都是属于NameSpace的类型) 每隔几个礼拜，我们就得落后于新出笼的COM界面。别想在程式中收到 "摇摇鼠" 的事件或是视窗支援多萤幕了....。<p>”在Visual Basic中，使用三十二位元作业系统的特质就像建立 Form一样简单”－ 绝大多数的时候里不是！Visual Basic在Automation元件的执行绪上做得很好，但是在一般的程式中并不允许你自由地设立执行绪。你得为了「同步」与「记忆体映射档」的主题而深入作业系统。从很多角度来看，Visual Basic只能说是一个三十一位元的语言。<p>”在Visual Basic中，建立「集合」就像建立 Form一样简单 ”－ 错得很可笑！<p>”在Visual Basic中，建立像函数的DLL就像使用Form一样简单 ”－ 错！全域物件表现得有那么点儿像中古世纪神学家所想出来的倒胃笑话。<p><p>＜＜当种种限制都还可以被容忍时，最好是忍受着，之后就抛弃它转向我们惯用的语言。＞＞<p>”在Visual Basic中，使用指标会像使用Form一样简单吗？ ”－ 错误的问题！没有人可以使指标容易使用些，也没有人应该在一个要求「简单」前题下语言中加入指标。正确的问法是：" 你如何在VB里不用指标来完成『在其它语言中使用指标的事情？』" Java做到了，而VB应该做得到。指标在Visual Basic里就像是脚踏车上的自动变速状置。<p><br> 我还可以继续列举类似的情形。有别于vb6的许多特性，vb6、VB6中几乎是所有的特性都无法达到「简化Form建立」的标准。怎么会呢？我想那是由于缺乏想像力与憧景所致。<p> 我知道Visual Basic的发展者将会宣称他们并不是缺乏憧景。只是他们的憧景和我不同。我对Visual Basic的梦想是希望有朝一日它能成为一个好的「一般用途、高阶、物件导向的程式语言」。在 Visual Basic 4 的时候，我认为这个语言正朝向那个目标迈进。版本5、6却让我失望了。<p> 我知道 Visual Basic 原本在真实世界里被当作资库操作的新衣。我也知道微软正尝试着把它变成一种Web发展语言。但这两种用途都引起不了我的兴趣。我对它们并没有什么成见，但是它们不在我的书里 － 因为我不关心。<p> 我所想像的是：大部份我的读者花了百分之八十的时间和 SQL, RDO, ADO, OLE DB, Dynamic HTML, ASP, MTS 和其它的一大串 "以字首字母缩写的字" 在玩文字游戏，这些读者花了百分之二十的时间在一般性目的的工作上，使他们的资料看起来不错。因为Visual Basic不是一个很好的一般用途语言，他们必需看我的书才能理解该怎么做。<p> 我把所有的时间都放在一般用途的东西上。这些缠住其他人百分之二十时间的限制却缠住了我百分之一百的时间。最后，我产生了一种幻觉，以为 Visual Basic 的发展者要把它发展成一个好的一般用途语言。但事实上他们从未以任何型式承诺过这一点，他们从不曾描述过这是他们发展的目标之一。虽然他们在 4.0 时候的某些举动曾经加强了这一个幻觉， 5.0 时变得很少，而 6.0 则完全没有。<p> 那么，为什么当他们并没有对语言本身做改善时，我会觉得自己被出卖了？我只能怪我自己，但现在我认出了这一个假像，我可以自我治疗。我已经越过悲痛的舞台：冲击与否定、愤怒、沮丧、讨价还价，还有悲哀。我仍在最后的舞台上活跃着：宽恕、坚定，以及接受。<p> 好笑的是，就商业的立场来看，他们可能是对的。我所期待的改善大概不会使他们赢得更多的客户。你要如何在一长串的市场特性中小作修正，像是在常数里提供连续字串呢？潜在的客户群真的会以一个没有Constructor的VB作为选择时的依据吗？我们之中的大多数人离不开VB是因为职业与商业上的原因，不论我们是多么地沮丧。当种种限制都还可以被容忍时，最好是忍受着，之后就抛弃它转向我们惯用的语言。<p><br> Visual Basic的发展者选择了累积越来越多粗糙打造的便宜货(译注：指的是内附的Control)，让使用者认识这些便宜货，而非了解如何去打造它们，卖的是黑盒子。这一点也许他们又做对了，不过是得付上一些代价。他们用的是同阶层人士对他们的敬重，去换取商业上的成功。不幸地，他们的委员会无法在盈收的前题下选择自重。这个问题的核心在于没有人能做主。这个语言不是一个人设计的，没有梦想家，也就不会有憧景。<p> Visual Basic 的小组委员得对来自各方的声音作出回应。一方面他们必须与微软的Office产品协调更新，因为这些产品使用VBA而且在开发环境上某些部份是相同的。在另一方面，他们必须其它的 Visual Studio 语言产品协调更新，因为某位高层人士曾经说过Visual Basic是 Visual Studio 的一部份，纵使它与其它的语言没有相同的地方，除了一样可憎的说明档阅览器之外...。<p> 在第三方面，他们必须理会来自不同作业平台技术的压力如ADO还有不同的Web技术。<p> 第四方面，他们必须对使用者作出回应，个个都比其他人都来得更为愤怒与怨恨。第五方面，他们自家内部分成了两派，正当一派建议要提供像AddressOf这类的半熟进阶特徵时，另一派却又鄙视将语言改成更简单的 "语法糖果"。<p> 有的时候，直接把使用者要求的给他们会比假设他们的需求来得更简单。我欣赏这种设想，但我可不需要一个由一群专门听从意见的人所设计出来的语言。<p><br>To be continued...<p>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -