There Are Exactly Three Paradigms

Is paradigm the best word for this page? Perhaps not. A great deal of invective surrounds it. Perhaps Conceptual Foundation would be a better word. But let's keep that to the WhatIsaParadigm discussion. This page is about the big three.

One might also argue that ThereAreNoParadigms. This page opposes that concept because there are very clear, very definite mechanisms by which to categorize language or expression features.

These are the three classic programming paradigms:

FunctionalProgramming ImperativeProgramming LogicProgramming (and ConstraintProgramming) That's it! Everything else is built on one of these three paradigms (Functional, Imperative and Logic), while sometimes incorporating elements of the others.

The Missing Paradigm

The above three paradigms hit three quadrants of a two-axis system: (Evaluate vs. Execute) and (Mechanism vs. Consequent), where by 'Mechanism' you apply a straightforward set of rules to get from the expression to the result, and for 'Consequent' you express what you want in terms of the end result (e.g. 'values that satisfy this predicate') and apply some sort of search to get from the expression to the result. You might also use the word 'Declarative' to describe programming in terms of consequents (see DeclarativeProgramming), but that word is as heavily overloaded as 'paradigm'... e.g. ConceptsTechniquesAndModelsOfComputerProgramming uses 'declarative' to simply mean that you've declared a variable to have a value.

LogicProgramming (or ConstraintProgramming) falls in the 'Evaluate' 'Consequent' quadrant, whereas FunctionalProgramming falls in the 'Evaluate' 'Mechanism' quadrant. ImperativeProgramming falls in the 'Execute' 'Mechanism' quadrant.

The Missing Paradigm: GoalBasedProgramming (possibly DeclarativeMetaprogramming) -- the 'Execute' 'Consequent' quadrant This hasn't yet become a common programming paradigm... and will not before we make considerable advance in Artificial Intelligence. AI is required for the broader uses because, unlike with searches for values (which are things that can be 'imagined' or 'considered' with only computational side-effects (heat, power, energy, time, money)), it is incredibly inefficient and often dangerous to perform the equivalent of a brute-force approach and try every possible solution to a problem, especially when the problem itself might change as a consequence of said attempts. Of course, since this IS 'The Missing Paradigm', it's still correct to say that there are only three classic paradigms.

There are, however, some approaches to programming that seem to be edging towards it, such as those where communications are implicitly maintained and performed based on a goal of having a particular value (e.g. FunctionalReactiveProgramming).

I'm not confident that there aren't more orthogonal axes by which we can divide language properties. Any particular expression will be in terms of (Evaluate/Execute) and (Mechanism/Consequent) of course, but there may be others. Perhaps there really should be 8 paradigms and we're missing some 'higher level' for the four listed above simply because we've never thought of it. I would say that a language orientation (what the language is designed to make very easy) isn't a true paradigm. Nor is a model a paradigm. However, these words are sometimes used in cases that might be worth considering for a paradigm in the sense seen above... e.g. if expressions in many parts of the code can affect one value, perhaps that should be the opposite of 'declarative', where one value is declared and affects many others... but we call it AspectOriented. MetaProgramming deserves mention, too, though it will ultimately fall in a paradigm too.

See (by Peter Van Roy, CTM co-author), which follows the basic Imperative/Functional/Constraint split, but also identifies sub-paradigms based on the addition of features like concurrency, laziness and choice (non-determinism), and identifies exemplar languages for each sub-paradigm. It also mentions TypeSystems, AspectOriented-ness and MetaProgramming as axes of classification orthogonal to the classification.

[lots of invective that is essentially written in duplicate on WhatIsaParadigm has been snipped. Suggestions on hierarchy for ProgrammingParadigm snipped, since it has already been accomplished]

The page of ProgrammingParadigms uses the word 'Paradigm' in a broader sense. The vast majority of the listed paradigms are more orientations or focuses regarding language support, and perhaps involve languages that support two or more of the above classic paradigms. There are certainly meaningful distinctions to be made on languages that are disparate from the three paradigms listed above (e.g. regarding types and support for distribution or concurrency or handling massive collections). Reading through ProgrammingParadigms should reveal some of these distinctions that the community finds especially important.

I don't know if it is a "paradigm", but there are often debates about "organic versus pure".

I'm fairly certain that would qualify as a question of "methodology".

Purists like lots of predefined restrictions, such as type-checking, and tight-grouping and/or heavy classification/taxonomies of various items. Organic fans like to be able to dump things into sets or lists without defining up-front about what is to go there. Organics feel that most abstractions are not reliable or lasting, and thus prefer looser flexible abstractions; while purists say that tight abstractions are both possible and protect against "bad things". There's also the view that the style should depend upon specific needs of an app or company.

Purists generally have made the observation that changing abstractions is much easier when there is a clear place to go into the code and tweak it. Therefore, the degree to which an abstraction is 'ephemeral' doesn't strike them as a concern.

This runs across (existing) paradigms. For example, in OOP we have Smalltalk versus Eiffle, and in databases we have DynamicRelational and semi-sparse tables versus heave constraint and type proponents who also want "thin tables" to better manage small groups of columns as sub-units below entity-level (FearOfAddingTables). Functional probably also has such sides.


Re: "I don't know if it is a paradigm ..."

It isn't.

It's an underlying BigIdea. "Paradigm" is ill-defined in my opinion.

It isn't a BigIdea either. A 'BigIdea' is 'YouAintGonnaNeedIt' or 'DoTheSimplestThingThatCouldPossiblyWork'. A BigIdea needs a name.

And "Paradigm" is very well-defined in the context of this page: it is defined by extension - there are exactly three paradigms, then it names them. You can't get much better defined than that.

Yes, but that is forced labeling/grouping in my opinion. Boundaries between all these are fuzzy.

Extensional definition is a perfectly legit form of definition, has been for long before you were born, and will continue to be long after you die - so having an opinion about whether it is 'forced' is entirely irrelevant. And the boundaries between the three paradigms above are not at all fuzzy. If they look blurry to you, I'm assuming it is because you've never understood them clearly.

At this stage, such terms are a kind of PrematureOptimization of vocab. Can you say with solid confidence that YagNi is a different kind of classification than the non-side-effects rule of functional? --top

YagNi is not a paradigm. It isn't a 'classification', either (what would YagNi classify?). It is, however, is a BigIdea - a motivating force (or meme) that has influenced and will continue to influence policy, design, and decision.

And silly, unjustifiable phrases like 'PrematureOptimization of vocab' are fine examples of how you insult people, unintentionally or otherwise, as you attempt to explain your own barely-formed ideas and religiously defend your half-formed conceptions. Perhaps you'd appreciate someone who clearly doesn't comprehend the RelationalModel arrogantly strutting across the wiki and saying that 'relations' are fuzzy things indistinct from 'YagNi' and it's all just a PrematureOptimization of vocab anyway.

I apologize if you found it rude. It seemed mild to me, but I guess it didn't come across that way. As far as "barely formed", that is almost unavoidable when dealing with nebulous concepts or definitions to begin with.

Were you dealing with nebulous concepts or definitions, that would actually be a reasonably sane statement.

I don't necessarily agree with the 3-way classification given above, for it's too simplistic and has a lot of gray areas and/or overlap. That being said, I doubt there is a perfect classification system because ProgrammingIsInTheMind and each mind classifies things differently. Thus, I tentatively accept the above 3 as a UsefulLie for discussion purposes and cannot present a superior alternative classification model at this time. (My first attempt was too complicated.) --top

What we see here is something like what in linear algebra is referred to as a "basis" of axis. Two vectors are defined, and then all vectors in the "language paradigm space" can map to those two vectors. If the space is really two dimensional and linear, then this is a perfect, simple representation. The way to disprove this hypothesis would be to find two paradigms which we know are rather different (far apart) yet map to the same or very similar vectors in this space. This indicates that there is at least one other dimension that is not covered by this set of axis, and that further refinement is needed. There is an important observation that comes from this view, in any case: There very well could be other axis systems that describe everything just as well. The argument that this is the best system because it is the most simple one is simply silly... it is just as much a combination of any other system where the same number of vectors are defined, and describe a space. In fact, if the two spaces are not identical, then that would disprove the hypothesis that this axis system accurately describes the full space of possible paradigms.
Contrast: ThereAreNoParadigms


See also WhatIsaParadigm, ProgrammingParadigm

View edit of December 26, 2013 or FindPage with title or text search