Hello everyone, I am han Cao 😈, a grass code ape 🐒 who has been working for more than a year. If you like my article, you can follow ➕ to like it and grow up with me. Add my wechat: Hancao97, invite you to join the group, learn and communicate together, and become a better engineer

“This is my fourth day of participating in the First Challenge 2022. For more details: First Challenge 2022.”

The overview

Previous article: Cold Grass and Architecture Clean | Leaves flying, story begins 🌟 A brief introduction to design and architecture and the value of architecture, this article will introduce programming paradigms.

Programming paradigms refer to the way programs are written and have relatively little relationship to a specific programming language. These paradigms tell you what code structure to use and when. To this day, there are only three paradigms:

• Structured programming

Structured programming limits and standardizes the direct transfer of program control. Dijkstra argued that using unrestricted jump statements like goto would damage the whole structure of the program, and it was Dijkstra who first advocated replacing jump statements with the familiar if/then/else and do/while/until statements.

• Object-oriented programming

Object – oriented programming limits and standardizes the indirect transfer of program control.

• Functional programming

Functional programming limits and normalizes assignment in programs.

All three paradigms limit and regulate the power of programmers in one way or another. There is no paradigm that adds new capabilities. That is, the purpose of every programming paradigm is to set limits. These paradigms are mainly designed to tell us what we can’t do, not what we can do.

Also, we should realize that these three programming paradigms limit the use of goto statements, function Pointers, and assignment statements, respectively.

Structured programming

But sex is derived

Programming is a difficult activity. A program, whether complex or not, contains a lot of detail. These details are far beyond a programmer’s cognitive capacity without the help of tools. In a program, even a small detail of the error will cause the entire program to fail.

Dijkstra’s solution to the above problem is mathematical derivation. That is, programmers can use code to chain together some of the structures that have been proved to work, and as long as they prove that the extra code is correct, they can deduce the correctness of the whole program.

Dijkstra found a problem in his research: certain uses of the Goto statement made it impossible for a module to be recursively broken down into smaller, provable units, which made it impossible to use decomposition to further break a large problem into smaller, provable parts.

Other uses of the goto statement did not cause this problem, but Dijkstra realized that their effect was consistent with the simpler branch if-then-else and loop do-while. If only these two types of control structures are used in your code, you can certainly decompose your program into smaller, provable units.

Bohm and Jocopini showed that one could construct any program using three structures: sequential structure, branch structure, and loop structure. This finding is important because it proves that the set of control structures we need to build deducible modules is the same as the minimum set of control structures we need to build all programs. Thus, structured programming was born.

Science: sequence structure and can use the enumeration method to prove the correctness of the branch structure, but the loop structure need to use mathematical induction * * * * : specifically, first of all to illustrate the correctness of the circular one with enumeration method, and then prove that if N is correct, then cycle N + 1 times also is correct.

GOTO is harmful

Here’s an interesting story:

In 1968, Dijkstra wrote a letter to the editor of CACM. In the letter, which was later published in the March issue of CACM under the headline Go To Statement Considered Harmfu/1, Dijkstra detailed his views on three control structures.

Since there was no Internet at the time, people couldn’t go online and make sarcastic comments about Dijkstra. The only thing they could do, and most of them did, was to write letters to the editors of various published newspapers.

Some of the language was not very kind, even very negative. But there are strong supporters. In all, the heated debate lasted more than a decade.

In the middle of a joke: this scene like all kinds of online war, ha ha ha

The debate eventually petered out. The reason is simple: Dijkstra is right. As programming languages evolved, goto statements became less important and eventually disappeared. The GOTO statement has been eliminated from most modern programming languages.

Today, we are all practitioners of the structured programming paradigm, willingly or not, because we use programming languages that largely prohibit unrestricted direct control transfer statements.

Functional degradation resolution

Since the structured programming paradigm can decompose modules recursively into derivable units, it means that modules can also decompose modules functionally. In this way, we can break down a large problem into a series of higher-level functions, and each of these higher-level functions can continue to break down into a series of lower-level functions, and so on recursively. More importantly, each split function can also be written using the structured programming paradigm.

By using these techniques, programmers can break down large system designs into modules and components, which can eventually be broken down into smaller, provable functions.

The idea is still used 🌟

conclusion

The most valuable thing about the structured programming paradigm is that it gives us the ability to create units of falsifiable program. This is why modern programming languages generally do not support unrestricted GOTO statements. More importantly, this is why functional degradation is still one of the best practices in architectural design.

Finally, I’m impressed: a program can be proved wrong by a test, but it can’t be proved right.

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Youth never knows heaven and earth

Conceit and talent are everywhere you look

Pretentious as it is

I was honest

I love such a boy

Humble and arrogant

Proud and calm ☀️

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Your likes and attention are my constant motivation, you can add my wechat: HancAO97, invite you to join the group, learn and communicate together, become a better front-end engineer ~