par•a•digmnoun [LL paradigma, fr. Gk paradeigma, fr. paradeiknynai to show side by side, fr. para- + deiknynai to show — more at diction] (15c)
1: example, pattern; esp : an outstandingly clear or typical example or archetype
2: an example of a conjugation or declension showing a word in all its inflectional forms
3: a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated
Science historian Thomas Kuhn used this term in his influential book The Structure of Scientific Revolutions to describe a set of theories, standards, and methods that together represent a way of organizing knowledge, that is, a way of viewing the world.
Robert Floyd used the term in his 1979 ACM Turing Award lecture, "The Paradigms of Programming". A programming paradigm is a way of conceptualizing what it means to perform computation, of structuring and organizing how tasks are to be carried out on a computer.
Programming language is a notational system (linguistic framework) for describing computation in a machine and human readable form. Since a computation can be solved in different ways (paradigms), the language used to describe the solution differs in abstractions, structures due to the way in which the problem is solved. For example, in object-oriented paradigm, everything is considered as an object, and computation is performed by objects communicating with one another and requesting that other object to perform actions. Corresponding mechanisms in object-oriented languages to describe objects, inherit objects and pass message between objects are designed.
Now a question arise that since a language is designed (or evolved) to express objects in a certain way, can a language is more powerful than an other in computation is. Alonzo Church pronounced in a conjecture that any computation for which there exists an effective procedure can be realized by a Turing machine. In an other word, if a language is Turing complete, it is fundamentally equal in power to the other languages. So we can say that if one program can be solved in a given paradigm, it can also be solved in another. So the difference between languages may be how expressive to describe a computational process, what is the cost and how easy to use.
Programming paradigm and Software architecture
Programming languages focus on data structure and algorithm of the computation, while software architecture addresses the organization of components and the overall system. We can see some common styles of software architecture are also used in programming languages. Or probably we should say they are actually evolved from programming languages.
Diagram of Programming Paradigms
Imperative: characterized by variable assignment and sequential execution.
Declarative: focus on specifying what, reduce on how. No variable assignment and no sequential execution.
Concurrent: parallel programming.
To learn more than one programming paradigm is good for several reasons. An programmer fluent in several programming paradigm can freely pick up the tools suitable for solving the problem. The ideas of different paradigms may be applicable in a lot of areas even out of that paradigm. And it’s also essential for one to design some new programming paradigm.
Procedural Programming Languages
Procedural programming paradigm is the traditional model of computation. It describes the steps that modify and manipulate variable storage or memories. And the final result is stored in memory when program halts. This model closely matches the actual executions of computer and usually has high execution efficiency.
Since procedural languages are not particularly close to the way human solving problems, it is difficult to specifying problems especially when the problem is complicated. Procedural programs are hard to maintain and not easy to reuse the code. They normally need a lot of human effort to find solutions to problems. And once conditions change, programs are hard to modify and sometimes need to start from scratch. So this is human cost expensive paradigm.
Functional Programming Languages
Functional programming paradigms treat values as single entities. Unlike variables, values are never modified. Instead, values are transformed into new values. Computation of functional languages are performed largely through applying functions to values. And functions are treated as "first class" data value. Functions can be assigned to identifiers, passed as argument and returned as a result.
Functional programming is atemporal and referential transparent. Atemporal means functional program is not dependent on time. Since functional programs only apply functions once arguments are available and only before the result are used (lazy evaluation), it doesn't matter when and where values are evaluated. With a given set of arguments, a function always produce a certain of result no matter when and where the function is executed, this feature is called "referential transparency". Referential transparency makes functions more easy to manipulate.
Functional languages has deleted some valuable tools in other languages like "side effect". This makes languages pure functional and not have to deal with features not compatible with functional techniques. But it also loses some benefits to use different styles to make language more flexible.
Constraint Programming Languages
In constraint programming, a sequence of constraints are specified that must be maintained during program execution. An underlying constraints satisfactory mechanism will assure the constraints. For example, given the statement C = (F - 32)x5/9 which defines a conversion between Fahrenheit degree and Celsius degree. Give either C or F, the other can be computed to maintain the constraint. So one program here can be used to solve at least two different problems. The descriptive nature of constraint languages makes it easy to describe problems. But don't expect the constraint-satisfaction system can them solve the problem automatically. Constraint language are not general problem solver. They tend to be more specific rather than general.
And constraint satisfaction systems are difficult to implement and less efficient.