There Are Exactly Three Paradigms [Link]
ThereAreExactlyThreeParadigms
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
1 of 6 26/10/2022, 10:24
There Are Exactly Three Paradigms [Link]
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
2 of 6 26/10/2022, 10:24
There Are Exactly Three Paradigms [Link]
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 [Link] (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
3 of 6 26/10/2022, 10:24
There Are Exactly Three Paradigms [Link]
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
4 of 6 26/10/2022, 10:24
There Are Exactly Three Paradigms [Link]
"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
5 of 6 26/10/2022, 10:24
There Are Exactly Three Paradigms [Link]
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
See also WhatIsaParadigm, ProgrammingParadigm
CategoryMultiparadigm
Last edit December 26, 2013
6 of 6 26/10/2022, 10:24
