8 ms·

Ask five programmers to define functional programming, get fifteen different answers.

galad87 10y ago
Same thing can be said for object-oriented programming, unfortunately.
greydius 10y ago
Most people would agree that in functional programming we can pass functions around as first class objects. What we disagree on is the definition of function.
- gardenhead 10y ago
  That's just one aspect of functional programming. By that definition, almost any modern language is functional.
  - kibwen 10y ago
    Every modern language is functional. :P But more accurately, every modern language is generally multi-paradigm.
  - junke 10y ago
    Take it from the other side: why would a language that allows to create higher-order functions/closures not be called functional?
    - eridius 10y ago
      Because that makes the term meaningless. You may as well ask "why don't we call any language that lets you do two actions in sequence 'procedural'?"
      - junke 10y ago
        A term does not necessarily become meaningless when it applies to a lot of things. "Functional" might be a broad category after all, not the exclusive name of a subset of functional languages. And if your language allows different paradigms, it will be called "functional and imperative and object-oriented... ". At best, if a property is so common that most language have it, it can be assumed to be satisfied by default. As for "procedural", the definition on wikipedia is a little more precise and does not apply to all languages: https://en.wikipedia.org/wiki/Procedural_programming https://en.wikipedia.org/wiki/Procedural_programming.
      - kibwen 10y ago
        That doesn't make the term meaningless, it just means that "functional programming" is a victim of its own success.
        eridius 10y ago
        If you can apply the term to every programming language in widespread use today[1], then yes, it is pretty useless. There is real value in having the term "functional programming" be meaningful and denote a certain class of languages; defining that as "any language with first-class function values" is too broad as to render the term meaningless. [1] Even C has this with Apple's Blocks extension (http://clang.llvm.org/docs/Block-ABI-Apple.html http://clang.llvm.org/docs/Block-ABI-Apple.html).
    - catnaroek 10y ago
      Most languages only have higher-order procedures, not higher-order functions. As for closures, well, closures are an implementation technique. Not distinguishing between language features and implementation techniques is a part of an established tradition that comes from Lisp, but that doesn't make it any less wrong.
      - frankpf 10y ago
        > Most languages only have higher-order procedures, not higher-order functions. What do you mean by that?
        catnaroek 10y ago
        Functions have the following properties: (0) A function maps every element of its domain to a unique element of its codomain. (1) Functions don't exist in time, let alone change over time. (2) Two functions with the same domain and codomain are equal if they map the same domain elements to the same codomain elements. Since when do so-called “first-class functions” in most programming languages behave like this?
- lanna 10y ago
  No, wrong. You can pass pointers to functions in C.
  - Someone 10y ago
    It is a bit snarky, but also has a ground truth: pointers to functions aren't functions. More importantly, you cannot make functions in C. For example, one cannot write a function that, given pointers to functions that compute 1/x and sin(x), returns a pointer to a function that returns 1/sin(x)
    - eridius 10y ago
      That's not a function, that's a closure. And you can simulate that in C by creating a struct that contains the function pointer and the set of captured data (and then when you invoke the function you pass the struct to it as a parameter).
      - junke 10y ago
        Yes, hence the distinction between first-class features and others, which you have to implement yourself.
        eridius 10y ago
        The parent comment said C function pointers aren't functions. They are. They just aren't closures.
Waterluvian 10y ago
I always thought FP == pure functions. I guess not?
- _mhr_ 10y ago
  I would call a language like Haskell "purely functional" and a language like OCaml "impurely functional". A functional programming language to me is a programming language where functions are in charge of data. In a language like Java, data is in charge of functions (broadly speaking). In a language like Prolog, relations are in charge of data. It's all about what perspective the programmer has between the abstraction and the data.
  - catnaroek 10y ago
    You have it backwards. In Java, collections of procedures (aka objects) are in charge of data. In Haskell and OCaml, data exists independently of the procedures that will operate on it.
lanna 10y ago
If they are truly functional programmers, asking them will always return the same referentially transparent answer. Only side-effecting functions would return different answers at different times :-)
anonymouslee 10y ago
Seems to me that's because functional programming continues to evolve (which is great!) and newfangled properties and semantics get folded in. To me the core is "no side effects" though (for pure FP). It's interesting to see what others consider to be the most salient feature(s).
shados 10y ago
and if it was about OOP, you'd get a hierarchy of answers that no one can follow and is unsound ;)
pjmlp 10y ago
It is the programming style I learned to program in Lisp and Caml Light, and when Haskell was still known as Mirada.
solidsnack9000 10y ago
The author of this article did reference a classic treatment, though: John Backus's lecture. A compact definition of functional programming is using only expressions, never statements. This leads to the idea that the effect or meaning of every computation must be encoded in its return value.
lmkg 10y ago
The term "functional programming" is overloaded, but I think there's a sensible way to split the term into two halves. "Purely functional programming" is writing programs to resemble mathematical functions, with referential transparency and absence of side-effects and so forth. Also know as "what Haskell does." "Function-oriented programming" is writing programs using functions as your main tool for abstraction, encapsulation, defining interfaces, unit of code division, etc. This part of functional programming is more typified by the Lisp family. Most languages that are considered functional generally encourage both of these aspects, partly because they work well together. The confusion over definition comes from these two halves getting tangled, and some languages or programmers emphasizing one half over the other. Non-functional languages that are becoming "more functional" are generally importing features from the "function-oriented" side of things, and adopting the "purely functional" aspect as a best practice convention, if at all. It's probably more accurate to say that they enable a functional style of programming, rather than that the are functional.
- js8 10y ago
  Actually, both of those families come from lambda calculus, except in different way. Lisp comes from untyped lambda calculus (and adds things like car, cdr and eq on top of it), while Haskell (and ML) comes primarily from typed lambda calculus. I offer a definition of "functional programming" as "based on semantics of lambda calculus".
  - catnaroek 10y ago
    Here are some features that the lambda calculus doesn't have: n-ary functions for n other than 1, macros (or any other means to analyze its own syntax), dynamically scoped variables, physical object identities, etc. In the untyped lambda calculus, any two alpha-equivalent terms are internally indistinguishable - in fact, you can even make them externally indistinguishable using a nameless representation of syntax like “de Bruijn indices”. So much for “Lisp comes from [the] untyped lambda calculus”.
  - kazinator 10y ago
    Lisp does not come from lambda calculus. Anonymous functions in Lisp get their LAMBDA name from lambda calculus, that's all. MacCarthy admitted that he didn't even understand lambda calculus properly, which is why early Lisp was dynamically scoped: lambdas didn't capture lexical variables. Whereas lambda calculus is lexical. Lexical scoping was adopted in later Lisp dialects and into Common Lisp, making those dialects retroactively related to lambda calculus. (Emacs Lisp shows the traditional behavior of dynamic scoping; therefore it couldn't be said to be related to lambda calculus.) Lambda calculus is a formalization of number theory which builds up numbers from functions. An important result is that lambda calculus is Turing complete. It shows that we can boostrap numbers and number theory from almost out of nothing, using Church numerals. Lisp has never built numbers out of Church numerals; it had ordinary integers. Also, lambda calculus, typed or not, does not have its own syntax as a data type. It doesn't have symbols. You don't quote a symbol and pass it to a function and so on. So that's basically it; there is a link between Lisp and lambda calculus due to the use of the word lambda in a related way, and a somewhat stronger link between lexically scoped Lisps (which came later) and lambda calculus.
bad_user 10y ago
There's only one definition that matters: functional programming is programming with mathematical (pure) functions. As a consequence you get referential transparency and thus equational reasoning. But change this definition and the term becomes meaningless.
- kibwen 10y ago
  Though by this definition, Lisp, the granddaddy of functional programming languages, is not a functional programming language.
  - catnaroek 10y ago
    It indeed isn't. Here's my litmus test. Is 2^100 always equal to 2^100? Let's ask SBCL: * (eq (expt 2 100) (expt 2 100)) NIL Damn object identities, ruining muh equalities. (Disclaimer: I'm not saying functional programming is the right approach for writing every program, but if a language can't even get arithmetic and relational operators right...)
    - junke 10y ago
      Structural equivalence is given by EQUALP and has of course its own limitations (but works with trees, user-defined structs and hash-tables, for example). Of course, if you use the identity comparison, you get different results. I agree CL does not fit your definition of functional programming. An implementation is permitted to make "copies" of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are "the same thing" if that thing is a character or number. http://www.lispworks.com/documentation/lw51/CLHS/Body/f_eq.htm http://www.lispworks.com/documentation/lw51/CLHS/Body/f_eq.h...
      - catnaroek 10y ago
        I'm aware of EQUALP. But the problem remains that it's possible to distinguish between supposedly “equal” values. Lisp and Scala are first and foremost object-oriented languages - whatever values you want to manipulate are always subordinate to objects whose physical identity in memory matters in the language's semantics, no matter how irrelevant they might be for your problem domain. On the other hand, in Haskell and ML, due to their superior value-oriented design, there's no way to distinguish between “this 123456789” and “that 123456789”, or between “this list [1,2,3]” and “that list [1,2,3]”. There is only one number 123456789 and one one list [1,2,3] in the language's semantics, no matter how many copies of their representation might exist in memory.

Same thing can be said for object-oriented programming, unfortunately.

Most people would agree that in functional programming we can pass functions around as first class objects. What we disagree on is the definition of function.

gardenhead 10y ago
That's just one aspect of functional programming. By that definition, almost any modern language is functional.
- kibwen 10y ago
  Every modern language is functional. :P But more accurately, every modern language is generally multi-paradigm.
- junke 10y ago
  Take it from the other side: why would a language that allows to create higher-order functions/closures not be called functional?
  - eridius 10y ago
    Because that makes the term meaningless. You may as well ask "why don't we call any language that lets you do two actions in sequence 'procedural'?"
    - junke 10y ago
      A term does not necessarily become meaningless when it applies to a lot of things. "Functional" might be a broad category after all, not the exclusive name of a subset of functional languages. And if your language allows different paradigms, it will be called "functional and imperative and object-oriented... ". At best, if a property is so common that most language have it, it can be assumed to be satisfied by default. As for "procedural", the definition on wikipedia is a little more precise and does not apply to all languages: https://en.wikipedia.org/wiki/Procedural_programming https://en.wikipedia.org/wiki/Procedural_programming.
    - kibwen 10y ago
      That doesn't make the term meaningless, it just means that "functional programming" is a victim of its own success.
      - eridius 10y ago
        If you can apply the term to every programming language in widespread use today[1], then yes, it is pretty useless. There is real value in having the term "functional programming" be meaningful and denote a certain class of languages; defining that as "any language with first-class function values" is too broad as to render the term meaningless. [1] Even C has this with Apple's Blocks extension (http://clang.llvm.org/docs/Block-ABI-Apple.html http://clang.llvm.org/docs/Block-ABI-Apple.html).
  - catnaroek 10y ago
    Most languages only have higher-order procedures, not higher-order functions. As for closures, well, closures are an implementation technique. Not distinguishing between language features and implementation techniques is a part of an established tradition that comes from Lisp, but that doesn't make it any less wrong.
    - frankpf 10y ago
      > Most languages only have higher-order procedures, not higher-order functions. What do you mean by that?
      - catnaroek 10y ago
        Functions have the following properties: (0) A function maps every element of its domain to a unique element of its codomain. (1) Functions don't exist in time, let alone change over time. (2) Two functions with the same domain and codomain are equal if they map the same domain elements to the same codomain elements. Since when do so-called “first-class functions” in most programming languages behave like this?
lanna 10y ago
No, wrong. You can pass pointers to functions in C.
- Someone 10y ago
  It is a bit snarky, but also has a ground truth: pointers to functions aren't functions. More importantly, you cannot make functions in C. For example, one cannot write a function that, given pointers to functions that compute 1/x and sin(x), returns a pointer to a function that returns 1/sin(x)
  - eridius 10y ago
    That's not a function, that's a closure. And you can simulate that in C by creating a struct that contains the function pointer and the set of captured data (and then when you invoke the function you pass the struct to it as a parameter).
    - junke 10y ago
      Yes, hence the distinction between first-class features and others, which you have to implement yourself.
      - eridius 10y ago
        The parent comment said C function pointers aren't functions. They are. They just aren't closures.

Waterluvian 10y ago

I always thought FP == pure functions. I guess not?

_mhr_ 10y ago
I would call a language like Haskell "purely functional" and a language like OCaml "impurely functional". A functional programming language to me is a programming language where functions are in charge of data. In a language like Java, data is in charge of functions (broadly speaking). In a language like Prolog, relations are in charge of data. It's all about what perspective the programmer has between the abstraction and the data.
- catnaroek 10y ago
  You have it backwards. In Java, collections of procedures (aka objects) are in charge of data. In Haskell and OCaml, data exists independently of the procedures that will operate on it.

lanna 10y ago

If they are truly functional programmers, asking them will always return the same referentially transparent answer. Only side-effecting functions would return different answers at different times :-)

anonymouslee 10y ago

Seems to me that's because functional programming continues to evolve (which is great!) and newfangled properties and semantics get folded in. To me the core is "no side effects" though (for pure FP). It's interesting to see what others consider to be the most salient feature(s).

shados 10y ago

and if it was about OOP, you'd get a hierarchy of answers that no one can follow and is unsound ;)

pjmlp 10y ago

It is the programming style I learned to program in Lisp and Caml Light, and when Haskell was still known as Mirada.

solidsnack9000 10y ago

The author of this article did reference a classic treatment, though: John Backus's lecture. A compact definition of functional programming is using only expressions, never statements. This leads to the idea that the effect or meaning of every computation must be encoded in its return value.

lmkg 10y ago

The term "functional programming" is overloaded, but I think there's a sensible way to split the term into two halves. "Purely functional programming" is writing programs to resemble mathematical functions, with referential transparency and absence of side-effects and so forth. Also know as "what Haskell does." "Function-oriented programming" is writing programs using functions as your main tool for abstraction, encapsulation, defining interfaces, unit of code division, etc. This part of functional programming is more typified by the Lisp family. Most languages that are considered functional generally encourage both of these aspects, partly because they work well together. The confusion over definition comes from these two halves getting tangled, and some languages or programmers emphasizing one half over the other. Non-functional languages that are becoming "more functional" are generally importing features from the "function-oriented" side of things, and adopting the "purely functional" aspect as a best practice convention, if at all. It's probably more accurate to say that they enable a functional style of programming, rather than that the are functional.

js8 10y ago
Actually, both of those families come from lambda calculus, except in different way. Lisp comes from untyped lambda calculus (and adds things like car, cdr and eq on top of it), while Haskell (and ML) comes primarily from typed lambda calculus. I offer a definition of "functional programming" as "based on semantics of lambda calculus".
- catnaroek 10y ago
  Here are some features that the lambda calculus doesn't have: n-ary functions for n other than 1, macros (or any other means to analyze its own syntax), dynamically scoped variables, physical object identities, etc. In the untyped lambda calculus, any two alpha-equivalent terms are internally indistinguishable - in fact, you can even make them externally indistinguishable using a nameless representation of syntax like “de Bruijn indices”. So much for “Lisp comes from [the] untyped lambda calculus”.
- kazinator 10y ago
  Lisp does not come from lambda calculus. Anonymous functions in Lisp get their LAMBDA name from lambda calculus, that's all. MacCarthy admitted that he didn't even understand lambda calculus properly, which is why early Lisp was dynamically scoped: lambdas didn't capture lexical variables. Whereas lambda calculus is lexical. Lexical scoping was adopted in later Lisp dialects and into Common Lisp, making those dialects retroactively related to lambda calculus. (Emacs Lisp shows the traditional behavior of dynamic scoping; therefore it couldn't be said to be related to lambda calculus.) Lambda calculus is a formalization of number theory which builds up numbers from functions. An important result is that lambda calculus is Turing complete. It shows that we can boostrap numbers and number theory from almost out of nothing, using Church numerals. Lisp has never built numbers out of Church numerals; it had ordinary integers. Also, lambda calculus, typed or not, does not have its own syntax as a data type. It doesn't have symbols. You don't quote a symbol and pass it to a function and so on. So that's basically it; there is a link between Lisp and lambda calculus due to the use of the word lambda in a related way, and a somewhat stronger link between lexically scoped Lisps (which came later) and lambda calculus.

bad_user 10y ago

There's only one definition that matters: functional programming is programming with mathematical (pure) functions. As a consequence you get referential transparency and thus equational reasoning. But change this definition and the term becomes meaningless.

kibwen 10y ago
Though by this definition, Lisp, the granddaddy of functional programming languages, is not a functional programming language.
- catnaroek 10y ago
  It indeed isn't. Here's my litmus test. Is 2^100 always equal to 2^100? Let's ask SBCL: * (eq (expt 2 100) (expt 2 100)) NIL Damn object identities, ruining muh equalities. (Disclaimer: I'm not saying functional programming is the right approach for writing every program, but if a language can't even get arithmetic and relational operators right...)
  - junke 10y ago
    Structural equivalence is given by EQUALP and has of course its own limitations (but works with trees, user-defined structs and hash-tables, for example). Of course, if you use the identity comparison, you get different results. I agree CL does not fit your definition of functional programming. An implementation is permitted to make "copies" of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are "the same thing" if that thing is a character or number. http://www.lispworks.com/documentation/lw51/CLHS/Body/f_eq.htm http://www.lispworks.com/documentation/lw51/CLHS/Body/f_eq.h...
    - catnaroek 10y ago
      I'm aware of EQUALP. But the problem remains that it's possible to distinguish between supposedly “equal” values. Lisp and Scala are first and foremost object-oriented languages - whatever values you want to manipulate are always subordinate to objects whose physical identity in memory matters in the language's semantics, no matter how irrelevant they might be for your problem domain. On the other hand, in Haskell and ML, due to their superior value-oriented design, there's no way to distinguish between “this 123456789” and “that 123456789”, or between “this list [1,2,3]” and “that list [1,2,3]”. There is only one number 123456789 and one one list [1,2,3] in the language's semantics, no matter how many copies of their representation might exist in memory.