Imperative Programming Paradigm: Difference between revisions
Jump to navigation
Jump to search
m (Text replacement - "<ref name=":0" />" to "") |
m (Text replacement - ". " to ". ") |
||
| Line 22: | Line 22: | ||
=== 2014 === | === 2014 === | ||
* ([[2014_TheCurseoftheExcludedMiddle|Meijer, 2014]]) ⇒ [[Erik Meijer]]. ([[2014]]). “[http://cacm.acm.org/magazines/2014/6/175179-the-curse-of-the-excluded-middle/ The Curse of the Excluded Middle]].” In: Queue Journal, 12(4). [http://dx.doi.org/10.1145/2611429.2611829 doi:10.1145/2611429.2611829] | * ([[2014_TheCurseoftheExcludedMiddle|Meijer, 2014]]) ⇒ [[Erik Meijer]]. ([[2014]]). “[http://cacm.acm.org/magazines/2014/6/175179-the-curse-of-the-excluded-middle/ The Curse of the Excluded Middle]].” In: Queue Journal, 12(4). [http://dx.doi.org/10.1145/2611429.2611829 doi:10.1145/2611429.2611829] | ||
** QUOTE: [[Imperative program]]s describe [[computation operation|computation]]s by repeatedly performing [[implicit effect]]s on a [[shared state|shared]] [[global state]]. In a [[parallel/concurrent/distributed world]], however, a [[single global state]] is an unacceptable [[bottleneck]], so the foundational assumption of [[Imperative Programming Paradigm|imperative programming]] that underpins most [[contemporary programming language]]s is starting to crumble. Contrary to popular belief, making [[state variable]]s [[immutable variable|immutable]] comes nowhere close to eliminating unacceptable [[implicit imperative effect]]s. [[Computation Operation|Operation]]s as ordinary as [[exception operation\exception]]s, [[threading operation|threading]], and [[I/O operation|I/O]] cause as much hardship as simple mutable state. … <P> … Pure [[functional programming]] is [[programming paradigm|programming]] with [[mathematical function]]s. This means the only way to express dependencies among values is by applying functions to arguments and harvesting values returned. Calling a function with the same arguments will return the same result every time. | ** QUOTE: [[Imperative program]]s describe [[computation operation|computation]]s by repeatedly performing [[implicit effect]]s on a [[shared state|shared]] [[global state]]. In a [[parallel/concurrent/distributed world]], however, a [[single global state]] is an unacceptable [[bottleneck]], so the foundational assumption of [[Imperative Programming Paradigm|imperative programming]] that underpins most [[contemporary programming language]]s is starting to crumble. Contrary to popular belief, making [[state variable]]s [[immutable variable|immutable]] comes nowhere close to eliminating unacceptable [[implicit imperative effect]]s. [[Computation Operation|Operation]]s as ordinary as [[exception operation\exception]]s, [[threading operation|threading]], and [[I/O operation|I/O]] cause as much hardship as simple mutable state. … <P> … Pure [[functional programming]] is [[programming paradigm|programming]] with [[mathematical function]]s. This means the only way to express dependencies among values is by applying functions to arguments and harvesting values returned. Calling a function with the same arguments will return the same result every time. | ||
=== 1999 === | === 1999 === | ||
Revision as of 12:23, 2 August 2022
An Imperative Programming Paradigm is a programming paradigm that describe computations by repeatedly performing implicit effects on a shared global state.
- AKA> Procedural Programming.
- Context:
- It can be associated with an Imperative Programming Program/Imperative Software Program (imperative programming code using an imperative programming language).
- Example(s):
- …
- Counter-Example(s):
- See: Imperative Programming Language, Procedural Programming.
References
2017
- (Wikipedia, 2017) ⇒ https://en.wikipedia.org/wiki/procedural_programming Retrieved:2017-3-31.
- Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions (not to be confused with mathematical functions, but similar to those used in functional programming), simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself. The first major procedural programming languages first appeared circa 1960, including Fortran, ALGOL, COBOL and BASIC. Pascal and C were published closer to the 1970s, while Ada was released in 1980. Go is an example of a more modern procedural language, first published in 2009.
Computer processors provide hardware support for procedural programming through a stack register and instructions for calling procedures and returning from them. Hardware support for other types of programming is possible, but no attempt was commercially successful (for example Lisp machines or Java processors).
- Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions (not to be confused with mathematical functions, but similar to those used in functional programming), simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself. The first major procedural programming languages first appeared circa 1960, including Fortran, ALGOL, COBOL and BASIC. Pascal and C were published closer to the 1970s, while Ada was released in 1980. Go is an example of a more modern procedural language, first published in 2009.
2014
- (Meijer, 2014) ⇒ Erik Meijer. (2014). “The Curse of the Excluded Middle].” In: Queue Journal, 12(4). doi:10.1145/2611429.2611829
- QUOTE: Imperative programs describe computations by repeatedly performing implicit effects on a shared global state. In a parallel/concurrent/distributed world, however, a single global state is an unacceptable bottleneck, so the foundational assumption of imperative programming that underpins most contemporary programming languages is starting to crumble. Contrary to popular belief, making state variables immutable comes nowhere close to eliminating unacceptable implicit imperative effects. Operations as ordinary as exception operation\exceptions, threading, and I/O cause as much hardship as simple mutable state. …
… Pure functional programming is programming with mathematical functions. This means the only way to express dependencies among values is by applying functions to arguments and harvesting values returned. Calling a function with the same arguments will return the same result every time.
- QUOTE: Imperative programs describe computations by repeatedly performing implicit effects on a shared global state. In a parallel/concurrent/distributed world, however, a single global state is an unacceptable bottleneck, so the foundational assumption of imperative programming that underpins most contemporary programming languages is starting to crumble. Contrary to popular belief, making state variables immutable comes nowhere close to eliminating unacceptable implicit imperative effects. Operations as ordinary as exception operation\exceptions, threading, and I/O cause as much hardship as simple mutable state. …
1999
- http://eprints.eemcs.utwente.nl/1077/03/introduction.html
- C functional random
int functional_random( int seed ) { return 22 * seed % 37 ; } - C using functional random
int first = functional_random( 1 ) ;
int second = functional_random( first ) ;
int third = functional_random( second ) ; - C imperative random
int seed = 1 ;
int imperative_random( void ) {
seed = 22 * seed % 37 ;
return seed ;}
- C functional random
1993
- http://caml.inria.fr/pub/docs/fpcl/fpcl-07.pdf
- The definition of a sum or product type may be annotated to allow physical (destructive) update on data structures of that type. This is the main feature of the imperative programming style. Writing values into memory locations is the fundamental mechanism of imperative languages such as Pascal. The Lisp language, while mostly functional, also provides the dangerous functions rplaca and rplacd to physically modify lists. Mutable structures are required to implement many efficient algorithms. They are also very convenient to represent the current state of a state machine.