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

where the value of an expression is computed, usually close to the lambda calculus.
or to put it differently: where the fundamental operation is reduction (of applicative terms).

ImperativeProgramming

where cells in some sort of memory are filled and overwritten with values. Inspired by the TuringMachine and curiously never mentioned in the above table (or to put it differently: where the fundamental operation is assignment.)
Actually, this generalizes to the fundamental operation being communication. The common case is simply communication to a cell maintained by some memory service (you send either a 'set' or a 'get', or possibly an 'apply-function' as needed for atomic ops or fast XOR processing). The more general case can consist of sends and receives on a fully networked, distributed model.
- Actually, this "generalization" sound much more like the ActorsModel, which is no where near ImperativeProgramming, actually the actor model is much more similar to FunctionalProgramming than it is to imperative programming.

LogicProgramming (and ConstraintProgramming)

where a solution to a set of logic formulas is sought; very declarative and incorporating some sort of search strategy like backtracking.
or to put it differently: where the fundamental operation is satisfaction of a predicate.
ConstraintProgramming envelopes LogicProgramming, since any logic domain can be expressed in terms of a constraint system, but the inverse is not often easy to express (due to the more strictly typed variables in LogicProgramming). However, the fields are disparate enough to have been split into LogicProgramming, ConstraintProgramming, and ConstraintLogicProgramming. (ConstraintAndLogicProgramming). This sort of programming is also called 'DeclarativeProgramming', but the word 'declarative' is somewhat overloaded.

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

Where a solution to a set of goals is sought through action; very declarative and incorporating some sort of search strategy like iterative planning with contingency
or, to put it differently: the fundamental operation is satisfaction of a goal (in terms of state or effect)

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 http://www.info.ucl.ac.be/~pvr/paradigms.html (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.

--top

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.

I meant belonging to different groups from each other, NOT that YagNi itself was a classification system.
- [What? A classification is a different group - it is in the dictionary, that a "type" is a unique group or classification.]
You still make no sense. Of which 'groups' do you speak? Both "You ain't gonna need it" and "Functional programming is defined mentioning only value reductions and thus doesn't admit to communication and therefore cannot possibly have side-effects in any pure form" are in the group described "Phrases Written in a Reasonable Approximation to English", if that is what you mean.
- [The only problem is that a program is a side effect if it does anything useful, such as, printing to the screen, modifying a database, writing graphics.]
- Indeed. Pure functional programs don't 'do' anything useful except tell the computer how to take one value and produce another. In fact, they don't 'do' anything at all, by themselves. But you can hand a functional program to an agent (e.g. interpreter or compiler) that uses it to calculate a value where said result represents a procedure to then execute. That's essentially what Haskell does with its 'main' function attached to the 'IO' monad.
- [In many hello world programs, I see functional programs printing to the screen.. which isn't functional programming. Surely Paul Grahams programs ended up having a side effect on the customer.. printing a shopping cart.]
- Not all 'functional' languages are purely functional; Haskell is one of few, and it uses those special semantics for 'main' and the IO monad. That said, I long ago came to the conclusion that 'pure functional' is not a good thing for the whole of a language because people - programmers - don't think in that manner. And 'impure functional' is even worse because you lose most of the benefits of functional programming. Thus, a better way to use 'functional' programming paradigm is as part of SeparateIoFromCalculation: utilize procedural (imperative) as pure IO and functional as pure calculation, and interleave them. Then add a dash of EventDrivenProgramming, cook at 350F for five or six years, and season to taste.
  - "That said, I long ago came to the conclusion that 'pure functional' is not a good thing for the whole of a language because people - programmers - don't think in that manner." [MostNaturalParadigm] People--programmers--think in whatever manner they've learned to think in. Because of the arbitrary choice of Von Neumann-style processors, programmers think in imperative programs. The best way to use the functional programming paradigm would be to find a way to do stuff like getting input and drawing to the screen in a functional way. Hint--that's not the IO monad.
  - I think I'll need more hints. Is it animal, vegetable, or mineral? Does it taste better with Tabasco? What are the concurrency primitives?
  - It seems to me that something like temporal/reactive functional programming is a good solution to this.
- [Agreed, and having some KombuchaTea (or green tea) while the project cooks, may help too]

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

AprilZeroEight

CategoryMultiparadigm