Category:Programming paradigm/Functional: Difference between revisions

Content added Content deleted

Inline

Revision as of 19:47, 17 August 2009

Functional programming treats functions as the fundamental first-class objects of the programming language. That has several consequences:

It's not possible to update variables (or other state) in a step-by-step fashion as in imperative programming.
Hence, all dependencies must be made explicit.
That leads to referential transparency -- given the same arguments, a piece of code will always behave identically.
Coding is compositional -- any two pieces of code with a matching 'interface', as specified by the type, can be combined, because no hidden side-effects can intervene. (See Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs by John Backus, 1977 Turing Award Lecture).
It's easy to refactor similar pieces of code, because any subexpression can be replaced by a variable bound at the outside.

This leads to a coding style which is very different from more traditional languages. Iteration is typically replaced by tail-recursion. Lists become a very important datatype. Code often consists of a composition of simpler blocks, which makes it look similar to declarative programming.

Most functional programming languages (FPLs) are related to the lambda calculus, which makes the specification of their formal semantics simpler.

One important characteristic of FPLs is their default evaluation order. Strict or eager FPLs will evaluate an argument as soon as possible, while lazy evaluation will do that as late as possible.

Strict FPLs often have an impure aspect that does allow functions with implicit side-effects, in order to interact with the (stateful) outside world. In non-strict FPLs, one uses monads or other means like uniqueness types to guarantee correct sequencing of side-effects.

With monads, one can also do imperative programming even in a purely functional languages, which is especially helpful if the notion of state is natural to the problem space.

Subcategories

This category has the following 96 subcategories, out of 96 total.

A

ACL2‎ (3 C, 96 P)
Acornsoft Lisp‎ (1 C, 17 P)
APL‎ (3 C, 310 P)
Arturo‎ (1 C, 779 P)
ATS‎ (3 C, 143 P)
Ayrch‎ (empty)

B

Binary Lambda Calculus‎ (50 P)
Blade‎ (5 P)
BQN‎ (1 C, 272 P)
Bruijn‎ (38 P)

C

C++‎ (3 C, 1,275 P)
Ceylon‎ (94 P)
Clio‎ (8 P)
Clojure‎ (3 C, 648 P)
Common Lisp‎ (3 C, 776 P)
Curry‎ (3 C, 8 P)

D

D‎ (3 C, 990 P)
DataWeave‎ (3 P)
Dylan‎ (3 C, 15 P)

E

EchoLisp‎ (303 P)
Ecstasy‎ (64 P)
Egison‎ (8 P)
Ela‎ (3 C, 66 P)
Elisa‎ (3 C, 7 P)
Elixir‎ (3 C, 538 P)
Elm‎ (1 C, 50 P)
Erlang‎ (3 C, 518 P)
Excel‎ (1 C, 75 P)

F

Falcon‎ (3 C, 35 P)
Fantom‎ (3 C, 150 P)
FormulaOne‎ (1 P)
Frege‎ (11 P)
Fōrmulæ‎ (1 C, 187 P)

G

Golo‎ (12 P)
Guile‎ (1 C, 1 P)

H

Haskell‎ (3 C, 1,172 P)
Hope‎ (3 C, 5 P)

I

Idris‎ (28 P)
Insitux‎ (1 C, 74 P)
Ioke‎ (3 C, 20 P)

J

J‎ (3 C, 1,413 P)
JavaScript‎ (3 C, 799 P)
Joy‎ (3 C, 90 P)
Jq‎ (2 C, 1,135 P)

K

Kitten‎ (3 P)

L

Lang5‎ (49 P)
Lean‎ (7 P)
Leon‎ (empty)
LFE‎ (1 C, 80 P)

M

M2000 Interpreter‎ (437 P)
Maclisp‎ (3 P)
Mathematica‎ (3 C, 1,206 P)
Mercury‎ (3 C, 127 P)
Miranda‎ (57 P)
MLite‎ (26 P)
Morfa‎ (9 P)

N

Nemerle‎ (3 C, 147 P)
NGS‎ (10 P)

O

Objeck‎ (3 C, 331 P)
OCaml‎ (3 C, 679 P)
Ol‎ (171 P)
Order‎ (3 C, 27 P)
Owl Lisp‎ (4 P)
Oz‎ (3 C, 278 P)

P

PARI/GP‎ (3 C, 606 P)
Perl‎ (6 C, 1,542 P)
Perl 6‎ (4 C)
PowerShell‎ (3 C, 500 P)
Pure‎ (3 C, 18 P)
Purity‎ (3 C, 4 P)

R

Racket‎ (3 C, 1,099 P)
Raku‎ (3 C, 1,619 P)
Rhovas‎ (6 P)
Roc‎ (2 P)
Ruby‎ (3 C, 1,236 P)
Rust‎ (2 C, 952 P)

S

Scala‎ (23 C, 950 P)
Scheme‎ (3 C, 425 P)
SequenceL‎ (1 C, 59 P)
Sidef‎ (1 C, 1,054 P)
SkookumScript‎ (1 C, 6 P)
Slope‎ (28 P)
Soda‎ (2 P)
Standard ML‎ (3 C, 301 P)

T

Thyrd‎ (3 C, 1 P)
Trith‎ (3 C, 21 P)
TXR‎ (3 C, 160 P)
Typed Racket‎ (1 C, 1 P)

U

Uiua‎ (1 C, 30 P)
Ultimate++‎ (5 P)
Unlambda‎ (3 C, 11 P)
Ursala‎ (3 C, 193 P)

V

Visual Prolog‎ (7 P)

W

Wart‎ (61 P)
Wortel‎ (43 P)

X

XQuery‎ (3 C, 15 P)

@@ Line 1: / Line 1: @@
+{{feature|Programming paradigm}}'''Functional programming''' treats functions as the fundamental first-class objects of the programming language. That has several consequences:
-{{feature|Programming paradigm}}{{stub}}
+* It's not possible to update variables (or other ''state'') in a step-by-step fashion as in [[imperative programming]].
+* Hence, all dependencies must be made explicit.
+* That leads to [http://www.haskell.org/haskellwiki/Referential_transparency referential transparency] -- given the same arguments, a piece of code will always behave identically.
+* Coding is '''compositional''' -- any two pieces of code with a matching 'interface', as specified by the type, can be combined, because no hidden side-effects can intervene. (See [http://www.stanford.edu/class/cs242/readings/backus.pdf ''Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs''] by John Backus, 1977 Turing Award Lecture).
+* It's easy to '''refactor''' similar pieces of code, because any subexpression can be replaced by a variable bound at the outside.
+This leads to a coding style which is very different from more traditional languages. [[Iteration]] is typically replaced by [[:Category:Recursion|tail-recursion]]. Lists become a very important datatype. Code often consists of a composition of simpler blocks, which makes it look similar to [[declarative programming]].
+Most functional programming languages (FPLs) are related to the [[wp:Lambda_Calculus|lambda calculus]], which makes the specification of their formal semantics simpler.
+One important characteristic of FPLs is their default evaluation order. ''Strict'' or ''eager'' FPLs will evaluate an argument as soon as possible, while [[lazy evaluation]] will do that as late as possible.
+Strict FPLs often have an ''impure'' aspect that does allow functions with implicit side-effects, in order to interact with the (stateful) outside world. In non-strict FPLs, one uses [[wp:Monads_in_functional_programming|monads]] or other means like uniqueness types to guarantee correct sequencing of side-effects.
+With monads, one can also do [[imperative programming]] even in a purely functional languages, which is especially helpful if the notion of state is natural to the problem space.