算法=逻辑+控制（左耳朵耗子：编程的本质是什么？）
大家应该都听说过等式‘算法+数据结构=程序’吧？这是Pascal设计者Niklaus Wirth的一本著作的书名，它刻画了过程式尤其是结构化编程的思想。后来Robert Kowalski进一步提出：算法=逻辑+控制。其中逻辑是算法的核心，控制主要用于改进算法的效率。在逻辑式编程中，程序员只需表达逻辑，而控制交给编程语言的解释器或编译器去管理。
1976 年，瑞士计算机科学家，Algol W，Modula，Oberon 和 Pascal 语言的设计师 Niklaus Emil Wirth 写了一本非常经典的书《Algorithms + Data Structures = Programs》（链接为 1985 年版） ，即算法 + 数据结构 = 程序。
这本书主要写了算法和数据结构的关系，这本书对计算机科学的影响非常深远，尤其在计算机科学的教育中。
1979 年，英国逻辑学家和计算机科学家 Robert Kowalski 发表论文 Algorithm = Logic + Control，并且主要开发“逻辑编程”相关的工作。
Robert Kowalski 是一位逻辑学家和计算机科学家，从 20 世纪 70 年代末到整个 80 年代致力于数据库的研究，并在用计算机证明数学定理等当年的重要应用上颇有建树，尤其是在逻辑、控制和算法等方面提出了革命性的理论，极大地影响了数据库、编程语言，直至今日的人工智能。
Robert Kowalski 在这篇论文里提到：
An algorithm can be regarded as consisting of a logic component, which specifies the knowledge to be used in solving problems, and a control component, which determines the problem-solving strategies by means of which that knowledge is used. The logic component determines the meaning of the algorithm whereas the control component only affects its efficiency. The efficiency of an algorithm can often be improved by improving the control component without changing the logic of the algorithm. We argue that computer programs would be more often correct and more easily improved and modified if their logic and control aspects were identified and separated in the program text.
翻译过来的意思大概就是：
任何算法都会有两个部分， 一个是 Logic 部分，这是用来解决实际问题的。另一个是 Control 部分，这是用来决定用什么策略来解决问题。Logic 部分是真正意义上的解决问题的算法，而 Control 部分只是影响解决这个问题的效率。程序运行的效率问题和程序的逻辑其实是没有关系的。我们认为，如果将 Logic 和 Control 部分有效地分开，那么代码就会变得更容易改进和维护。
编程的本质
两位老先生的两个表达式：
- Programs = Algorithms + Data Structures
- Algorithm = Logic + Control
第一个表达式倾向于数据结构和算法，它是想把这两个拆分，早期都在走这条路。他们认为，如果数据结构设计得好，算法也会变得简单，而且一个好的通用的算法应该可以用在不同的数据结构上。
第二个表达式则想表达，数据结构不复杂，复杂的是算法，也就是我们的业务逻辑是复杂的。我们的算法由两个逻辑组成，一个是真正的业务逻辑，另外一种是控制逻辑。程序中有两种代码，一种是真正的业务逻辑代码，另一种代码是控制我们程序的代码，叫控制代码，这根本不是业务逻辑，业务逻辑不关心这个事情。
总之，通过这两个表达式，我们可以得出：
Program = Logic + Control + Data Structure
如果你再仔细地结合我们之前讲的各式各样的编程范式来思考上述这些概念的话，你是否会觉得，所有的语言或编程范式都在解决上面的这些问题。也就下面的这几个事。
- Control 是可以标准化的。比如：遍历数据、查找数据、多线程、并发、异步等，都是可以标准化的。
上述三点，就是编程范式的本质。
- 有效地分离 Logic、Control 和 Data 是写出好程序的关键所在！
https://mp.weixin.qq.com/s/3WKImtdg_rEd_R9eCjs6WA
计算机程序的本质
从本质上来说， 程序就是一系列有序执行的指令集合。 如何将指令集合组织成可靠可用可信赖的软件（美妙的逻辑之塔）， 这是个问题。
程序逻辑控制。从编程角度来说， 开发者应对的就是逻辑， 逻辑的表达、组织和维护。 逻辑是事物自此及彼的合乎事物发展规律的序列。指令是逻辑的具体实现形式。
逻辑成立的先决条件是合乎事物发展规律。 程序只能处理数值， 却传入了字符串， 就只能报错而无法继续； 当处理海量数据时， 若内存不足， 就会导致程序崩溃； 若程序存在内存泄露， 随着时间的推移而耗尽内存， 也会导致程序崩溃。 多个线程同时修改一个共享变量， 若不加控制， 就会因为不同线程执行修改变量的时序的不确定导致该变量最终值的不确定。 这些就是程序执行的发展规律。 要编写程序， 必定要先通悉这些规律。
规律的表现形式是：如果条件 (C1, C2, ..., Cn) 是产生结果 (R1, R2, ... , Rn) 的充分必要条件， 那么当 C1, C2, ..., Cn 任一不满足条件时， 都不可能产生结果 (R1, R2, ..., Rn) ； 反之， 若结果 (R1, R2, ..., Rn) 没有出现， 则必定是 C1, C2, ..., Cn 某一条件不满足导致。 错误和异常即是 C1, C2, ..., Cn 任一不满足条件的表现。规律的性质是必然的， 不存在可能之说； 只存在人们探索的是否足够精确。编程开发首先应当懂得程序执行的规律， 然后才是实际的开发； 否则就会被程序的结果折腾得死去活来。
在通悉程序执行规律之后， 程序需要解决如下问题：
- 要表达什么逻辑
- 如何表达该逻辑；
- 如何维护该逻辑。
暂时先回到软件的起点， 回顾一下这一切是如何发生的。
—— SDK IDE BUG “” 此外， 软件还经历了“单机程序 => 多机程序 => 分布式程序” 的过程 ， 多机联网程序因为多个子系统的交互变得更加复杂。 这里不再赘述。
但请注意， 无论软件发展到多么复杂的程度， 总有一群人， 在试图从程序的本质中探究软件开发的基本问题， 他们试图论证和确保程序的正确性、提炼软件的基本属性并进行衡量； 程序的正确性本质是逻辑学来保证的。 没有逻辑学， 程序根本就无法立足， 更不可能有今天的大规模应用。
软件开发工具让我们更有效率地创造逻辑、 远离语法错误的困扰；
公共库将常用的通用逻辑块封装成可反复使用的组件， 避免不必要的重复劳动；
设计模式体现的是如何可扩展地解决常见的逻辑交互问题；
应用框架解决的是应用的通用逻辑流的控制的问题，让开发者更多地聚焦具体业务逻辑上；
开发技术是在具体的应用情境下按照既定总体思路去探究具体问题解决的方法。
表达和维护大型逻辑
表达和维护大型逻辑的终极诀窍就是： 将大型逻辑切分为容易消化的一小块一小块， “不急不忙地吃掉”。
在该方法的实践中， 可以充分利用现有的开发工具、公共库、设计模式、应用框架、开发技术。
软件开发：如何表达和维护大型逻辑
https://www.cnblogs.com/lovesqcc/p/4334095.html?ptvd
