Category:Programming paradigm/Functional: Difference between revisions

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}}'''Functional programming''' treats functions as the fundamental first-class objects of the programming language. In addition:

* ~~It's~~ ~~not~~ ~~possible~~ to ~~update~~ ~~variables~~ ~~(or~~ ~~other~~ ~~''state'')~~ in a ~~step-by-step~~ ~~fashion~~ as in [[imperative programming]].

# State changes are encapsulated in function results, in this paradigm, rather than in side effects, as in [[imperative programming]]

* ~~Hence,~~ ~~all~~ dependencies ~~must be made~~ explicit.

# This makes dependencies 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.

# This 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).

# Coding is '''compositional''' -- any two pieces of code with a matching 'interface', as specified by function domains, 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.

# 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]].

This leads to a coding style which is very different from more traditional languages. [[Iteration]] may be replaced by [[:Category:Recursion|tail-recursion]] or delegated to other functions. 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.