This is the classical
ProgrammingParadigm (and
ThereAreExactlyThreeParadigms) where some sort of "memory" is assumed and the most primitive operations are reading and writing cells of memory. Contrast this with
FunctionalProgramming, where the emphasis is placed not on the underlying machinery of the computation, but rather, on the computation itself (the most primitive operation being the application of a function to its parameter(s)), making explicit all inputs and outputs, so as to maintain
ReferentialTransparency.
ImperativeProgramming is the underlying paradigm of many (most?) classic computing machines: the
TuringMachine, the
VonNeumannMachine and
GotoPrograms are all variants of it, but
LambdaCalculus and
CombinatorialLogics are not.
ImperativeProgramming is often called
ProceduralProgramming (the latter might be even more common), because the primitive operation is the procedure, which has an effect on the state of the world (as opposed to the function, which has no effect but calculates a return value). However, a "procedure" is also a subprogram, the principal mechanism of abstraction in all but the most primitive imperative programming languages. So
ProceduralProgramming can easily be misinterpreted as "the not-quite-paradigm where a complex program is decomposed into procedures", which untimately leads to the stunning profusion of structuring disciplines layered
on top of the basic paradigms that can be found under
ProgrammingParadigms.
See also:
WhatIsaParadigm,
FunctionalProgramming,
LogicProgramming