Programming paradigm

Robert Floyd used the term programming paradigm in his Turing Award speech in 1979, after Thomas Kuhl proposed the “revolution in science” paradigm. Programming paradigms generally have three aspects, taking OOP as an example:

1. Logical system of discipline — rule paradigm: such mechanisms as class/object, inheritance, dynamic binding, method rewriting, object replacement, etc.

2. Psychological Cognitive Factors — Psychological paradigms: According to Alan Kay, the father of object-oriented programming, “Computing is simulation”. The OO paradigm attaches great importance to the value of metaphor, which simulates nature in nature’s way through personification.

3. Natural view/world view — Conceptual paradigm: emphasizing the organization technology of programs, viewing programs as a combination of loosely coupled objects/classes, organizing classes into a hierarchy by inheritance mechanism, and viewing program operation as a dialogue between objects that serve each other.

Simply put, a programming paradigm is the programmer’s view of how a program should be, and represents the programmer’s view of how a program should be built and executed.

Common programming paradigms include imperative, procedural, declarative, object-oriented, functional, generic programming, etc.

Imperative – Imperative | | process type

BASIC COBOL C Ada FORTRAN

Scripted Perl, Python and PHP, which “glue together” separate programs developed in other languages as parts

Object-oriented Smalltalk C++ Java, will be built on the interaction of independent objects first. Each object has its own internal state and an executable subroutine that manages its state

The Declarative – indicates type | | Declarative

Functional Lisp ML Haskell, a program is considered an input-to-output function

Data Flow LD Val, the language views computing as a flow of information between some basic functional nodes. The node is triggered by the arrival of the input word and can operate concurrently

Logical Prolog, which tries to find values that satisfy certain relationships according to a set of logical rules

Template-based XSLT XML HTML,

One caveat: The programming paradigm is a way of categorizing programming languages and is not specific to any particular programming language. As far as programming languages are concerned, there are many programming paradigms that can be applied to one language.


Some programming languages are designed specifically for a particular paradigm, for example C is a procedural programming language; Smalltalk and Java are purer object-oriented programming languages; Haskell is a purely functional programming language. Other programming languages have a somewhat different relationship to programming paradigms, such as Python, Scala, and Groovy, which all support object-oriented and some degree of functional programming. C++ is a successful multi-paradigm programming language. C++ supports the same procedural programming paradigm as C language, and also supports object-oriented programming paradigm. STL (Standard Template Library) enables C++ to have generic programming capabilities. Support for multiple paradigms is probably one of the reasons C++ remains so strong today.

Swift is a typical multi-paradigm programming language that supports both object-oriented and functional programming paradigms, as well as generic programming. Swift supports multiple programming paradigms as determined by its creative goals. Swift was created to provide a useful industrial language. Unlike academic programming languages like Haskell, which come out of universities and research institutions. Apple launched Swift with a clear business purpose: It would give Apple developers a more modern programming language in objective-C, the primary programming language for Mac OS and iOS, and help the entire Apple ecosystem thrive.

Imperative programming:

The main idea of imperative programming is to focus on the steps the computer performs, telling the computer step by step what to do first and what to do next.

In essence, it is “von. Neumann machine “abstract operation mechanism, its programming way of thinking from the sequence of computer instructions.

(That is, procedural languages simulate the system construction of computer machines, not the individual abilities and tendencies of language users. We should be well aware of this point, such as the assembly language we used the first MCU.

Whether you use C, C++, C#, Java, Javascript, BASIC, Python, Ruby, etc., you can write in this way.

Program flow chart is an effective auxiliary means of programming in imperative language.

Imperative languages are particularly well suited to linear (or step-by-step) algorithmic problems. It emphasizes a “top-down” and “excelsior” design approach. This approach is very similar to the way we work and live, as our daily activities are carried out in a step-by-step order.

Imperative languages tend to develop programs that run faster and use system resources more efficiently. Imperative languages are flexible and powerful, and have many classic applications that allow programmers to use them to solve a variety of problems.

The disadvantage of imperative languages is that they are not suitable for solving certain kinds of problems, such as those that are unstructured and have complex algorithms. The problem is that imperative languages must specify an algorithm and include the order in which these instructions or statements are executed. In fact, it is extremely difficult to give detailed algorithms for unstructured problems with complex algorithms.

The most controversial and widely discussed areas are: unconditional branching, or GOTO statements, which are a part of most procedural programming languages. Opponents claim that goTO statements can be abused indefinitely; It provides opportunities for programming to create confusion. The current consensus is that it should be kept in most languages, and that its dangers should be minimized by procedural rules.

Imperative processing of actual things can generally be divided into the following two modes:

  • Process drive: similar to the general active polling in the work but also take the initiative to find work to do so have free time is completely wasted

    Using the alert type to polling, behavior depends on their own observation and judgment, is process-driven, in line with the pattern of conventional flow-driven Programming.

  • Event-driven: For example, the company has an OA system. When you finish your work, you only need to check whether the OA system has assigned you any work and whether you can do your own work without worrying about other unfinished work

    It is event-driven and conforms to the mode of event-driven programming (EDP).


Event-driven programming

Event-driven programming was used in programming long before the graphical user interface (GUI), but it was only when GUI became widespread that it gradually evolved into a widely used programming pattern.

In procedural programming, the code itself gives the order in which the program should be executed, although the order of execution may be affected by the input data to the program.

In event-driven programming, many parts of the program can be executed at completely unexpected moments. Often the execution of these programs is triggered by the user’s interaction with the program being executed.

  • Event: Notification that a particular event has occurred (randomly).

  • Events and polling: The act of polling is constantly observing and judging, and it is an endless way of doing things. And events are quietly waiting for things to happen. In fact, prior to The advent of Windows, PC applications using mouse-input character patterns had to do serial polling and in this way query and respond to different user actions.

  • Event handler: a piece of program code executed in response to an event. Event handlers enable programs to react to user actions.

Event-driven is often used for user – program interaction through graphical user interface (mouse, keyboard, touchpad) for interactive interaction. Of course, it can also be used for exception handling and responding to user-defined events, etc.

Exception handling of events is more complex than user interaction.

Event-driven is not limited to GUI programming applications. However, we also need to consider more practical issues to achieve event-driven, such as: event definition, event triggering, event transformation, event merging, event queuing, event dispatching, event processing, event joint and so on.

In fact, so far, we haven’t found a language or similar development environment for pure event-driven programming. All the information on event-driven is based on GUI events.

Event-driven programming languages include VB, C#, Java (Java Swing’s GUI), and so on. The vast majority of the events they involve are GUI events.

This programmatic paradigm requires programmers to look at each problem with a step-by-step algorithm. Obviously, not every problem lends itself to this procedural way of thinking. This has led to the emergence of other programming paradigms, including the object-oriented one we are introducing now.


From the development history of programming to talk about the emergence of object-oriented. When software was very simple, we only had to programmatically:

Define a function

Function one function two function three function four

Define the data

Data one, data two, data three, data four

Finally various functions, data operations.

As software develops, and our software gets bigger and bigger, with more code and more complexity than Hello World, we have trouble writing it: functions and data are defined too much, and we face two problems. First of all, there are naming conflicts. There are only so many English words, and there may be no suitable short words to use when writing the name. In order to avoid conflicts, we can only make the function name longer and longer. Then there is code duplication. We can use the function to call the method of the function, but the function to call the function (for example, a function with multiple methods (function), several functions mixed method) is not easy to maintain.


Object-oriented program

Object-oriented Programming OOP is a programming paradigm that supports object-oriented programming through classes, methods, objects, and message passing. An object is an instance of a class. It regards the object as the basic unit of the program and encapsulates the program and data to improve the reuse, flexibility and expansibility of the software. The program in the object can access and often modify the data related to the object. In object-oriented programming, programs are designed as objects related to each other.

Object-oriented programming can be regarded as the idea of including various independent and mutually calling objects in a program, which is the opposite of the traditional idea: the program is regarded as a collection of functions, or directly a series of instructions to the computer. Every object in object-oriented programming should be able to accept data, process data, and communicate data to other objects, so they can be thought of as a small “machine,” or object. That is, delegating the task to the best person to do it.

The most obvious analogy of the difference between object-oriented and process-oriented is the wag of a dog’s tail and the dog. The difference between wagging the tail ().

Three basic concepts of object-oriented programming:

  • Encapsulation, object-oriented programming hides the specific execution steps of a method and instead sends messages to it through a messaging mechanism. After deep thought, a good abstraction is made, giving a “complete and minimal” interface and allowing internal details to be hidden from the outside

  • Inheritance. In some cases, a class may have “subclasses.” Subclasses are more specific than their parent classes (called superclasses);

  • Polymorphism refers to the inheritance of related different classes, whose objects will make different responses to the same message;

Using an object-oriented programming language, it is easy to build software models. Because objects seem to be very easy to class and all things and concepts in the real world.

Object oriented through interfaces

  • Class. A class is a collection of similar objects. Birds of a feather flock together — illustration. Each object is an entity in its class. Objects in a class can accept the same message. In other words: a class contains and describes a group of objects that have “common characteristics (data elements) and common behavior (functionality).”

  • Interfaces. Every object has interfaces. An interface is not a class, but a set of specifications for classes that meet the requirements of the interface. Interfaces are methods that state what a class should do but do not specify how to do it. A class can have one or more interfaces.

  • Method, which determines what messages an object can receive. Object-oriented design can sometimes be reduced to simply “sending messages to objects.”


Object-oriented technology, on the one hand, draws on philosophical, psychological and biological ways of thinking; on the other hand, it is built on other programming technologies and is a natural product of previous programming ideas.

If structured software design is applying functional programming techniques to imperative languages for programming, object-oriented programming is just another approach to applying functional models to imperative programs, where modules evolve into objects and procedures shrink into class member methods. Many of the techniques of OOP — abstract data types, information hiding, interface and implementation separation, object generation capabilities, messaging mechanisms, and so on — are owned by structured software design or are found in other programming languages alone. But it is only in object-oriented languages that they appear together, collaborating and complementing each other in a uniquely collaborative way.


As can be seen from the above, if a car is designed with a process-oriented approach, the car manufacturer needs to purchase a large number of parts and then figure out how to debug and invoke the large number of parts to complete a function. However, if the object-oriented method is adopted to design cars, automobile manufacturers can outsource the design to professional brake system manufacturers, and they only need to agree which public methods to open and what to input and output.


Kevin Zou at Zhihu summarized three object-oriented approaches:

Static function package object

Encapsulate a group of functions that are functionally related into a class. The class can have no internal data at all, or it can have data. Configuration is transparent to a well-designed object. The function inside the object itself does not know that configuration exists. It only knows that every data it needs has been stored in this since its new. The nature of this object is that each of its functions (or methods) is read-only to this data, so it doesn’t change its state regardless of whether or not the method is called, by whom, or how many times it is called.

Domain model object

This concept is in contrast to the traditional database-oriented system analysis and design. Databases describe a complex world with only foreign keys, but the difficulty of software development is to adapt to change and be able to modify it safely. The relationship model seems simple, but it is like a spider’s web, all the tables and columns are wrapped in a piece, affecting the whole body, so that you are treading on thin ice when modifying, if not careful, you will care for one thing and lose another, and bugs one after another. The encapsulation nature of OO solves this problem. Organize business data into separate objects so that their data can only be accessed by themselves. What is left to the outside world are basically interfaces (methods), and none of the data is exposed unless absolutely necessary. The outside world can only send messages to it, and it responds by modifying its own data. This object, in contrast to the first, must have data, and each of its functions exists to modify its own data. Each modification is coarse-grained, and the object is still in the Valid state after each modification. Recommended reading “Domain Model analysis”, “Domain model, Do you really understand?”

By the way: Domain-driven Design – anaemic model – Domain model – congestion model

Temporary objects

Other small objects used to solve the process of development, too many variables, too complex process and sorted out. These objects work together to accomplish a function that would normally take thousands of lines of procedural code. For example, now you want to connect to SQL Server to execute a query and get the results back. Do not use any class libraries and tools, all the steps themselves, such as protocol parsing, socket network connection, packet sending and receiving, etc. At this point, we use a function to complete the task from beginning to end, without first dividing up the objects with distinct responsibilities. It is much easier to let the objects cooperate to complete the task.


But programming practice shows that not everything being an object is a good thing. To take an example of a jump in Java, only objects can be passed as arguments to functions in Java (and of course the primitive primitive type). So in order to pass a function to another function, you need to wrap the function around an object, usually using an anonymous class, because that class has no other purpose than to make everything in Java happy with the object design.

Java has a pure object-oriented concept. From the beginning of its design, it hopes to model the world with pure object model which is the object of everything. But now Java is adding more and more non-objects. Closure is introduced to obtain the first-order function in functional programming. By introducing generics, parameterized types are obtained. This may imply that the world is so rich that modeling it using a single model will not work.


Declarative programming:

Declarative programming expresses the logic of program execution in the form of data structures. The idea is to tell the computer what to do, but not specify how to do it.

SQL statements are the most obvious examples of declarative programming, such as:

SELECT * FROM collection WHERE num > 5

In addition to SQL, HTML and CSS used in web programming are declarative programming.

One of the features of declarative programming is that it does not require the creation of variables to store data.

Another feature is that it does not contain loop control code such as for, while.

Functional programming and declarative programming are related because they share the same idea: focus on what to do, not how to do it. But functional programming is not limited to declarative programming.

Functional programming

Functional programming, also known as functional programming, is a programming paradigm that treats computer operations as functional operations and avoids the use of program states and mutable objects. Among them, lambda calculus is the most important foundation of the language. Furthermore, a function of the lambda calculus can accept functions as inputs (arguments) and outputs (outgoing values).

Functional programming is concerned with relationships between types (algebraic structures), imperative programming is concerned with steps to solve a problem. Lambda in functional programming can be thought of as a relationship between two types, an input type and an output type. Lambda calculus is to give a lambda expression a value of input type, then can get a value of output type, this is a calculation, the calculation process satisfies the -equivalence and – specification. And the idea of functional programming is how do you put this relationship together, and use mathematical constructionism to construct the program that you’re designing

Compared with imperative programming, functional programming emphasizes the results of program execution rather than the process of execution, advocating the use of several simple execution units to make the results of calculation gradually, and the derivation of complex operations layer by layer, rather than designing a complex execution process.


Imperative programming is an abstraction for computer hardware, with variables (corresponding to storage units), assignment statements (get, store instructions), expressions (memory references and arithmetic operations), and control statements (jump instructions). In short, an imperative program is a sequence of instructions on a Von Neumann machine.

Functional programming, on the other hand, is a mathematically oriented abstraction that describes computation as an expression evaluation. In a word, a functional program is an expression.

The most important feature of functional programming is “function first”, which means that a function can appear anywhere. For example, you can pass a function as an argument to another function, and you can also pass a function as a return value.

The nature of functional programming

The term function in functional programming does not refer to functions in computers (which are actually subroutines), but rather functions in exponentials, i.e. mappings of independent variables. That is, the value of a function depends only on the parameters of the function, not on other states. For example, SQRT (x) computes the square root of x, and as long as x doesn’t change, it doesn’t change whenever it’s called, how many times it’s called.

In functional languages, functions, as first-class citizens, can be defined anywhere, inside or outside a function, as arguments and return values to a function, and can be combined.

A variable in a purely functional programming language is not a variable in an imperative programming language, which is a unit of state, but a variable in algebra, which is the name of a value. Values of variables are immutable, which means that it is not possible to assign a value to a variable more than once, as is the case in imperative programming languages. For example, in imperative programming languages we write “x = x + 1”, the fact that it depends on mutable state is true for programmers, but false for mathematicians.

In functional languages, such as conditional statements, loop statements are not control statements in imperative programming languages, but syntactic sugar of functions. For example, in Scala, if else is not a statement but a ternary operator that returns a value.

Strictly functional programming means programming without mutable variables, assignments, loops, and other imperative control structures.

In theory, functional languages do not run on the machines of the von Neumann architecture, but by the λ calculus, by substituting variables for their values or expressions, functions for their expressions, and computing according to operators. The λ calculus was Turing’s complete displacement, but for the most part, functional programs were implemented by compiling instructions in machine language.


Features of functional programming

  • Functions are “first-class citizens” : functions take precedence, just like any other data type.

  • “Expression” only, not “statement” : A return value is obtained through the evaluation of an expression, rather than a statement changing a state.

  • No side effects: no contamination of variables, the same input always get the same data.

  • Immutability: As mentioned earlier, return a new value without modifying the variable.

Since the value of a variable is immutable, the operation on the value is not to modify the original value, but to modify the newly generated value, and the original value remains inconvenient.

Algorithms are generally defined as iterative and recursive.

Because variables are immutable, loops cannot be implemented in purely functional programming languages, because For loops use mutable state as counters, whereas While or DoWhile loops require mutable state as a condition For breaking out of the loop. The only way to solve iterative problems in functional languages is recursion, which makes functional programming heavily dependent on recursion.

Functional languages also include the following features:


  • Higher-order function: functions that take arguments or return values of functions. With higher-order functions, you can reduce the granularity of reuse to the functional level, which is lower than in object-oriented languages.

  • Partially Applied Functions: a function that Partially applies Functions receives a function with multiple parameters and returns a function that requires fewer parameters. Partial functions fix one or more arguments internally, and then return the new function, which receives the remaining arguments to complete the application of the function.

  • Currying: taking a function that takes more than one argument and returning a function that takes only one argument.

  • Closure: A Closure is a function that has access to a variable in the scope of another function. Closures have three features: 1. Closures are functions defined within functions. 2. Closures can access variables that contain functions. 3. Variables referenced by closures are not released even when the include function is finished executing. See Gossip Closures for details.


The benefits of functional programming

Since imperative programming languages can also implement higher-order functions in a manner similar to function Pointers, the main benefit of functional expressions is immutability. There is No mutable state, the function is Referential transparency and No Side Effect.

The function does not depend on the external state and does not modify the external state. The result of the function call does not depend on the time and location of the call. The code written in this way is easy to reason and not easy to make mistakes. This makes unit testing and debugging easier.

Due to the () between multiple threads do not share state, not cause resource contention (Race condition), also do not need to use the lock to protect mutable state, there would be no deadlock, so that we can better concurrency, especially under the symmetric multiprocessor (SMP) architecture to better use of multiple processors (nuclear) provide the ability of parallel processing.

I think the nice thing about functional programming is that you don’t have to worry about the damn this reference in JS

Functional programming languages also provide Lazy evaluation, also known as call-by-need, which does not evaluate an expression when it is assigned to a variable (or bound) but only when the variable is used for the first time. This improves performance by avoiding unnecessary evaluation.

Functional programming languages also typically provide powerful Pattern matching capabilities. Algebraic data types can be defined in functional programming languages, and new data types can be formed by combining existing data types. For example, case class is provided in Scala, and the values of Algebraic data types can be analyzed by pattern matching.

Functional programming is inherently attuned to unit testing (especially black-box testing) because FP focuses on inputs and outputs. In contrast with Java or C++, it is not enough to check the return value of a function: the code may modify external state values, so we also need to verify that these external state values are correct. In FP, you don’t need it at all.

Debug error detection because errors in FP programs do not depend on previously run unrelated code. In an instruction program, a bug may sometimes recur and sometimes not. Because these functions depend on some external state that needs to be modified by some special execution flow of code that has nothing to do with the bug. In FP this doesn’t happen at all: if a function returns an error, it always does, no matter what code you’ve run. And the whole program is function solitaire.

Recommended reading is Functional Programming for Dummies

Generic programming

Generic programming is another interesting topic. Generics provide a higher level of abstraction to the programming language, parameterized types. In other words, it abstracts the type information from an algorithm or class that is specific to a particular type. This abstraction is known as a Template in the C++ Standard Template Library (STL). STL demonstrated the power of generic programming and became a powerful weapon in C++ from its inception. In addition to C++, C#, Java, Haskell and other programming languages have introduced the concept of generics.


Generic programming is a slightly more local concept that deals only with how to deal with types more abstractly, parameterized types. This is not enough to support the core concepts of a language. We don’t hear about a programming language that is purely generic and has no other programming paradigm. But because generics don’t change the core of the programming language, most of the time they fit well into other ways of programming. Programming languages as diverse as C++, Scala, and Haskell support generics. Generic programming provides a higher level of abstraction, which means greater expressiveness. This is good wine for most programming languages.


In Swift, generics are widely used, and much of the Swift standard library is built from generic code. For example, Swift’s array and dictionary types are generic sets. Swift is full of examples.

Text link: talk about the programming paradigm – the thought behind the programming language – model design, domain design, software design, – zhou Army’s personal website, talk about the series are all moving bricks summary article, the article is not appropriate, please leave a message to inform, thank you!

Reference article:

Programming paradigm [programmer’s programming worldview]

Hannota – Solutions to various programming paradigms

Programming paradigms: Imperative, Declarative and Functional programming

The magic of lambda calculus of https://www.cnblogs.com/dragonpig/archive/2010/01/26/1657052.html

http://www.cnblogs.com/lisperl/archive/2011/11/20/2256165.html programming language paradigm

Lambda calculus learning www.cnblogs.com/kirohuji/p/…

Functional programming rambling cloud.tencent.com/developer/a…

This article is mostly the link text summary given in this article, if not, please leave a message to this site, inform, thank you!

Programming Paradigms again – The ideas behind programming languages