Programming paradigm
![]() |
Programming paradigms |
---|
|
Programming paradigms are a way of grouping programming languages based on what they do. Languages can be in more than one paradigm.
Some paradigms are focused on how the code is run, such as allowing side effects, or having to do things in a certain order. Other paradigms look at the way that code is organized, such as grouping code into one or two large pieces or a bunch of small pieces. Some other paradigms are instead focused on the syntax and grammar of the code.
There are two main categories of paradigms, imperative and declarative. A language can be both imperative and declarative.[1][2]
Imperative programming
In imperative programs, you give the computer a list of steps that need to be done in order to do something. If you wanted the computer to draw a cat face, you might give instructions such as "Draw a circle here, draw two smaller circles there, draw two triangles" and so on. Imperative programs often have a lot of side effects.
There are two major imperative paradigms, and it's very common to see both in the same language:
- Structured – The computer is given a series of structured steps. Steps like "go back to step 3" (known as "goto statements") are not allowed.
- Procedural – The computer is given a series of steps can be named, turning them into procedures. Most structured languages are also procedural.
- Object-Oriented – Code is organized into objects.
Declarative programming
In declarative paradigms, you tell the computer how to get something done. If you wanted the computer to draw a cat face, you might give instructions such as "Draw a face, draw two eyes, draw two ears" and so on.
The most well-known declarative paradigms are:[3]
- Functional – Most of the work is done by functions with no side effects.
- Logic – A series of facts are stated, and then one or more "questions" are asked.
- Event-based – Pieces of code are executed when certain events (such as mouse movement) are triggered.
Other paradigms
Some paradigms can be found in both imperative and declarative languages. These paradigms are usually found with one of the above paradigms instead of going on their own.
- Parallel: Multiple pieces of code are executed at the same time.
- Meta: Features let the programmer change the way the language itself acts.
Overview

Programming languages are grouped by paradigms in the same way that tools might be grouped by what they're used for.
A few languages fit neatly in one paradigm, such as:
- Smalltalk (object-oriented)
- Assembly (imperative, but not structured or object-oriented)
- Haskell (functional)
- Prolog (logic)
Most languages, though, are in more than one paradigm. Ones that stand out for having more than just one include:
- Scala (object-oriented, functional, parallel)
- Visual Basic (event-based, object-oriented)
- Common Lisp (procedural, functional, object oriented, meta)
- Scheme (functional, procedural, meta)
- Perl (functional, procedural, meta, object-oriented, event-based)
- Python (functional, object-oriented, procedural)
- Ruby (functional, object-oriented, procedural)
- Wolfram Language (functional, procedural, generally declarative)
- Oz (logic, functional, imperative, object-oriented)
- F# (functional, imperative, object-oriented, meta
Having more paradigms is not always good. For example, a function in a language that is only functional can sometimes do less work (such as only going over the parts of a list it actually needs to) than one in a language that is both object-oriented and functional.[6]
Many programming paradigms are well known for the techniques they do not allow as for those they do allow. One example is that functional languages that are only functional usually do not allow have side-effects.[6] Another example is that the biggest difference between structured programming and normal imperative programming is that the first one does not let the programmer use "goto statements" (statements telling the program to go to an earlier step). Because of this and other reasons, people often think new paradigms are too strict.[7] The rules aren't always a bad thing, though: they can help you avoid bugs, and let the computer make guesses that so it can run code faster or even check code for errors before the code runs!
Criticism
Some people who research programming languages do not like that paradigms are used to group programming languages, such as Harper[8] and Krishnamurthi.[9] Those people say that a lot of programming languages can't just be grouped in to paradigms because they borrow features and ideas from lots of paradigms.
History
New paradigms have been created over time, and people either pointed them out at the time, or when looking back. One of the first paradigms that was recognized as a new way of programming was structured programming from the 1960s. The idea of a "programming paradigm" is from 1978 if not earlier, in a lecture by Robert W. Floyd called The Paradigms of Programming. The word "paradigm" in the way Robert meant it was first used by Thomas Kuhn in his book, The Structure of Scientific Revolutions (1962).[10]
Machine code
The lowest-level (and oldest) programming paradigm is machine code [11] (an imperative paradigm). The instructions of machine code are just a sequence of numbers. Assembly language is a little bit less low-level (and a little bit less old). In assembly language, the machine instructions are represented by mnemonics (easier-to-remember names) and memory addresses can be given names. These are sometimes called first- and second-generation languages.
In the 1960s, assembly languages were developed to support library COPY, very advanced macros (bits of "special" code that got transformed to normal code before the program started running)[12], running procedures, and variables from outside the program. This let people re-use quite a bit of code, and avoid having to deal with hardware-specific problems thanks to commands like READ/WRITE/GET/PUT.
Assembly was, and sometimes still is, used in systems where it is important for the code to be fast, and it is also used a lot in embedded systems because it gives the most direct control of what the machine does.
Procedural languages
In the very late 1960s, people started inventing procedural languages. These third-generation languages (the first few of what we now call high-level languages) had words related to what they were trying to solve. For example,
- COmmon Business Oriented Language (COBOL) – uses words like file, move and copy.[13]
- FORmula TRANslation (FORTRAN) – uses mathematical words and symbols ( shapes used in writing and typing). It was developed mostly for science and engineering.
- ALGOrithmic Language (ALGOL) – made for writing algorithms (sets of steps telling the computer what to do). It uses mathematical words and symbols, just like FORTRAN.
- Programming Language One (PL/I) – was supposed to be useful to everyone.
- Beginners All purpose Symbolic Instruction Code (BASIC) – made to let people program even if they had never programmed before.
- C – a programming language made to be useful to everyone. Dennis Ritchie worked on it from 1969 to 1973 at AT&T Bell Labs.
Object-oriented programming
After many people had started using procedural languages, they invented object-oriented programming languages. In these languages, data and its "methods" (ways of manipulating the data) are put in one "object". Some programmers, such as Richard Stallman,[14] do not agree that object-oriented languages are better for explaining ideas to a computer than procedural languages.
Because object-oriented programming is a paradigm, not a language, people have made object oriented assembly languages like HLA (High Level Assembly).
Declarative paradigms
At the same time, declarative programming languages (languages where you tell the computer what to do, not how to do it) were being made. A language that is well known for being declarative is SQL (a language for adding and removing things from tables).
See also
Simple English Wikipedia does not use Portals at this time. Please remove this template. This template categorizes the page it is put on for cleanup to remove the template call.
References
- ↑ Michael A. Covington (2010-08-23). "CSCI/ARTI 4540/6540: First Lecture on Symbolic Programming and LISP" (PDF). University of Georgia. Archived from the original (PDF) on 2012-03-07. Retrieved 2013-11-20.
{{cite web}}
: Unknown parameter|dead-url=
ignored (|url-status=
suggested) (help) - ↑ Nørmark, Kurt. Overview of the four main programming paradigms. Aalborg University, 9 May 2011. Retrieved 22 September 2012.
- ↑ Frans Coenen (1999-10-11). "Characteristics of declarative programming languages". cgi.csc.liv.ac.uk. Retrieved 2014-02-20.
- ↑ Peter Van Roy (2009-05-12). "Programming Paradigms for Dummies: What Every Programmer Should Know" (PDF). info.ucl.ac.be. Retrieved 2014-01-27.
- ↑ Peter Van-Roy; Seif Haridi (2004). Concepts, Techniques, and Models of Computer Programming. MIT Press. ISBN 978-0-262-22069-9.
- ↑ 6.0 6.1 Hudak, Paul (September 1989). "Conception, Evolution, and Application of Functional Programming Languages". ACM Digital Library.
{{cite web}}
: Cite has empty unknown parameter:|dead-url=
(help) - ↑ Frank Rubin (March 1987). "'GOTO Considered Harmful' Considered Harmful" (PDF). Communications of the ACM. 30 (3): 195–196. doi:10.1145/214748.315722. Archived from the original (PDF) on March 20, 2009.
{{cite journal}}
: Unknown parameter|deadurl=
ignored (|url-status=
suggested) (help) - ↑ Harper, Robert (1 May 2017). "What, if anything, is a programming-paradigm?". FifteenEightyFour. Cambridge University Press.
- ↑ Krishnamurthi, Shriram (November 2008). "Teaching programming languages in a post-linnaean age". SIGPLAN. ACM. pp. 81–83. Not. 43, 11..
- ↑ Floyd, R. W. (1979). "The paradigms of programming". Communications of the ACM. 22 (8): 455. doi:10.1145/359138.359140.
- ↑ "Computer science - Programming languages". Encyclopedia Britannica. Retrieved 2018-12-29.
- ↑ Maurer, Ward (May 14, 1969). "The compiled macro assembler" (PDF). AFIPS Spring Joint Computing Conference.
- ↑ Mackinson, Thomas N. (1961-08-01). "COBOL: a sample problem". Communications of the ACM. 4 (8): 340–346. doi:10.1145/366678.366687. ISSN 0001-0782.
- ↑ "Mode inheritance, cloning, hooks & OOP (Google Groups Discussion)".
External links
