作为理论建筑的编程-彼得·诺尔
彼得·诺尔(Peter Naur)在1985年的一篇经典文章“作为理论建筑的编程”(Programming As Theology Building)中辩称，一个程序不是它的源代码。程序是一种共享的心理结构(他用了“理论”这个词)，它存在于从事该程序的人的头脑中。如果你失去了人，你就失去了项目。代码仅仅是程序的书面表示，而且它是有损的，所以你不能从它的代码重新构造程序。
目前的讨论有助于理解什么是编程。它建议，恰当的编程应该被视为程序员对手头的事情形成或实现某种洞察力或理论的一种活动。这一建议与更常见的概念相反，即编程应该被视为节目和某些其他文本的产物。
这里提出的观点的一些背景可以在对程序和处理它们的程序员团队实际发生的情况的某些观察中找到，特别是在意外的、可能是错误的程序执行或反应引起的情况下，以及在程序修改的情况下。在编程的生产视图中容纳这样的观察是困难的，这表明这种观点是误导的。提出了一种可供选择的理论建构观。
演讲的一个更一般的背景是坚信对编程是什么有一个适当的理解是很重要的。如果我们的理解不恰当，我们就会误解活动中出现的困难，而我们试图克服它们的努力就会导致冲突和挫折。
在本次讨论中，我们将首先概述一些重要的背景经验。接下来是对什么是编程的理论的解释，称为理论构建视图。接下来的几节将讨论理论构建视图的一些后果。
我将使用编程这个词来表示设计和实现编程解决方案的整个活动。我关心的是将现实世界中活动的某些重要部分和方面与计算机上运行的程序可以完成的正式符号操作相匹配的活动。有了这样的概念，就可以直接得出这样的结论：我所说的编程活动必须包括与程序执行(换句话说，程序修改)相匹配的、与现实世界活动中发生的变化相对应的时间上的开发。
我想说明主要观点的一种方式是，在这个意义上的编程主要必须是程序员积累某种知识，这些知识基本上是程序员直接拥有的，任何文档都是辅助的、次要的产品。
作为下一节中进一步阐述这一观点的背景，本节的剩余部分将描述处理大型程序的一些实际经验，这些经验在我思考问题的过程中对我来说似乎越来越重要。在任何一种情况下，经验都是我自己的，或者是与相关活动有直接接触的人传达给我的。
情况1涉及编译器。它是由A组为在计算机X上工作得很好的语言之地开发的。现在，B组的另一个任务是为计算机Y编写L+M语言的编译器，L+M语言的适度扩展。B组决定，由A组开发的L语言编译器将是他们设计的一个很好的起点，并与A组签订合同，他们将以完整文档的形式获得支持，包括带注释的程序文本和许多额外的书面设计讨论，以及个人建议。这种安排是有效的，B组设法开发了他们想要的编译器。在目前的情况下，重要的问题是A组的个人建议在有关如何实现语言的扩展M的事项上的重要性。在设计阶段，B组就扩建项目应采用的方式提出建议，并提交给A组进行审查。在几个主要案例中，A组发现B组建议的解决方案没有使用现有编译器结构中固有的设施，而是基于以补丁形式增加的结构，而补丁形式的补丁有效地破坏了该结构的威力和简单性，而这些设施在其文档中进行了详细的讨论，但B组提出的解决方案没有使用现有编译器结构中固有的设施，而是基于以补丁形式添加的设施，而补丁形式的补丁有效地破坏了该结构的功能和简单性。A组成员能够立即发现这些案件，并能提出简单有效的解决方案，完全在现有结构框架内。这是一个例子，说明完整的程序文本和附加文档如何不足以向热情高涨的B组传达对设计的更深层次的洞察力，即立即呈现给A组成员的理论。
在这些事件之后的几年里，B组开发的编译器在没有A组指导的情况下被同一组织的其他程序员接管。A组的一名成员获得的关于编译器在大约10年后进一步修改的信息清楚地表明，在后来的阶段，原来强大的结构仍然可见，但由于许多不同种类的无定形添加而变得完全无效。因此，作为一些最重要的设计思想的载体，程序文本及其文档再次被证明是不够的。
案例2涉及用于监控工业生产活动的大型实时系统的安装和故障诊断。该系统由其生产商销售，每次交付的系统都单独适应其特定的传感器和显示设备环境。每个安装中交付的程序大小约为200,000行。处理这类系统的相关经验涉及到安装和故障查找编程组的角色和工作方式。事实是，首先，从系统设计之时起，这些程序员就把系统作为一种全职工作来密切关注了好几年。其次，当诊断故障时，这些程序员几乎完全依赖于他们对系统和带注释的程序文本的现成知识，而无法构思出对他们有用的任何类型的附加文档。第三，负责系统特定安装操作的其他程序员小组，因此从生产商的工作人员那里获得系统文档和关于其使用的全面指导，他们经常遇到困难，因为咨询生产商的安装和故障查找程序员可追溯到对现有文档的理解不足，但安装和故障查找程序员可以很容易地解决这些问题。
这一结论似乎是不可避免的，即至少对于某些大程序而言，对其中错误的持续适应、修改和纠正，本质上依赖于一群与它们紧密而持续地联系在一起的程序员所拥有的某种知识。
如果假定编程必须涉及到程序员知识的构建这一基本部分，那么下一个问题就是更紧密地描述这些知识。这里要考虑的建议是，在Ryle[1949]的意义上，程序员的知识应该被恰当地视为一种理论。简而言之，拥有或拥有这种意义上的理论的人知道如何做某些事情，此外，他还可以通过解释、辩解和回答关于所关注的活动的问题来支持实际做的事情。可以注意到，赖尔的理论概念似乎是K·波普尔(K.Popper，and Eccle，1977)所说的未具体化的世界3对象的一个例子，因此具有可辩护的哲学立场。在本节中，我们将更详细地描述赖尔的理论概念。
赖尔[1949]发展了他的理论概念，作为他对智力活动本质的分析的一部分，第页
这里使用的理论概念显然并不局限于洞察力中最普遍或最抽象的部分。例如，要像这里理解的那样理解牛顿的力学理论，还不足以理解中心定律，如力等于质量乘以加速度。此外，正如库恩[1970，p.187ff]更详细地描述的那样，拥有该理论的人必须了解中心定律在现实的某些方面的应用方式，以便能够认识到该理论并将其应用于其他类似的方面。因此，一个拥有牛顿力学理论的人必须了解它如何应用于摆和行星的运动，并且必须能够认识到世界上类似的现象，从而能够正确地运用该理论的数学表达规则。
一种理论依赖于对现实世界的情况和事件之间的某种相似性的把握，这就是为什么拥有这种理论的人所掌握的知识原则上不能用规则来表达的原因。事实上，所讨论的相似之处不是也不可能用标准来表达，因此只能表达许多其他类型的物体的相似之处，如人脸、曲调或葡萄酒的味道。“。
按照赖尔的理论概念，程序员必须建立的是一种理论，即世界上的某些事情将如何由计算机程序处理或支持。论程序设计的理论构建观程序员建立的理论高于其他产品，如程序文本、用户文档和附加文档(如规范)。
在论证理论构建观点时，最基本的问题是说明程序员凭借其拥有的理论所拥有的知识是如何必然地、以一种本质的方式超越了记录在文档产品中的知识。这个问题的答案是，程序员的知识至少在三个基本领域超越了文档中给出的知识：
拥有程序理论的程序员可以解释解决方案与它帮助处理的世界事务之间的关系。这样的解释必须与世界事务的总体特征和细节在某种意义上映射到程序文本和任何附加文档中的方式有关，因此程序员必须能够解释程序文本的每个部分和它的每个整体结构特征与世界的哪些方面或活动相匹配，这是因为程序员必须能够解释程序文本的每个部分和它的每个整体结构特征与世界的哪些方面或活动相匹配，因此程序员必须能够解释程序文本的每个部分和它的每个整体结构特征与世界的哪些方面或活动相匹配，因此程序员必须能够解释程序文本的每个部分及其总体结构特征与世界的哪些方面或活动相匹配。相反，对于世界的任何方面或活动，程序员都能够陈述其映射到程序文本的方式。到目前为止，世界上最大部分的方面和活动当然会超出计划文本的范围，与上下文无关。然而，只有了解整个世界的人才能做出与世界某一部分相关的决定。这一理解必须由程序员做出贡献。
拥有程序理论的程序员可以解释为什么程序的每个部分都是这样的，换句话说，能够支持具有某种合理性的实际程序文本。论证的最终基础是并且必须始终保持程序员的直接、直观的知识。即使在理由使用推理的情况下也是如此，也许是通过应用设计规则、定量估计、与备选方案的比较等等，要点是原则和规则的选择，以及它们与手头的情况相关的决定，归根结底必须仍然是程序员的直接知识问题。
拥有程序理论的程序员能够建设性地响应任何修改程序的要求，从而以一种新的方式支持世界事务。设计如何最好地将修改合并到已建立的计划中，取决于对新需求与已构建到计划中的操作设施的相似性的看法。必须察觉到的那种相似性是世界各方面之间的一种相似之处。它只对了解世界的代理有意义，也就是对程序员来说，并且不能被简化为任何有限的标准或规则集，原因类似于上面给出的不能减少程序合理性的原因。
虽然本节的讨论提出了采用程序设计的理论建构观的一些基本论点，但对这一观点的评估应该考虑到它在多大程度上有助于对程序设计及其问题的一致理解。这些问题将在以下各节中讨论。
提出编程的理论构建观点的一个突出原因是希望建立对编程的洞察力，以支持对程序修改的合理理解。因此，这个问题将是第一个要进行分析的问题。
有一件事似乎大家都同意，那就是软件会被修改。一如既往的情况是，一旦程序投入运行，人们会觉得它只是手头问题答案的一部分。此外，程序本身的使用将激发出该程序应该提供的进一步有用服务的想法。因此，需要找到处理修改的方法。
程序修改问题与程序成本问题密切相关。面对改变程序运行方式的需要，人们希望通过修改现有的程序文本来实现成本节约，而不是通过编写全新的程序来实现。
期望以低成本修改程序应该是可能的，这需要更仔细的分析。首先，应该指出的是，这种期望不能通过与其他复杂的人造结构的修改相类比来支持。在偶尔实施改建的地方，例如建筑物，众所周知，改建的费用很高，事实上，先完全拆除现有建筑，然后再进行新的建设，往往发现在经济上更可取。其次，对低成本程序修改可能性的期望可以从这样一个事实中得到支持，即程序是保存在允许容易编辑的介质中的文本。要使这种支持有效，必须清楚地假设主要成本是文本处理成本。这与编程就是文本生产的概念是一致的。论理论建构观这个整装都是假的。这种观点不支持这样一种期望，即通常可以以低成本进行程序修改。
另一个密切相关的问题是程序灵活性。在程序中加入灵活性，我们在程序中建立了某些操作设施，这些设施并不是立即需要的，但很可能会被证明是有用的。因此，灵活的程序能够在不修改的情况下处理某些类别的外部环境变化。
人们经常说，程序的设计应该包含大量的灵活性，以便容易地适应不断变化的环境。就容易实现的灵活性而言，成功服务可能是合理的。然而，灵活性通常只有在实际成本的情况下才能实现。它的每一项都要设计，包括它要覆盖什么情况，它应该控制什么样的参数。然后必须实现、测试和描述它。这一成本是在实现程序功能时产生的，该程序功能的有用性完全取决于未来的事件。显然，内置的程序灵活性并不能满足使程序适应不断变化的世界环境的普遍需求。
在程序修改中，现有的编程解决方案必须更改SOA，以迎合它必须匹配的现实世界活动中的更改。修改所需要的，首先是现有解决方案与所需修改所要求的要求之间的对峙。在这种对抗中，必须确定现有解决方案的能力与新需求之间的相似程度和种类。这种确定相似性的需要凸显了理论建构观的优点。实际上，在相似性的确定中，任何忽视具有适当洞察力的人直接参与的中心要求的编程观的缺点都变得明显起来。要点是，必须认识到的那种相似性对于拥有节目理论的人来说是可以获得的，尽管完全超出了可以由规则确定的范围，因为甚至连判断它的标准都不能被制定出来。通过洞察新需求和程序已经满足的需求之间的相似性，程序员能够设计实现修改所需的程序文本的更改。
在某种意义上，不可能有理论修改的问题，只有程序修改的问题。事实上，拥有该理论的人必须已经准备好回应可能引起程序修改的各种问题和要求。这一观察结果得出了一个重要的结论，即程序修改的问题是基于程序设计是程序文本生产的假设而产生的，而不是将程序设计理解为一种理论建构活动。
从理论建构观看程序文本的衰败。
..
