我看到Edsger Dijsktra看到的关于编程风格的这篇文章.快速解释一下,主要的不同之处在于莫扎特,当编程的类比,在写任何东西之前完全理解(辩论)问题,而贝多芬在纸上写下笔记时作出了他的决定,并在此过程中创造了许多修改.使用Mozart编程,1.0版本将是软件的唯一版本,其目标应该是无错误和最高效率.此外,Dijkstra表示,不应该向那些提升和稳定性水平的软件发布.
基于他的观点,有两个问题.莫扎特的编程是否可行？如果我们采用莫扎特风格,我们今天写的软件真的会受益吗？
我的想法.看来,为了应对日益复杂的软件,我们已经从这种方法转向敏捷开发,公共beta测试和不断修订,定义Web开发的方法,速度最重要.但是,当我想到网络软件可以经历的所有修订时,尤其是在维护期间,当补丁通常应用于补丁时,然后通过繁琐的重构过程进行改进 - 莫扎特方式似乎非常有吸引力.它至少可以减少那些烦人的软件更新,例如Digsby,Windows,iTunes等,很多是无法预料的漏洞需要新的即时发布的结果.
编辑:有关Dijsktra视图的更准确说明,请参阅下面的响应.
莫扎特的编程风格是一个完整的神话(每个人都必须编辑和修改他们最初的努力),虽然"Mozart"在本例中基本上是一个隐喻,但值得注意的是,莫扎特本身就是一个神话.
莫扎特是一个神奇的神童神童,他在4岁时创作了他的第一个奏鸣曲(他实际上是6岁,而且它很糟糕 - 你不会听到它在任何地方演奏过).当然,很少有人提到他的父亲被认为是欧洲最伟大的音乐老师,并且他一旦拿起乐器或钢笔,他就迫使他的所有孩子每天练习演奏和作曲几个小时.
莫扎特本人小心翼翼地通过摧毁他的大部分草稿来保持他的音乐从他的脑海中浮现出来的幻觉,尽管足以证明他是一个像其他人一样的编辑.贝多芬对这个过程更加诚实(也许是因为他是聋子,无论如何都无法判断是否有人偷偷摸摸他).
我甚至都不会提到莫扎特从听歌鸟那里得到他的旋律的理论.还是事实,他创造了用骰子随机生成的音乐(这实际上是很酷,但也可能解释了多少莫扎特的音乐似乎空穴来风)的系统.
故事的寓意是:不要相信炒作.编程是有效的,接着是更多的工作来修复你第一次犯的错误,然后是更多的工作来修复你第二次犯的错误,等等等等,直到你死了.
它不会扩展.
我可以在脑海中找到一行代码,一个例程,甚至一个小程序.但是一个中等程序？可能有一些人可以做到这一点,但有多少,他们花了多少钱？他们真的应该写下一个薪资计划吗？这就像在muzak上浪费莫扎特一样.
现在,试着想象一下莫扎特队.只是几秒钟.
它仍然是一种强大的工具.如果你可以在头脑中弄清楚整条线,那就去做吧.如果你能找到一个包含所有有趣案例的小例程,那就去做吧.
从表面上看,它避免了回到绘图板,因为你没有想到一个边缘情况需要一个完全不同的界面.
可以通过学习另一种人类语言来解释更深层的含义(头部假的？).很长一段时间,你会想到哪些词代表你的想法,以及如何将它们命名为有效的句子 - 这种转录需要花费大量的前景周期.
有一天,你会注意到你刚才说话的解放感觉.它可能感觉像"用外语思考",或者好像"言语自然而然".你有时会绊倒,寻找一个特定的词或成语,但大多数时候翻译运行在"潜意识CPU"的巨大资源中.
"高目标"是开发一种解决方案的心理模型,该模型(大部分)独立于实现语言,将问题的解决方案与转录问题分开.转录很容易,重复,易于培训,抽象的解决方案可以重复使用.
我不知道如何教这个,但"在开始编写它之前尽可能多地搞清楚"听起来像是朝着这个目标的良好编程实践.
来自Usenet的经典故事,关于真正的莫扎特节目.
真正的程序员用Fortran编写.
也许他们现在这样做,在这个颓废的Lite啤酒时代,手工计算器和"用户友好"的软件,但回到了旧日,当时"软件"一词听起来很有趣,真正的计算机是用鼓和真空管制成的,真正的程序员用机器码编写.不是Fortran.不是RATFOR.甚至不是汇编语言.机器代码.原始的,朴素的,不可思议的十六进制数字.直.
为了避免新一代程序员在这个辉煌的过去无知中成长,我觉得有责任尽可能地通过代沟来描述真正的程序员如何编写代码.我会称他为梅尔,因为这是他的名字.
当我去Royal McBee Computer Corp.工作时,我第一次见到了Mel,这是一家现已解散的打字机公司的子公司.该公司制造了LGP-30,这是一种小型,廉价(按照当时的标准)鼓式记忆计算机,刚刚开始制造RPC-4000,这是一种改进得更好,更大,更好,更快的鼓 - 记忆电脑.无论如何,核心成本太高,而且不会留下来.(这就是你没有听说过公司或计算机的原因.)
我被聘请为这个新的奇迹编写Fortran编译器,Mel是我的奇迹指南.梅尔不赞成编译器.
"如果一个程序不能重写自己的代码,"他问道,"它有什么用处？"
Mel用十六进制编写了该公司拥有的最受欢迎的计算机程序.它在LGP-30上播出,并在电脑节目中与潜在客户一起玩二十一点.它的效果总是戏剧性的.LGP-30的展台在每次展会上都挤满了人,IBM销售人员站在一起互相交谈.这个实际销售的计算机是否是我们从未讨论过的问题.
Mel的工作是重写RPC-4000的二十一点程序.(端口？这是什么意思？)新计算机有一对一的寻址方案,其中每个机器指令除了操作代码和所需操作数的地址外,还有第二个地址指示位置,在旋转鼓上,下一条指令被找到了.用现代的说法,每一条指令都跟着一个GO TO!把它放在Pascal的烟斗里吸烟吧.
Mel喜欢RPC-4000,因为他可以优化他的代码:也就是说,在鼓上找到指令,这样当完成它的工作时,下一个就是到达"读头"并可立即执行.有一个程序可以完成这项工作,一个"优化装配工",但梅尔拒绝使用它.
"你永远不知道它会把东西放在哪里",他解释说,"所以你必须使用单独的常数".
在我理解这句话之前很长一段时间.由于Mel知道每个操作代码的数值,并分配了他自己的鼓地址,因此他写的每条指令也可以被认为是一个数值常数.如果它有正确的数值,他可以拿起一个早先的"添加"指令,然后乘以它.他的代码对其他人来说并不容易修改.
我将Mel的手动优化程序与优化汇编程序所使用的相同代码进行了比较,而Mel的运行速度更快.那是因为程序设计的"自上而下"的方法尚未发明,而梅尔也不会使用它.他首先编写了程序循环的最里面的部分,因此他们将首先选择鼓上的最佳地址位置.优化的汇编程序不够聪明,不能这样做.
梅尔也从未写过时间延迟循环,即使是那些笨拙的Flexowriter要求输出字符之间的延迟才能正常工作.他只是在滚筒上找到了说明书,所以 当需要时,每个连续的一个刚好超过读头; 鼓必须执行另一次完整的革命才能找到下一条指令.他为这个程序创造了一个令人难忘的术语.尽管"最佳"是一个绝对术语,如"独特",但是使其相对成为常见的口头练习:"不太理想"或"不太理想"或"不太理想".梅尔称最大时间延迟位置为"最悲观".
在他完成了二十一点程序并让它运行后,("甚至初始化程序已经优化",他自豪地说)他收到了销售部门的变更请求.该程序使用一个优雅的(优化的)随机数发生器来洗牌"牌"并从"牌组"处理,一些销售人员觉得这太公平了,因为有时客户输了.他们希望Mel修改程序,因此,在控制台上的感应开关设置下,他们可以改变赔率并让客户获胜.
梅尔犹豫不决.他觉得这显然是不诚实的,事实上,它影响了他作为程序员的个人诚信,所以他拒绝这样做.头部推销员与梅尔谈话,大老板也是如此,在老板的催促下,还有几位研究员.Mel终于放弃并编写了代码,但是他向后测试了,当感应开关打开时,程序会作弊,每次都会赢.梅尔很高兴这一点,声称他的潜意识是无法控制的道德,坚决拒绝解决它.
在Mel离开公司获得更加美好的价格之后,Big Boss让我看看代码,看看我是否能找到测试并将其反转.有点不情愿,我同意了.追踪梅尔的代码是一次真正的冒险.
我经常觉得编程是一种艺术形式,其真正的价值只有精通同一个神秘艺术的人才能体会到; 有可爱的宝石和精彩的政变隐藏在人类的观点和钦佩之中,有时是永恒的,因为这个过程的本质.通过阅读他的代码,你甚至可以用十六进制来学习很多关于个人的知识.我想,梅尔是一个无名的天才.
当我发现一个没有测试的无辜循环时,也许是我最大的震惊.没有考试.没有.常识说它必须是一个闭环,程序会循环,永远,无休止.然而,程序控制直接通过它,并安全地从另一侧传出.我花了两周的时间来搞清楚.
RPC-4000计算机有一个非常现代的设施,称为索引寄存器.它允许程序员编写一个程序循环,在其中使用索引指令; 每次通过时,索引寄存器中的数字被添加到该指令的地址中,因此它将引用一系列中的下一个数据.他每次只需递增索引寄存器.梅尔从没用过它.
相反,他会将指令拉入机器寄存器,在其地址中添加一个,然后将其存储回来.然后,他将从寄存器中执行修改后的指令.编写了循环,因此考虑了这个额外的执行时间 - 就像这个指令完成一样,下一个正好在鼓的读头下面,准备好了.但循环没有测试.
当我注意到索引寄存器位(位于指令字中的地址和操作码之间的位)被打开时,重要的线索就出现了 - 但是Mel从未使用过索引寄存器,一直保持为零.当灯亮了,它几乎让我失明了.
他将他正在处理的数据放在靠近内存顶部的位置 - 指令可以处理的最大位置 - 因此,在处理完最后一个数据之后,递增指令地址会使其溢出.进位将向操作代码添加一个,将其更改为指令集中的下一个:跳转指令.果然,下一个程序指令在地址位置为零,程序很快就开始了.
我没有与梅尔保持联系,所以我不知道他是否曾经屈服于那些漫长的过去时代已经洗过编程技术的大变革.我觉得他没有.无论如何,我印象深刻,以至于我不再寻找令人讨厌的测试,告诉Big Boss我找不到它.他似乎并不感到惊讶.
当我离开公司时,如果你打开正确的感应开关,二十一点程序仍然会作弊,我认为它应该如何.我不喜欢破解真正的程序员的代码.
Edsger Dijkstra在这个名为" 思想中的纪律 "的YouTube视频中讨论了他对莫扎特与贝多芬节目的看法.
这个帖子中的人们已经讨论过Dikstra的观点是如何不切实际的.我打算试着为他辩护一些.
Dijkstra反对公司基本上"测试"他们的客户软件. 发布1.0版,然后立即修补1.1.他认为该程序应该被打磨到"修补程序"补丁是临界不道德的程度.
他并不 认为软件应该一蹴而就,或者永远不需要做出改变. 他经常讨论他的设计理念,其中之一就是模块化和易于改变.他经常认为,在完全理解问题之后,应该以这种方式编写单独的算法.那是他纪律的一部分.
他找到了他对程序员的丰富经验后发现程序员并不高兴,除非他们正在推动他们的知识极限.他说,程序员不想完全编程,100%理解它,因为它没有任何挑战. 程序员总是想要处于他们的知识边缘. 虽然他理解为什么程序员是这样的,但他表示它不代表低误差容差编程.
有一些行业或编程应用我相信Dijkstra的"学科"也是有保证的.NASA流浪者,健康产业嵌入式设备(即配药等),某些转移我们资金的财务软件.这些领域在发布后没有任何增量变化的奢侈品,并且需要更多的"莫扎特方法".
我认为莫扎特的故事混淆了所发送的内容与它的开发方式.贝多芬没有对他的交响曲进行beta测试.(看到他在第一次公开表演后改变了多少分数会很有趣.)
我也不认为Dijkstra坚持认为这一切都在你脑海里完成.毕竟,他写了关于纪律编程的书籍,其中包括在纸上进行编程,并且在相同的程度上他想要看到数学质量的纪律,你是否注意到在处理问题时纸张和粉笔板数学家可能会消耗多少？
我赞成Simucal的回应,但我认为应该抛弃莫扎特 - 贝多芬的比喻.那个鞋子Dijkstra坚持纪律和理解到一个它真正不属于的角落.
补充说明:
电视普及并不是那么热门,它混淆了一些关于音乐作品和作曲家正在做什么以及程序员正在做什么的事情.用Dijkstra自己的话来说,从他1972年的图灵奖演讲开始:"我们不要忘记制作节目不是我们的事;我们的业务是设计能够显示所需行为的计算类别." 作曲家可能会出去发现所需的行为.
此外,在Dijkstra的观点中,版本1.0应该是最终版本,我们也很容易混淆期望的行为和功能随时间的演变.我认为他认为所有未来的版本都是因为第一个版本没有经过深思熟虑和可靠的思考而过于简单化.
即使没有上市时间的紧迫性,我认为我们现在更了解重要类型的软件随着用户体验它以及它们的实用目的而发展.明显的反例是游戏(也考虑如何开发戏剧性电影).你是否认为贝多芬可以在没有他之前的经验和探索的情况下写出第九交响曲？你认为观众可以听到它的内容吗？他应该等到他拥有完美的奏鸣曲吗？我敢肯定迪克斯特拉不会提出这个问题,但我确实认为他与莫扎特 - 贝多芬的关系太过分了.
另外,考虑下棋游戏软件.新版本不是因为之前的版本没有正确播放.它是关于利用国际象棋游戏启发式和可用计算机能力的进步.对于这个和许多其他情况,版本1.0作为最终版本的想法是基础的.据我所知,他理所当然地反对发布已知的不可靠且可能受损的软件,这些软件在维护和未来版本中都有不足之处.但莫扎特的反驳论据并没有阻止我.
那么,Dijkstra是否继续驾驶他购买的第一辆汽车,或者那辆汽车的克隆？也许有计划的过时,但其中很多都与改进和可靠性有关,这些改进和可靠性在前几代汽车技术中是不可能获得的.
我是Dijkstra的忠实粉丝,但我觉得莫扎特 - 贝多芬的事情过于简单化,也不合适.我也是贝多芬的大粉丝.
我认为这是可能出现采用莫扎特编程.我知道有一家公司,暴雪,它没有发布软件产品,直到他们做好准备.这并不意味着暗黑破坏神3将在一次令人眼花缭乱的精彩编码中完整地从一个人的脑海中完成.它确实意味着它将如何呈现给我们其他人.暴雪将在内部测试他们的游戏,直到他们解决了所有的问题之后才向世界其他地方展示.大多数公司都没有采用这种方法,而是更倾向于在软件解决问题时发布软件,然后在出现问题时修复错误并添加功能.这种方法适用于大多数公司(在不同程度上).
京公网安备 11010802040832号 | 京ICP备19059560号-6 