python编程构建知识库_编程作为理论构建

python编程构建知识库

Building models and solutions in software is not just about programming. We will review Peter Naur’s classic paper.

用软件构建模型和解决方案不仅仅涉及编程。 我们将回顾Peter Naur的经典论文。

This classic article from 1985 anticipated many of the concepts that are in common use in the industry today. There are other interesting inspirational ideas from the paper that we have not yet taken advantage of.

1985年的这篇经典文章预测了当今行业中普遍使用的许多概念。 本文中还有其他有趣的鼓舞性想法，我们尚未加以利用。

历史背景 (Historic context)

Peter Naur’s paper from 1985 brings us concepts that still go unnoticed today.

彼得·纳尔(Peter Naur) 于1985年发表的论文为我们带来了至今仍不为人知的概念。

Written documentation was the model to follow.

书面文档是要遵循的模型。

The Cascading Lifecycle reigned supreme and was the industry standard. Peter Naur challenges us to reflect on our profession and brings us concepts that are still very relevant 25 years later.

级联生命周期是最高标准，是行业标准。 彼得·瑙尔(Peter Naur)挑战我们反思自己的专业，并为我们带来25年后仍然非常相关的概念。

Peter Naur was a Danish scientist, winner of a Turing Award (equivalent to the Nobel Prize in computing). He took part in the development of Algol 60 and helped create the syntax model BNF that all programming languages ​​use to define their grammar.

彼得·瑙尔(Peter Naur)是丹麦科学家，曾获得图灵奖 (相当于诺贝尔计算奖)。 他参与了Algol 60的开发，并帮助创建了所有编程语言都用来定义其语法的语法模型BNF 。

By 1985, Naur had discovered the difficulty in the education of computer professionals and its radical difference from other engineering disciplines.

到1985年，Naur发现了计算机专业人员教育方面的困难，并且与其他工程学科有着根本的区别。

His collaborative and human conception always contrasted with the Taylorist concepts of software development that see activities as watertight compartments and human beings as interchangeable pieces.

他的协作和人类观念始终与泰勒主义的软件开发观念形成鲜明对比，后者将活动视为不透水的隔间，而人类则是可互换的部分。

His epistemological approach, based on incremental iterative learning, contrasts with mathematics represented by the formal ideas of Dijkstra.

他基于渐进式迭代学习的认识论方法与Dijkstra形式思想所代表的数学形成了对比。

理论建构 (Theory building)

The paper presents novel ideas for the time, then taken up by the agile manifesto placing humanistic values ​​of knowledge acquisition over the Taylorist vision of software building.

本文提出了当时的新颖思想，然后被敏捷宣言所采纳，将知识获取的人文价值置于泰勒主义的软件构建愿景之上。

The theory is built by observing reality as in scientific procedure. The individuals jointly assemble the emergent knowledge of said observations. In this knowledge the whole is greater than the sum of the parts as Aristotle correctly predicted.

该理论是通过在科学程序中观察现实而建立的。 个人共同收集所述观察的新兴知识。 以这种知识， 整体大于亚里士多德正确预测的各部分之和。

The programming phase corresponds to the implementation stage of said theory in a machine.

编程阶段对应于所述理论在机器中的实施阶段。

This idea is partially contradicted by techniques such as TDD where knowledge training is encouraged while the solution is implemented.

这种想法与诸如TDD之类的技术在某种程度上矛盾，后者在实施解决方案的同时鼓励知识培训。

结果记录 (Documentation of findings)

According to Naur, software developed and the accompanying documentation are not enough to express the design ideas developed in theory.

根据Naur的说法，开发的软件和随附的文档不足以表达理论上开发的设计思想。

Ideas exist only among the individuals who formulated them.

想法仅存在于提出这些想法的个人中。

Therefore, the loss of any of its members, fragments the collectively generated knowledge.

因此，任何成员的流失都会破坏集体产生的知识。

Photo by Matt Artz on Unsplash

Matt Artz在 Unsplash上 拍摄的照片

提前敏捷 (Agile ahead of time)

The agile manifesto is based on four pillars:

敏捷宣言基于四个Struts：

1 Individuals and interactions over processes and tools

1 个人与流程和工具之间的互动

This corresponds to Naur’s ideas about the importance of people who are shaping knowledge.

这与Naur关于塑造知识的人的重要性的思想相对应。

2 Working software over comprehensive documentation

2 可用的软件，而非完整的文档

As we saw earlier, the documentation is irrelevant and is not a good starting point for further software development.

正如我们前面所看到的，文档无关紧要，也不是进行进一步软件开发的良好起点。

3 Customer collaboration over contract negotiation

3通过合同谈判进行客户合作

Communication to build the theory between the people developing the software, and the domain experts, is essential for that theory to correspond to a useful solution. As a corollary, only formal communication between the parties is counterproductive.

在软件开发人员和领域专家之间建立理论的交流对于该理论与一个有用的解决方案相对应至关重要。 因此，只有当事方之间的正式沟通才会适得其反。

4 Responding to change over following a plan

4 响应计划变更

The theory developed is a process that does not have an initial plan or an end goal. It is an incremental spiral where theory adjusts to needs as it learns from the real world.

开发的理论是没有初始计划或最终目标的过程。 这是一个渐进式螺旋，理论从现实世界中汲取了教训，理论可以根据需求进行调整。

公理没关系 (Axioms don’t matter)

Peter Naur’s theory is not based on formal axioms with postulates, derivation of theorems, or corollaries. Instead, look for a declarative model that explains the business we are simulating.

彼得·纳尔(Peter Naur)的理论不是基于带有假设，定理推导或推论的形式公理。 而是寻找一个说明性模型来解释我们正在模拟的业务。

This way of doing science is based on Ryle which, in turn, is based on the constructivist ideas about the language of Wittgenstein.

这种科学方法基于赖尔(Ryle) ，而赖尔又基于关于维特根斯坦(Wittgenstein)语言的建构主义思想。

Building software is acquiring knowledge. Trying to define the behavior of a class without having previously built any instance is an mistake.

建筑软件正在获取知识。 尝试在没有事先构建任何实例的情况下定义类的行为是一个错误。

To build theory in an exploratory way, prototyping languages ​​are much more useful tools than classification languages.

为了以探索的方式建立理论，原型语言比分类语言更有用。

Naur believes that there is no single scientific method but that there is a multiplicity of them. In accordance with Feyerabend’s ideas.

瑙尔认为，没有单一的科学方法，而是有多种方法。 按照费耶阿本德的想法。

This theory is understood as the knowledge a person must have in order not only to do things intelligently and well according to certain criteria, but also to be able to explain, answer questions, argue or justify the activity of concern.

该理论被理解为一个人必须具备的知识，不仅可以根据某些标准明智地做好事情，而且能够解释，回答问题，争论或证明关注的活动。

以人为本 (Human beings are the center)

The built theory cannot be expressed in the developed program. It can only be enunciated by the human beings who participated in its building.

建立的理论无法在开发的程序中表达。 它只能由参与其建筑的人来宣布。

Software is the product of these ideas.

软件是这些想法的产物。

Before a change of people a similar theory can be reconstructed from the artifacts. This theory will be incomplete and different with respect to that elaborated by the original authors.

在换人之前，可以从人工制品中重建类似的理论。 该理论将是不完整的，并且与原始作者所阐述的理论不同。

The asset of a software company is not the lines of source code with intellectual property that only reflect explicit knowledge. The people who develop that theory and build that software possess irreplaceable, and therefore valuable, implicit knowledge.

软件公司的资产不是具有仅反映显式知识的具有知识产权的源代码行。 开发该理论并开发该软件的人们拥有不可替代的，因此有价值的隐性知识。

The theory builders are based on a certain paradigm, as established by Kuhn. The paper mentions that, to know Newton’s theory, it is not enough to read only the physical formulas.

理论构建者基于库恩建立的某种范例。 该论文提到，要了解牛顿的理论，仅阅读物理公式是不够的。

the person having the theory must have an understanding of the manner in which the central laws apply to certain aspects of reality, so as to be able to recognize and apply the theory to other similar aspects. A person having Newton’s theory of mechanics must thus understand how it applies to the motions of pendulums and the planets, and must be able to recognize similar phenomena in the world, so as to be able to employ the mathematically expressed rules of the theory properly.

具有理论的人必须了解中央法律适用于现实的某些方面的方式，以便能够认识到该理论并将其应用于其他类似方面。 因此，拥有牛顿力学理论的人必须理解它如何应用于摆锤和行星的运动，并且必须能够识别世界上的类似现象，以便能够正确地运用数学上表达的理论规则。

如果模型不存在，结果将永远不会达到预期 (If the model does not exist, the results will never be as expected)

Naur begins the article by taking certain observations of what really happens with programs and the teams of programmers who deal with them, particularly in situations that arise from unexpected and erroneous executions or reactions of the software.

Naur在开始本文时，首先是对程序以及与之打交道的程序员团队的实际情况进行了某些观察，特别是在由于软件的意外和错误执行或React引起的情况下。

The difficulty of accommodating such observations in a production view of programming suggests that this view is misleading. The theory building view is presented as an alternative.

在编程的生产视图中很难容纳这样的观察结果，这表明该视图具有误导性。 提出了理论构建视图作为替代。

Building adequate and self-defense models is not easy. It requires a long process of mastery learning. Its fruits allow us to mitigate risks and to be able to maintain the existing software.

建立适当的自卫模型并不容易。 这需要长时间的精通学习。 它的成果使我们能够减轻风险并能够维护现有软件。

没有银弹 (There are no silver bullets)

Naur rejects the idea of ​​a single method to develop software.

Naur拒绝使用单一方法来开发软件的想法。

A development methodology, such as the one already mentioned TDD, must be complemented with other practices.

开发方法(例如已经提到的TDD )必须与其他实践相辅相成。

The absence of the much desired silver bullet is a sad reality, even these days.

即使在最近的日子里，也缺少令人向往的银弹是可悲的现实。

语言是偶然的 (Language is accidental)

According to Naur, the notation used to express this theory is accidental.

根据Naur所说，用来表达该理论的符号是偶然的。

Today we know that language is an inseparable part of what it can express.

今天，我们知道语言是语言表达不可分割的一部分。

It is not the same to write an algorithm in a declarative language than in a low-level one.

用声明性语言编写算法与使用低级语言编写算法不同。

Nor will we be able to express good business models in non-declarative languages ​​like C or GoLang.

我们也无法用非声明性语言(例如C或GoLang)表达良好的商业模型。

In the same way that we should not describe chemical or physical equations in natural language, we should not express our theory in low-level languages.

就像我们不应该用自然语言来描述化学或物理方程式一样，我们也不应该用低级语言来表达我们的理论。

The software should not be seen as the text that can be uploaded to a repository but as the theory that supports it .

该软件不应被视为可以上载到存储库的文本，而应被视为支持该文本的理论。

Photo by Roman Mager on Unsplash

罗曼·马格 ( Roman Mager)在Unsplash上的照片

错误的决定 (Bad decisions)

Throughout the theory building process, those involved make decisions so that the model corresponds to the bijection to the real world. These decisions are not explicitly documented.

在整个理论构建过程中，相关人员进行决策，以使模型与现实世界的双射相对应。 这些决定未明确记录。

Observing the result without knowing why a design decision was made is another limitation that a theory can explain but the built software cannot.

在不知道为什么要做出设计决定的情况下观察结果是理论可以解释但构建的软件无法解释的另一个限制。

In legacy systems it is common to see individuals act out of habit without wondering what reasons lead them to make decisions.

在遗留系统中，通常会看到个人出于习惯而行动，却不知道是什么原因导致他们做出决定。

模型在哪里？ (Where is the model?)

According to Naur, the model should remain solely as theory among the participants. However, if we stay true to bijection and create a model with a MAPPER the model will be only as good as the theory developed in it.

根据Naur所说，该模型应仅作为参与者的理论。 但是，如果我们坚持双射并使用MAPPER创建模型，则该模型将仅与其中开发的理论一样好。

GPT3 and the others transformers are cornering programmers who write code without understanding the underlying theory. We still have time to avoid it.

GPT3和其他的转换器正在使那些不了解底层理论的代码编写人员陷入困境 。 我们还有时间避免它。

结论 (Conclusions)

Building software is a human activity.

构建软件是一种人类活动。

Theory building is a mental activity that requires a process of learning and discussion until reaching a consensus.

建立理论是一项精神活动，需要学习和讨论才能达成共识。

Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.

本系列文章的目的之一是为软件设计的辩论和讨论创造空间。 我们期待对本文的评论和建议。

This article is also available in Spanish here.

本文也可以在西班牙语中找到 。

You can hit me up on twitter.

你可以在推特上打我。

翻译自: https://medium.com/dev-genius/programming-as-theory-building-9e8cb6f2cd73

python编程构建知识库