Functional programming

From Wikipedia for FEVERv2
Jump to navigation Jump to search

For subroutine-oriented programming, see Procedural programming. Functional programming_sentence_0

In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. Functional programming_sentence_1

It is a declarative programming paradigm in which function definitions are trees of expressions that each return a value, rather than a sequence of imperative statements which change the state of the program. Functional programming_sentence_2

In functional programming, functions are treated as first-class citizens, meaning that they can be bound to names (including local identifiers), passed as arguments, and returned from other functions, just as any other data type can. Functional programming_sentence_3

This allows programs to be written in a declarative and composable style, where small functions are combined in a modular manner. Functional programming_sentence_4

Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions. Functional programming_sentence_5

When a pure function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects. Functional programming_sentence_6

This is in contrast with impure procedures, common in imperative programming, which can have side effects (such as modifying the program's state or taking input from a user). Functional programming_sentence_7

Proponents of purely functional programming claim that by restricting side effects, programs can have fewer bugs, be easier to debug and test, and be more suited to formal verification. Functional programming_sentence_8

Functional programming has its roots in academia, evolving from the lambda calculus, a formal system of computation based only on functions. Functional programming_sentence_9

Functional programming has historically been less popular than imperative programming, but many functional languages are seeing use today in industry and education, including Common Lisp, Scheme, Clojure, Wolfram Language, Racket, Erlang, OCaml, Haskell, and F#. Functional programming_sentence_10

Functional programming is also key to some languages that have found success in specific domains, like R in statistics, J, K and Q in financial analysis, and XQuery/XSLT for XML. Functional programming_sentence_11

Domain-specific declarative languages like SQL and Lex/Yacc use some elements of functional programming, such as not allowing mutable values. Functional programming_sentence_12

In addition, many other programming languages support programming in a functional style or have implemented features from functional programming, such as C++11, Kotlin, Perl, PHP, Python, Raku, and Scala. Functional programming_sentence_13

History Functional programming_section_0

The lambda calculus, developed in the 1930s by Alonzo Church, is a formal system of computation built from function application. Functional programming_sentence_14

In 1937 Alan Turing proved that the lambda calculus and Turing machines are equivalent models of computation, showing that the lambda calculus is Turing complete. Functional programming_sentence_15

Lambda calculus forms the basis of all functional programming languages. Functional programming_sentence_16

An equivalent theoretical formulation, combinatory logic, was developed by Moses Schönfinkel and Haskell Curry in the 1920s and 1930s. Functional programming_sentence_17

Church later developed a weaker system, the simply-typed lambda calculus, which extended the lambda calculus by assigning a type to all terms. Functional programming_sentence_18

This forms the basis for statically-typed functional programming. Functional programming_sentence_19

The first functional programming language, LISP, was developed in the late 1950s for the IBM 700/7000 series of scientific computers by John McCarthy while at Massachusetts Institute of Technology (MIT). Functional programming_sentence_20

LISP functions were defined using Church's lambda notation, extended with a label construct to allow recursive functions. Functional programming_sentence_21

Lisp first introduced many paradigmatic features of functional programming, though early Lisps were multi-paradigm languages, and incorporated support for numerous programming styles as new paradigms evolved. Functional programming_sentence_22

Later dialects, such as Scheme and Clojure, and offshoots such as Dylan and Julia, sought to simplify and rationalise Lisp around a cleanly functional core, while Common Lisp was designed to preserve and update the paradigmatic features of the numerous older dialects it replaced. Functional programming_sentence_23

Information Processing Language (IPL), 1956, is sometimes cited as the first computer-based functional programming language. Functional programming_sentence_24

It is an assembly-style language for manipulating lists of symbols. Functional programming_sentence_25

It does have a notion of generator, which amounts to a function that accepts a function as an argument, and, since it is an assembly-level language, code can be data, so IPL can be regarded as having higher-order functions. Functional programming_sentence_26

However, it relies heavily on the mutating list structure and similar imperative features. Functional programming_sentence_27

Kenneth E. Iverson developed APL in the early 1960s, described in his 1962 book A Programming Language (ISBN 9780471430148). Functional programming_sentence_28

APL was the primary influence on John Backus's FP. Functional programming_sentence_29

In the early 1990s, Iverson and Roger Hui created J. Functional programming_sentence_30

In the mid-1990s, Arthur Whitney, who had previously worked with Iverson, created K, which is used commercially in financial industries along with its descendant Q. Functional programming_sentence_31

John Backus presented FP in his 1977 Turing Award lecture "Can Programming Be Liberated From the von Neumann Style? Functional programming_sentence_32

A Functional Style and its Algebra of Programs". Functional programming_sentence_33

He defines functional programs as being built up in a hierarchical way by means of "combining forms" that allow an "algebra of programs"; in modern language, this means that functional programs follow the principle of compositionality. Functional programming_sentence_34

Backus's paper popularized research into functional programming, though it emphasized function-level programming rather than the lambda-calculus style now associated with functional programming. Functional programming_sentence_35

The 1973 language ML was created by Robin Milner at the University of Edinburgh, and David Turner developed the language SASL at the University of St Andrews. Functional programming_sentence_36

Also in Edinburgh in the 1970s, Burstall and Darlington developed the functional language NPL. Functional programming_sentence_37

NPL was based on Kleene Recursion Equations and was first introduced in their work on program transformation. Functional programming_sentence_38

Burstall, MacQueen and Sannella then incorporated the polymorphic type checking from ML to produce the language Hope. Functional programming_sentence_39

ML eventually developed into several dialects, the most common of which are now OCaml and Standard ML. Functional programming_sentence_40

In the 1970s, Guy L. Steele and Gerald Jay Sussman developed Scheme, as described in the Lambda Papers and the 1985 textbook Structure and Interpretation of Computer Programs. Functional programming_sentence_41

Scheme was the first dialect of lisp to use lexical scoping and to require tail-call optimization, features that encourage functional programming. Functional programming_sentence_42

In the 1980s, Per Martin-Löf developed intuitionistic type theory (also called constructive type theory), which associated functional programs with constructive proofs expressed as dependent types. Functional programming_sentence_43

This led to new approaches to interactive theorem proving and has influenced the development of subsequent functional programming languages. Functional programming_sentence_44

The lazy functional language, Miranda, developed by David Turner, initially appeared in 1985 and had a strong influence on Haskell. Functional programming_sentence_45

With Miranda being proprietary, Haskell began with a consensus in 1987 to form an open standard for functional programming research; implementation releases have been ongoing since 1990. Functional programming_sentence_46

More recently it has found use in niches such as parametric CAD courtesy of the OpenSCAD language built on the CSG geometry framework, although its restriction on reassigning values (all values are treated as constants) has led to confusion among users who are unfamiliar with functional programming as a concept. Functional programming_sentence_47

Functional programming continues to be used in commercial settings. Functional programming_sentence_48

Concepts Functional programming_section_1

A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object-oriented programming). Functional programming_sentence_49

However, programming languages often cater to several programming paradigms, so programmers using "mostly imperative" languages may have utilized some of these concepts. Functional programming_sentence_50

First-class and higher-order functions Functional programming_section_2

Main articles: First-class function and Higher-order function Functional programming_sentence_51

Higher-order functions are closely related to first-class functions in that higher-order functions and first-class functions both allow functions as arguments and results of other functions. Functional programming_sentence_52

The distinction between the two is subtle: "higher-order" describes a mathematical concept of functions that operate on other functions, while "first-class" is a computer science term for programming language entities that have no restriction on their use (thus first-class functions can appear anywhere in the program that other first-class entities like numbers can, including as arguments to other functions and as their return values). Functional programming_sentence_53

Higher-order functions enable partial application or currying, a technique that applies a function to its arguments one at a time, with each application returning a new function that accepts the next argument. Functional programming_sentence_54

This lets a programmer succinctly express, for example, the successor function as the addition operator partially applied to the natural number one. Functional programming_sentence_55

Pure functions Functional programming_section_3

Main article: Pure function Functional programming_sentence_56

Pure functions (or expressions) have no side effects (memory or I/O). Functional programming_sentence_57

This means that pure functions have several useful properties, many of which can be used to optimize the code: Functional programming_sentence_58

Functional programming_unordered_list_0

  • If the result of a pure expression is not used, it can be removed without affecting other expressions.Functional programming_item_0_0
  • If a pure function is called with arguments that cause no side-effects, the result is constant with respect to that argument list (sometimes called referential transparency), i.e., calling the pure function again with the same arguments returns the same result. (This can enable caching optimizations such as memoization.)Functional programming_item_0_1
  • If there is no data dependency between two pure expressions, their order can be reversed, or they can be performed in parallel and they cannot interfere with one another (in other terms, the evaluation of any pure expression is thread-safe).Functional programming_item_0_2
  • If the entire language does not allow side-effects, then any evaluation strategy can be used; this gives the compiler freedom to reorder or combine the evaluation of expressions in a program (for example, using deforestation).Functional programming_item_0_3

While most compilers for imperative programming languages detect pure functions and perform common-subexpression elimination for pure function calls, they cannot always do this for pre-compiled libraries, which generally do not expose this information, thus preventing optimizations that involve those external functions. Functional programming_sentence_59

Some compilers, such as gcc, add extra keywords for a programmer to explicitly mark external functions as pure, to enable such optimizations. Functional programming_sentence_60

Fortran 95 also lets functions be designated pure. Functional programming_sentence_61

C++11 added constexpr keyword with similar semantics. Functional programming_sentence_62

Recursion Functional programming_section_4

Main article: Recursion (computer science) Functional programming_sentence_63

Iteration (looping) in functional languages is usually accomplished via recursion. Functional programming_sentence_64

Recursive functions invoke themselves, letting an operation be repeated until it reaches the base case. Functional programming_sentence_65

In general, recursion requires maintaining a stack, which consumes space in a linear amount to the depth of recursion. Functional programming_sentence_66

This could make recursion prohibitively expensive to use instead of imperative loops. Functional programming_sentence_67

However, a special form of recursion known as tail recursion can be recognized and optimized by a compiler into the same code used to implement iteration in imperative languages. Functional programming_sentence_68

Tail recursion optimization can be implemented by transforming the program into continuation passing style during compiling, among other approaches. Functional programming_sentence_69

The Scheme language standard requires implementations to support proper tail recursion, meaning they must allow an unbounded number of active tail calls. Functional programming_sentence_70

Proper tail recursion is not simply an optimization; it is a language feature that assures users that they can use recursion to express a loop and doing so would be safe-for-space. Functional programming_sentence_71

Moreover, contrary to its name, it accounts for all tail calls, not just tail recursion. Functional programming_sentence_72

While proper tail recursion is usually implemented by turning code into imperative loops, implementations might implement it in other ways. Functional programming_sentence_73

For example, CHICKEN intentionally maintains a stack and lets the stack overflow. Functional programming_sentence_74

However, when this happens, its garbage collector will claim space back, allowing an unbounded number of active tail calls even though it does not turn tail recursion into a loop. Functional programming_sentence_75

Common patterns of recursion can be abstracted away using higher-order functions, with catamorphisms and anamorphisms (or "folds" and "unfolds") being the most obvious examples. Functional programming_sentence_76

Such recursion schemes play a role analogous to built-in control structures such as loops in imperative languages. Functional programming_sentence_77

Most general purpose functional programming languages allow unrestricted recursion and are Turing complete, which makes the halting problem undecidable, can cause unsoundness of equational reasoning, and generally requires the introduction of inconsistency into the logic expressed by the language's type system. Functional programming_sentence_78

Some special purpose languages such as Coq allow only well-founded recursion and are strongly normalizing (nonterminating computations can be expressed only with infinite streams of values called codata). Functional programming_sentence_79

As a consequence, these languages fail to be Turing complete and expressing certain functions in them is impossible, but they can still express a wide class of interesting computations while avoiding the problems introduced by unrestricted recursion. Functional programming_sentence_80

Functional programming limited to well-founded recursion with a few other constraints is called total functional programming. Functional programming_sentence_81

Strict versus non-strict evaluation Functional programming_section_5

Main article: Evaluation strategy Functional programming_sentence_82

Functional languages can be categorized by whether they use strict (eager) or non-strict (lazy) evaluation, concepts that refer to how function arguments are processed when an expression is being evaluated. Functional programming_sentence_83

The technical difference is in the denotational semantics of expressions containing failing or divergent computations. Functional programming_sentence_84

Under strict evaluation, the evaluation of any term containing a failing subterm fails. Functional programming_sentence_85

For example, the expression: Functional programming_sentence_86

fails under strict evaluation because of the division by zero in the third element of the list. Functional programming_sentence_87

Under lazy evaluation, the length function returns the value 4 (i.e., the number of items in the list), since evaluating it does not attempt to evaluate the terms making up the list. Functional programming_sentence_88

In brief, strict evaluation always fully evaluates function arguments before invoking the function. Functional programming_sentence_89

Lazy evaluation does not evaluate function arguments unless their values are required to evaluate the function call itself. Functional programming_sentence_90

The usual implementation strategy for lazy evaluation in functional languages is graph reduction. Functional programming_sentence_91

Lazy evaluation is used by default in several pure functional languages, including Miranda, Clean, and Haskell. Functional programming_sentence_92

argues for lazy evaluation as a mechanism for improving program modularity through separation of concerns, by easing independent implementation of producers and consumers of data streams. Functional programming_sentence_93

Launchbury 1993 describes some difficulties that lazy evaluation introduces, particularly in analyzing a program's storage requirements, and proposes an operational semantics to aid in such analysis. Functional programming_sentence_94

Harper 2009 proposes including both strict and lazy evaluation in the same language, using the language's type system to distinguish them. Functional programming_sentence_95

Type systems Functional programming_section_6

Main article: Type system Functional programming_sentence_96

Especially since the development of Hindley–Milner type inference in the 1970s, functional programming languages have tended to use typed lambda calculus, rejecting all invalid programs at compilation time and risking false positive errors, as opposed to the untyped lambda calculus, that accepts all valid programs at compilation time and risks false negative errors, used in Lisp and its variants (such as Scheme), though they reject all invalid programs at runtime when the information is enough to not reject valid programs. Functional programming_sentence_97

The use of algebraic datatypes makes manipulation of complex data structures convenient; the presence of strong compile-time type checking makes programs more reliable in absence of other reliability techniques like test-driven development, while type inference frees the programmer from the need to manually declare types to the compiler in most cases. Functional programming_sentence_98

Some research-oriented functional languages such as Coq, Agda, Cayenne, and Epigram are based on intuitionistic type theory, which lets types depend on terms. Functional programming_sentence_99

Such types are called dependent types. Functional programming_sentence_100

These type systems do not have decidable type inference and are difficult to understand and program with. Functional programming_sentence_101

But dependent types can express arbitrary propositions in higher-order logic. Functional programming_sentence_102

Through the Curry–Howard isomorphism, then, well-typed programs in these languages become a means of writing formal mathematical proofs from which a compiler can generate certified code. Functional programming_sentence_103

While these languages are mainly of interest in academic research (including in formalized mathematics), they have begun to be used in engineering as well. Functional programming_sentence_104

Compcert is a compiler for a subset of the C programming language that is written in Coq and formally verified. Functional programming_sentence_105

A limited form of dependent types called generalized algebraic data types (GADT's) can be implemented in a way that provides some of the benefits of dependently typed programming while avoiding most of its inconvenience. Functional programming_sentence_106

GADT's are available in the Glasgow Haskell Compiler, in OCaml (since version 4.00) and in Scala (as "case classes"), and have been proposed as additions to other languages including Java and C#. Functional programming_sentence_107

Referential transparency Functional programming_section_7

Main article: Referential transparency Functional programming_sentence_108

Functional programs do not have assignment statements, that is, the value of a variable in a functional program never changes once defined. Functional programming_sentence_109

This eliminates any chances of side effects because any variable can be replaced with its actual value at any point of execution. Functional programming_sentence_110

So, functional programs are referentially transparent. Functional programming_sentence_111

Consider C assignment statement x = x * 10, this changes the value assigned to the variable x. Functional programming_sentence_112

Let us say that the initial value of x was 1, then two consecutive evaluations of the variable x yields 10 and 100 respectively. Functional programming_sentence_113

Clearly, replacing x = x * 10 with either 10 or 100 gives a program a different meaning, and so the expression is not referentially transparent. Functional programming_sentence_114

In fact, assignment statements are never referentially transparent. Functional programming_sentence_115

Now, consider another function such as int plusone(int x) {return x+1;} is transparent, as it does not implicitly change the input x and thus has no such side effects. Functional programming_sentence_116

Functional programs exclusively use this type of function and are therefore referentially transparent. Functional programming_sentence_117

Data structures Functional programming_section_8

Main article: Purely functional data structure Functional programming_sentence_118

Purely functional data structures are often represented in a different way than their imperative counterparts. Functional programming_sentence_119

For example, the array with constant access and update times is a basic component of most imperative languages, and many imperative data-structures, such as the hash table and binary heap, are based on arrays. Functional programming_sentence_120

Arrays can be replaced by maps or random access lists, which admit purely functional implementation, but have logarithmic access and update times. Functional programming_sentence_121

Purely functional data structures have persistence, a property of keeping previous versions of the data structure unmodified. Functional programming_sentence_122

In Clojure, persistent data structures are used as functional alternatives to their imperative counterparts. Functional programming_sentence_123

Persistent vectors, for example, use trees for partial updating. Functional programming_sentence_124

Calling the insert method will result in some but not all nodes being created. Functional programming_sentence_125

Comparison to imperative programming Functional programming_section_9

Functional programming is very different from imperative programming. Functional programming_sentence_126

The most significant differences stem from the fact that functional programming avoids side effects, which are used in imperative programming to implement state and I/O. Functional programming_sentence_127

Pure functional programming completely prevents side-effects and provides referential transparency. Functional programming_sentence_128

Higher-order functions are rarely used in older imperative programming. Functional programming_sentence_129

A traditional imperative program might use a loop to traverse and modify a list. Functional programming_sentence_130

A functional program, on the other hand, would probably use a higher-order “map” function that takes a function and a list, generating and returning a new list by applying the function to each list item. Functional programming_sentence_131

Side-by-side comparison of Imperative vs. Functional programming Functional programming_section_10

The following two examples (written in JavaScript) achieve the same effect: they multiply all even numbers in an array by 10 and add them all, storing the final sum in the variable "result". Functional programming_sentence_132

Traditional Imperative Loop: Functional programming_sentence_133

Functional Programming with higher-order functions: Functional programming_sentence_134

Simulating state Functional programming_section_11

There are tasks (for example, maintaining a bank account balance) that often seem most naturally implemented with state. Functional programming_sentence_135

Pure functional programming performs these tasks, and I/O tasks such as accepting user input and printing to the screen, in a different way. Functional programming_sentence_136

The pure functional programming language Haskell implements them using monads, derived from category theory. Functional programming_sentence_137

Monads offer a way to abstract certain types of computational patterns, including (but not limited to) modeling of computations with mutable state (and other side effects such as I/O) in an imperative manner without losing purity. Functional programming_sentence_138

While existing monads may be easy to apply in a program, given appropriate templates and examples, many students find them difficult to understand conceptually, e.g., when asked to define new monads (which is sometimes needed for certain types of libraries). Functional programming_sentence_139

Functional languages also simulate states by passing around immutable states. Functional programming_sentence_140

This can be done by making a function accept the state as one of its parameters, and return a new state together with the result, leaving the old state unchanged. Functional programming_sentence_141

Impure functional languages usually include a more direct method of managing mutable state. Functional programming_sentence_142

Clojure, for example, uses managed references that can be updated by applying pure functions to the current state. Functional programming_sentence_143

This kind of approach enables mutability while still promoting the use of pure functions as the preferred way to express computations. Functional programming_sentence_144

Alternative methods such as Hoare logic and uniqueness have been developed to track side effects in programs. Functional programming_sentence_145

Some modern research languages use effect systems to make the presence of side effects explicit. Functional programming_sentence_146

Efficiency issues Functional programming_section_12

Functional programming languages are typically less efficient in their use of CPU and memory than imperative languages such as C and Pascal. Functional programming_sentence_147

This is related to the fact that some mutable data structures like arrays have a very straightforward implementation using present hardware. Functional programming_sentence_148

Flat arrays may be accessed very efficiently with deeply pipelined CPUs, prefetched efficiently through caches (with no complex pointer chasing), or handled with SIMD instructions. Functional programming_sentence_149

It is also not easy to create their equally efficient general-purpose immutable counterparts. Functional programming_sentence_150

For purely functional languages, the worst-case slowdown is logarithmic in the number of memory cells used, because mutable memory can be represented by a purely functional data structure with logarithmic access time (such as a balanced tree). Functional programming_sentence_151

However, such slowdowns are not universal. Functional programming_sentence_152

For programs that perform intensive numerical computations, functional languages such as OCaml and Clean are only slightly slower than C according to The Computer Language Benchmarks Game. Functional programming_sentence_153

For programs that handle large matrices and multidimensional databases, array functional languages (such as J and K) were designed with speed optimizations. Functional programming_sentence_154

Immutability of data can in many cases lead to execution efficiency by allowing the compiler to make assumptions that are unsafe in an imperative language, thus increasing opportunities for inline expansion. Functional programming_sentence_155

Lazy evaluation may also speed up the program, even asymptotically, whereas it may slow it down at most by a constant factor (however, it may introduce memory leaks if used improperly). Functional programming_sentence_156

Launchbury 1993 discusses theoretical issues related to memory leaks from lazy evaluation, and O'Sullivan et al. Functional programming_sentence_157

2008 give some practical advice for analyzing and fixing them. Functional programming_sentence_158

However, the most general implementations of lazy evaluation making extensive use of dereferenced code and data perform poorly on modern processors with deep pipelines and multi-level caches (where a cache miss may cost hundreds of cycles). Functional programming_sentence_159

Functional programming in non-functional languages Functional programming_section_13

It is possible to use a functional style of programming in languages that are not traditionally considered functional languages. Functional programming_sentence_160

For example, both D and Fortran 95 explicitly support pure functions. Functional programming_sentence_161

JavaScript, Lua and Python had first class functions from their inception. Functional programming_sentence_162

Python had support for "lambda", "map", "reduce", and "filter" in 1994, as well as closures in Python 2.2, though Python 3 relegated "reduce" to the functools standard library module. Functional programming_sentence_163

First-class functions have been introduced into other mainstream languages such as PHP 5.3, Visual Basic 9, C# 3.0, C++11, and Kotlin. Functional programming_sentence_164

In PHP, anonymous classes, closures and lambdas are fully supported. Functional programming_sentence_165

Libraries and language extensions for immutable data structures are being developed to aid programming in the functional style. Functional programming_sentence_166

In Java, anonymous classes can sometimes be used to simulate closures; however, anonymous classes are not always proper replacements to closures because they have more limited capabilities. Functional programming_sentence_167

Java 8 supports lambda expressions as a replacement for some anonymous classes. Functional programming_sentence_168

In C#, anonymous classes are not necessary, because closures and lambdas are fully supported. Functional programming_sentence_169

Libraries and language extensions for immutable data structures are being developed to aid programming in the functional style in C#. Functional programming_sentence_170

Many object-oriented design patterns are expressible in functional programming terms: for example, the strategy pattern simply dictates use of a higher-order function, and the visitor pattern roughly corresponds to a catamorphism, or fold. Functional programming_sentence_171

Similarly, the idea of immutable data from functional programming is often included in imperative programming languages, for example the tuple in Python, which is an immutable array. Functional programming_sentence_172

Applications Functional programming_section_14

Academia Functional programming_section_15

Functional programming is an active area of research in the field of programming language theory. Functional programming_sentence_173

There are several peer-reviewed publication venues focusing on functional programming, including the International Conference on Functional Programming, the Journal of Functional Programming, and the Symposium on Trends in Functional Programming. Functional programming_sentence_174

Industry Functional programming_section_16

Functional programming has seen use in a wide variety of industrial applications. Functional programming_sentence_175

For example, Erlang, which was developed by the Swedish company Ericsson in the late 1980s, was originally used to implement fault-tolerant telecommunications systems, but has since become popular for building a range of applications at companies such as Nortel, Facebook, Électricité de France and WhatsApp. Functional programming_sentence_176

Scheme, a dialect of Lisp, was used as the basis for several applications on early Apple Macintosh computers, and has been applied to problems such as training simulation software and telescope control. Functional programming_sentence_177

OCaml, which was introduced in the mid-1990s, has seen commercial use in areas such as financial analysis, driver verification, industrial robot programming, and static analysis of embedded software. Functional programming_sentence_178

Haskell, though initially intended as a research language, has also been applied by a range of companies, in areas such as aerospace systems, hardware design, and web programming. Functional programming_sentence_179

Other functional programming languages that have seen use in industry include Scala, F#, Wolfram Language, Lisp, Standard ML, and Clojure. Functional programming_sentence_180

Functional "platforms" have been popular in finance for risk analytics (particularly with the larger investment banks). Functional programming_sentence_181

Risk factors are coded as functions that form interdependent graphs (categories) to measure correlations in market shifts not unlike Gröbner basis optimizations but also for regulatory compliance such as Comprehensive Capital Analysis and Review. Functional programming_sentence_182

Given the use of OCAML or CAML variations in finance, these systems are sometimes considered related to a categorical abstract machine or CAM. Functional programming_sentence_183

Indeed, functional programming is heavily influenced by category theory. Functional programming_sentence_184

Education Functional programming_section_17

Many universities teach or have taught functional programming as part of their undergraduate Computer Science degrees. Functional programming_sentence_185

Some use it as their introduction to programming, while others teach it after teaching imperative programming. Functional programming_sentence_186

Outside of computer science, functional programming is being used as a method to teach problem solving, algebra and geometric concepts. Functional programming_sentence_187

It has also been used as a tool to teach classical mechanics in Structure and Interpretation of Classical Mechanics. Functional programming_sentence_188

See also Functional programming_section_18

Functional programming_unordered_list_1


Credits to the contents of this page go to the authors of the corresponding Wikipedia page: en.wikipedia.org/wiki/Functional programming.