高级语言与交互式编程

使用高级语言的主要理由是什么？

• 理由一（生产率）: 见 020-人月与进度中的生产率数据, 整体提升而非部分增加;
• 理由二（调试）: 存在更少的 bug, 而且更容易查找;
• bug 更少的原因: 它避免在错误面前暴露所有级别的工作, 既不会造成语法错误, 也不会产生语义问题（如不当使用寄存器）;
• 更容易查找的原因: 编译器的诊断机制帮助找出类似错误, 更重要的是非常容易插入调试快照;
• 作者结论: 这些生产率和调试优势是势不可挡的, 无法想象使用汇编语言能方便地开发系统软件;

对高级语言的传统反对意见是否成立？

反对意见	作者回应
无法完成我想做的事情	所有证据显示人们可以完成想做的事, 只是需要时间精力找出如何做, 可能需要一些讨人嫌的技巧
目标代码过于庞大	新的优化编译器已非常令人满意, 并将持续改进
目标代码运行速度过慢	经优化编译器生成的代码比绝大多数程序员手写代码效率更高; 全面测试后可把 1%-5% 替换成手写代码解决速度问题

系统编程应该用什么语言？

• 原著结论: 当时可供合理选择的语言是 PL/I--它提供完整功能集, 与操作系统环境吻合, 并有多种编译器（交互式、快速、诊断性好、优化程度高）;
• 作者个人用法: 用 APL 解决算法更快, 然后翻译成系统环境下的 PL/I;
• 20 年后修正: "现在可供合理选择的语言是 PL/I"不再正确;

交互式编程解决了什么问题？

• 关键认识: 调试是系统编程中很慢和较困难的部分, 而漫长的调试周转时间是调试的祸根;
• 逻辑合理性: 就这一点而言, 交互式编程的逻辑合理性勿庸置疑;
• 数据支持: Harr 的数据表明系统软件开发中交互式编程的生产率至少是原来的两倍;
• 概念差异: Multics（及后续 TSS）与其他交互式系统在概念上很大的不同--多个级别上数据和程序的共享和保护、可延伸的库管理、协助终端用户共同开发的设施;
• 边界: 在某些应用上批处理系统决不会被交互式系统取代;

高级语言和交互式编程为什么是一对强大的工具？

• 依赖关系: 由于远程键盘终端无法用于内存转储的调试, 大多数交互式工具的有效使用需要采用高级语言来开发;
• 协同效果: 有了高级语言, 可以很容易地修改代码和选择性地打印结果;
• 结论: 实际上它们组成了一对强大的工具;
• 20 年后: 只有懒散和惰性会妨碍它们的广泛应用, 如今它们已经在全世界使用;

文本编辑系统为什么是节省劳动最多的工具？

• 评价: 在所有工具中, 最能节省劳动力的可能是运行在可靠平台上的、计算机化的文本编辑系统;
• OS/360 实例: 由 J. W. Franklin 发明的系统使用非常方便; 没有它, OS/360 手册的进度会远远落后, 而且更加晦涩难懂;
• 副作用: 6 英尺厚的 OS/360 手册带来新的不理解问题, 很多人认为它是一大堆口头垃圾;
• 作者的两点回应:
  • 文档规模不可避免, 需要仔细的阅读计划; 应把手册看成图书馆或百科全书, 而不是一系列强制阅读的文章;
  • 它比那些刻画大多数编程系统特性的短篇文档更加可取, 但仍有很多需要改进的地方, 事实上某些部分已被很好地改写;