See http://en.wikipedia.org/wiki/Procedural_programming. ---- A ProgrammingParadigm characterized by: * use of procedures and functions for control abstraction. Usually, these are second-class (a fixed set of procedures/functions, bound to a fixed set of environments, is specified for the program). ** Please clarify this "fixed" nature. ** Code rarely, if it's even ''possible'' to begin with, synthesizes new procedures at runtime. For example, a purely procedural software blitter will have a rigidly defined control-flow for manipulating graphics; meanwhile, something not quite so "procedural" might optimize the software blitter by dynamically synthesizing a machine language procedure to perform the blit operation via dynamic allocation of a chunk of code space and populating it with the appropriate CPU opcodes to get the job done (e.g., a JIT compiler for blitting). * Simple control flow constructs, such as loop, if/then/else, and case statements. Things like ContinuationsAndCoroutines, exceptions, or FirstClassContinuations are generally not found in ProceduralLanguage''''''s. GoTo may be present; but it's use is discouraged, and it is generally limited to intra-function use. ** These issues are generally orthogonal to paradigms. ** ''Not necessarily... Can a functional program contain a GoTo?'' * Simple data types, including basic algebraic types (records and arrays). May have AbstractDataType''''''s or modules for abstraction. Inheritance/subtyping are generally not found. * Other than limited cases (such as the ability of pointers and arrays to range over a base type), limited PolyMorphism. Generics are not common. SubtypePolymorphism (a hallmark of ObjectOrientedProgramming) is not found. ** Generics is probably orthogonal also. * Programming model is very focused on SideEffect''''''s--a common definition of a ''procedure'' is a subprogram which is evaluated for its side effects, rather than its explicit result. * While not a requirement of the procedural model, most procedural languages do not have automatic GarbageCollection of any sort. The main exceptions to this rule are the early pre-OO ScriptingLanguages (BourneShell, early PerlLanguage). '''As opposed to OOP:''' * Procedural programming lacks such things as inheritance and subtyping. Many procedural languages (like CeeLanguage) lack any linguistic mechanisms for encapsulation or modular design; other procedural languages (ModulaTwo, early dialects of AdaLanguage) do support these things. ** We need a more robust definition of "modular" to evaluate this. ** ''Not really. We need only to recognize that many procedural languages (like CeeLanguage) lack any '''explicit''' (i.e. "linguistic") mechanisms aimed at supporting encapsulation or modular design. What little modularity CeeLanguage has comes entirely from non-standard extralanguage features provided by the linker and the runtime dynamic link-loader.'' ** What C lacks is what C lacks. That is NOT an inherent "procedural" feature. For example, some languages have name-spaces, which are not OOP-related. Having these are not having these does not "procedural" make. ** ''Language-supported objects themselves constitute 'linguistic mechanisms for encapsulation or modular design'. So '''every''' OOP language has these, which is why (I imagine) it was considered a relevant comparison (i.e. OOP must have feature E, procedural languages do not need to have feature E and many procedural languages do not, in fact, support feature E). It is true that procedural languages also 'may' support modules (and some, like Pascal, have explicit ModuleSystem''''''s), but this is an 'extra' for procedural.'' ** But that's mostly a naming issue. We could package language features A, B, F, and W together and call it "Fipple Programming". Or Procedural++. ** {''Modular design in C is usually done with underscore prefixed words. Namespaces in C can be emulated by using naming schemes such as mysql_somefunc() where mysql_ is the namespace (prefixed word), and somefunc is the function name. This leads to verbose hideous repetitious code, since one must type mysql_ in front of every mysql related function.''} ** I'm not sure how this relates to the above. There are multiple approaches to managing modularity and name-spaces. The above is just one. When I said "package features together", I meant as part of a definition, not an actual programming code set. ** ''It was claimed above that C lacks modularity, but the underscore in C allows one to make their functions more modular than if no underscore existed. It's a small language feature, but it still is something. C has include files which are like modules too, and this is more modular than standard pascal, which had no include files and forced you to put all your code in one single file (yuck). If you use underscores and prefixes like mysql_somefunc() and you put functions in include files, this is modular design, although not as modular as a language like modula. The claim that Cee lacks modular features is actually partially false, and it very much relates to the above despite your rude arrogant idiotic claim that it doesn't relate to the above.'' ** Okay, I'm clear now. Thanks. I thought you were implying that non-OOP only offers very limited modularity. '''As opposed to FunctionalProgramming:''' * Procedures and functions are decidedly second-class; in some languages they are third-class. * Programming culture encourages SideEffect''''''s. ** Please clarify. ** The state wasn't always explicitly passed, much of was globalised before the current vogue of refactoring. The culture was to write poorly factored code, but this doesn't mean you can't write elegant, side-effect free procedural code. ---- ''Some of the wording above makes procedural sound outdated or inferior. However, I find that it complements databases and relational technology well. For example, one uses schemas instead of "complex types". -- top'' Why couldn't the schema contain complex types? For example a table that contains a column that stores polygons rather than just integers. The "instead of" attitude is what causes hostility between table dick heads and object oriented dick heads. Rather than "instead of" we should figure a way to merge the two technologies. {We have. It's TutorialDee with DateAndDarwensTypeSystem, and it's implemented in the RelProject.} ---- See also: ProceduralMethodologies