Imperative Programming

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.