5 ms·

A functional language is a procedural language that meets the following three additional conditions: (0) It encourages using values over objects with a notion

A functional language is a procedural language that meets the following three additional conditions: (0) It encourages using values over objects with a notion of physical identity. (1) It encourages using procedures that compute functions: mappings from values to values. (2) It discourages distinguishing between procedures that compute the same function. Let's see how well JavaScript fares: (0) Are `[1,2,3]` and `[1,2,3]` equal or different? (1) Given `function(x) { return { first: x, second: y }; }`, are `f("hello")` and `f("hello")` equal or different? (2) Are `function(x,y) { return x + y; }` and `function(x,y) { return x + y; }` equal or different? This should tell you whether JavaScript is a functional language.

minitech 10y ago
[citation needed], because this sounds wrong: > A functional language is a procedural language this doesn’t sound authoritative: > that meets the following three additional conditions this doesn’t sound like the right distinction: > It encourages using values over objects and this doesn’t sound meaningful: > It discourages distinguishing between procedures that compute the same function.
- catnaroek 10y ago
  > this doesn’t sound authoritative A functional language still uses procedures, even Haskell! To see what I mean, consider the possibility of divergence (infinite loop, `undefined`, `error "foo"`, you name it). It doesn't make sense for a mathematical function to diverge. The difference between, on the one hand, Haskell, ML and Racket, and, on the other hand, JavaScript, Python and Ruby, is that the former group encourages you program with procedures that compute mathematical functions, whereas the latter group does not. > this doesn’t sound like the right distinction It doesn't suffice, but it's a precondition. For good or for bad, mathematical functions are mappings from values to values, so you can't talk about computing functions in a language without a rock-solid notion of (possibly compound) value. > and this doesn’t sound like the right example for (2) [deleted from your original post, but I'm not deleting it from here] Yes, it's the right example. Haskell and ML prevent you from accidentally distinguishing two extensionally equal functions by not letting you compare procedures in the first place. > and this doesn’t sound meaningful These functions ought to be extensionally equal in any mathematically civilized language: function foo(x,y) { return x + y; } function bar(x,y) { return x + y; } But JavaScript lets me distinguish them.
  - minitech 10y ago
    Wikipedia is far from the be-all and end-all source, but at least it is one, so here’s a quote from https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming: “It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements.” I would agree with it that the usual meanings of “procedural language” and “functional language” are not compatible.
    - catnaroek 10y ago
      Any procedural language, not only functional ones, can be expression-oriented, rather than statement-oriented, e.g., Ruby. And Prolog programs are literally lists of declarations (of inference rules), yet Prolog isn't a functional language.
      - minitech 10y ago
        The quote says functional programming is a type of declarative programming, not the other way around. Prolog is irrelevant. Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal? If the functions that can be compared aren’t restricted to some silly level and the language is Turing-complete, I can’t imagine any better behaviour than Haskell’s that you already mentioned, which you can bring to JavaScript pretty easily.
        catnaroek 10y ago
        > The quote says functional programming is a type of declarative programming, not the other way around. Well, your quote doesn't even provide a full definition, sooo... > Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal? No, that's obviously undecidable. (Rice's theorem.) But read what I said more carefully. Did I ever say “A functional language lets you determine whether two functions are equal?” I didn't! What I said is “A functional language doesn't let you distinguish equal functions.” Not letting you test functions for equality is a perfectly valid (and, in fact, the only valid) approach in a higher-order language. > which you can bring to JavaScript pretty easily. Not really. I can't undefined JavaScript's existing equality operator.
solidsnack9000 10y ago
It would be reasonable to add _referential transparency_ to this definition and consider the implications. Say we have a function: function time() { return new Date() } Referential transparency implies that we can everywhere replace an expression with any reduction of it but because the return value of this function can change even when its arguments don't, this is not true in Javascript.
- catnaroek 10y ago
  > Referential transparency implies that we can everywhere replace an expression with any reduction of it I'm aware, but that's too strong a requirement. I wanted my definition to capture the bare minimum necessary to make it pleasant to write functional programs. The basic idea is “functional programming is designing your programs in terms of mathematical functions whenever possible (not always!)”, not “functional programming is requiring an embedded IO DSL to do anything effectful”. (But don't take this as a dismissal of Haskell. While I do have complaints against it, effect segregation isn't one of them.) > but because the return value of this function can change even when its arguments don't, this is not true in Javascript. That's okay. A procedure that returns the system date will never be referentially transparent, yet such a procedure is a necessity in any programming language. My beef is actually with the fact JavaScript doesn't have compound values: https://news.ycombinator.com/item?id=12191119 https://news.ycombinator.com/item?id=12191119 . Since compound entities (whether values or mutable objects) are a necessity in practical programming, the harsh reality is that JavaScript programmers have to use mutable objects whether they want it or not.
  - solidsnack9000 10y ago
    > That's okay. A procedure that returns the system date will never be referentially transparent, yet such a procedure is a necessity in any programming language. As long as it accepts a Universe or State parameter, a system time function is referentially transparent. This is rather like how every query in a database can be seen as implicitly depending on a transaction ID parameter. One intuition that falls out of the Church-Turing thesis is that there is no routine in C, Pascal, &c that has no referentially transparent equivalent.

minitech 10y ago

[citation needed], because this sounds wrong: > A functional language is a procedural language this doesn’t sound authoritative: > that meets the following three additional conditions this doesn’t sound like the right distinction: > It encourages using values over objects and this doesn’t sound meaningful: > It discourages distinguishing between procedures that compute the same function.

catnaroek 10y ago
> this doesn’t sound authoritative A functional language still uses procedures, even Haskell! To see what I mean, consider the possibility of divergence (infinite loop, `undefined`, `error "foo"`, you name it). It doesn't make sense for a mathematical function to diverge. The difference between, on the one hand, Haskell, ML and Racket, and, on the other hand, JavaScript, Python and Ruby, is that the former group encourages you program with procedures that compute mathematical functions, whereas the latter group does not. > this doesn’t sound like the right distinction It doesn't suffice, but it's a precondition. For good or for bad, mathematical functions are mappings from values to values, so you can't talk about computing functions in a language without a rock-solid notion of (possibly compound) value. > and this doesn’t sound like the right example for (2) [deleted from your original post, but I'm not deleting it from here] Yes, it's the right example. Haskell and ML prevent you from accidentally distinguishing two extensionally equal functions by not letting you compare procedures in the first place. > and this doesn’t sound meaningful These functions ought to be extensionally equal in any mathematically civilized language: function foo(x,y) { return x + y; } function bar(x,y) { return x + y; } But JavaScript lets me distinguish them.
- minitech 10y ago
  Wikipedia is far from the be-all and end-all source, but at least it is one, so here’s a quote from https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming: “It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements.” I would agree with it that the usual meanings of “procedural language” and “functional language” are not compatible.
  - catnaroek 10y ago
    Any procedural language, not only functional ones, can be expression-oriented, rather than statement-oriented, e.g., Ruby. And Prolog programs are literally lists of declarations (of inference rules), yet Prolog isn't a functional language.
    - minitech 10y ago
      The quote says functional programming is a type of declarative programming, not the other way around. Prolog is irrelevant. Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal? If the functions that can be compared aren’t restricted to some silly level and the language is Turing-complete, I can’t imagine any better behaviour than Haskell’s that you already mentioned, which you can bring to JavaScript pretty easily.
      - catnaroek 10y ago
        > The quote says functional programming is a type of declarative programming, not the other way around. Well, your quote doesn't even provide a full definition, sooo... > Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal? No, that's obviously undecidable. (Rice's theorem.) But read what I said more carefully. Did I ever say “A functional language lets you determine whether two functions are equal?” I didn't! What I said is “A functional language doesn't let you distinguish equal functions.” Not letting you test functions for equality is a perfectly valid (and, in fact, the only valid) approach in a higher-order language. > which you can bring to JavaScript pretty easily. Not really. I can't undefined JavaScript's existing equality operator.

solidsnack9000 10y ago

It would be reasonable to add _referential transparency_ to this definition and consider the implications. Say we have a function: function time() { return new Date() } Referential transparency implies that we can everywhere replace an expression with any reduction of it but because the return value of this function can change even when its arguments don't, this is not true in Javascript.

catnaroek 10y ago
> Referential transparency implies that we can everywhere replace an expression with any reduction of it I'm aware, but that's too strong a requirement. I wanted my definition to capture the bare minimum necessary to make it pleasant to write functional programs. The basic idea is “functional programming is designing your programs in terms of mathematical functions whenever possible (not always!)”, not “functional programming is requiring an embedded IO DSL to do anything effectful”. (But don't take this as a dismissal of Haskell. While I do have complaints against it, effect segregation isn't one of them.) > but because the return value of this function can change even when its arguments don't, this is not true in Javascript. That's okay. A procedure that returns the system date will never be referentially transparent, yet such a procedure is a necessity in any programming language. My beef is actually with the fact JavaScript doesn't have compound values: https://news.ycombinator.com/item?id=12191119 https://news.ycombinator.com/item?id=12191119 . Since compound entities (whether values or mutable objects) are a necessity in practical programming, the harsh reality is that JavaScript programmers have to use mutable objects whether they want it or not.
- solidsnack9000 10y ago
  > That's okay. A procedure that returns the system date will never be referentially transparent, yet such a procedure is a necessity in any programming language. As long as it accepts a Universe or State parameter, a system time function is referentially transparent. This is rather like how every query in a database can be seen as implicitly depending on a transaction ID parameter. One intuition that falls out of the Church-Turing thesis is that there is no routine in C, Pascal, &c that has no referentially transparent equivalent.