10 ms·

If we want to be pedantic, there is no such thing as a pure JavaScript function. If the stack is full, the invocation of ANY function will overflow the stack. T

If we want to be pedantic, there is no such thing as a pure JavaScript function. If the stack is full, the invocation of ANY function will overflow the stack. That's a side effect to the outside world. Pure functions exist under Plato's Theory of the Form conception of the world, but not on a fixed and finite physical computer. http://www.johndcook.com/blog/2010/05/18/pure-functions-have-side-effects/ http://www.johndcook.com/blog/2010/05/18/pure-functions-have... If we don't want to pedantic, then a fraction of the 74% of who took the function as 'pure' probably took this to mean being equivalent to referential transparency. That's good enough, and I believe the author would agree. I hope we can start shifting our discussions from 'is this pure?' to 'Does this function behave like a Mathematical Function in all the situations I will encounter in my code?' It's a good exercise to think about assumptions, but we shouldn't be so paranoid as to check if native JS methods, namely Array.isArray, have been overridden (unless security is a concern). When we speak about the Fibonacci sequence, it's nonsensical to talk about f("pie"). The domain being integers is implied in the semantics of the function. In the veins of "keep an open mind but not so open that your brain falls out", I propose "keep writing code with pure functions, but not so pure that your code becomes cluttered."

wldcordeiro 10y ago
I ran into this article a little while ago and I had a similar sentiment. I get the point staltz is making but it felt pedantic and heavy handed, hell you can ignore JavaScript entirely and the same is true for just about every programming language. Seems that there is a trend towards ideology in the JavaScript community lately that bothers me. People obsess over pure functions and FRP and talk so highly about these things like mutation and non-FRP are the worst things on the planet when it comes to code.
- oldmanjay 10y ago
  The trouble with trying to apply words like "community" to millions upon millions of people with basically nothing but a surface connection (like they all have used javascript, for instance) is explained nicely in Vonnegut's "Cat's Cradle"
  - philh 10y ago
    "The JavaScript community" need not include everyone who has used javascript. Why do you assume GP was intending it to do so?
    - oldmanjay 10y ago
      I made only one assumption - that "the JavaScript community" is a granfalloon. Any further assumptions you assume I made are not valid.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
dustingetz 10y ago
yes we run on imperative hardware, a pure functional language can run out of memory too (but I agree that Staltz's stance is unhelpful)
wongarsu 10y ago
>Pure functions exist under Plato's Theory of the Form conception of the world, but not on a fixed and finite physical computer In the same vein you can say that C is a Turing complete language (i.e. you can use C to simulate a Turing machine), so there can be no complete implementation of C on a computer because no computer can simulate a Turing machine (since real computers are only state machines, which are inferior to Turing machines). When talking about computer-science terms like "pure function" or "turing complete" things tend to stay a lot more sane if you just assume that even in the real world you will not run out of memory (just as a lot of programming stays more sane under that assumption).
amelius 10y ago
> If we want to be pedantic, there is no such thing as a pure JavaScript function. If the stack is full, ... Under this definition, Haskell has no pure functions either.
- jrockway 10y ago
  I think that's a fine assertion to make, because Haskell functions can die at runtime because of pattern match failure or an explicit evaluation of "bottom" (undefined). Prelude> undefined *** Exception: Prelude.undefined Prelude> let x 2 = 4 in x 1 *** Exception: <interactive>:7:5-11: Non-exhaustive patterns in function x Neither of these behaviors is indicated in the type definition: Prelude> :t undefined undefined :: t Prelude> :t let x 2 = 4 in x let x 2 = 4 in x :: (Eq a, Num a, Num a1) => a -> a1 I was promised a -> a but got a runtime exception instead.
  - tiagobraw 10y ago
    isn't bottom part of any data type, including a?
    - jrockway 10y ago
      It is, yes, but people often proclaim "haskell has solved the 'null' problem", and it hasn't because bottom is the exact same thing as null.
      - tome 10y ago
        > bottom is the exact same thing as null No it's not because you can't check for bottom (purely) and thus you can't use it as a flag or sentinel value.
  - wyager 10y ago
    You can get full pattern match checking via -fwarn-incomplete-patterns. Crashing on bottom is a concession to the fact that crashing is more useful than infinite loops. The semantics of the program exiting are the same as the semantics of the program infinite looping. So I'd say it's as pure as you can get on a finite state computer.
dottedmag 10y ago
As a matter of fact, if your JS code is running on a pages where other pieces of code could be loaded, then it will regularly encounter native JS methods being overridden (Prototype.js is the worst offender so far).
msl09 10y ago
>When we speak about the Fibonacci sequence, it's nonsensical to talk about f("pie"). Indeed it is, but I think you are taking his example literally. That problem can appear in more subtle ways. Consider some other examples: f(string) Does f works for every string? What if it's unicode. What if it's an empty string? What if it's a sequence type(like an iterator over a stream) that returns the letters of a string? mean(numbers) What is the biggest number I can pass? If I pass a list of integers does it return a float or an integer? If I pass an empty list, does it return 0, -1, null, undefined? There are several situations on which you can encounter similar situations. I do not disagree that all that type information has a cost, your type signature can become more complicated, your cognitive load can be increased, your code can be less flexible, it can be harder to integrate with existing technologies, but since the problem still exists I think it's very reasonable that the author is trying to keep that discussion alive.
- klodolph 10y ago
  The conventional definition of "pure" is that the result of the function is the same for the same input. You might include "throws an exception" as a possible "result" for a JavaScript function, or you might not (generally not). So the fact that your implementation of mean() returns a float when you expected an int (honestly, there are no ints in JavaScript, just floats which happen to have integer values, why would you expect that?) or returns undefined doesn't mean that the function is impure, it just means that the function doesn't do what you thought that it should do. For example, I can write the function: function addOne(x) { return x + 1; } I think there is no conceivable generally useful definition of "pure" under which this function is not pure, and yet... it could overflow the stack, it could run out of heap memory if you pass a string depending on how much heap memory is available... The generally useful definition of "pure" is just that if f is pure, I can save y = f(x) and use y instead of f(x), or vice versa, or I can eliminate f(x) completely if I don't need the result. The fact that extreme corner cases, like out-of-memory situations, can result in slightly different behavior is something that we like to gloss over.

wldcordeiro 10y ago

I ran into this article a little while ago and I had a similar sentiment. I get the point staltz is making but it felt pedantic and heavy handed, hell you can ignore JavaScript entirely and the same is true for just about every programming language. Seems that there is a trend towards ideology in the JavaScript community lately that bothers me. People obsess over pure functions and FRP and talk so highly about these things like mutation and non-FRP are the worst things on the planet when it comes to code.

oldmanjay 10y ago
The trouble with trying to apply words like "community" to millions upon millions of people with basically nothing but a surface connection (like they all have used javascript, for instance) is explained nicely in Vonnegut's "Cat's Cradle"
- philh 10y ago
  "The JavaScript community" need not include everyone who has used javascript. Why do you assume GP was intending it to do so?
  - oldmanjay 10y ago
    I made only one assumption - that "the JavaScript community" is a granfalloon. Any further assumptions you assume I made are not valid.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]

dustingetz 10y ago

yes we run on imperative hardware, a pure functional language can run out of memory too (but I agree that Staltz's stance is unhelpful)

wongarsu 10y ago

>Pure functions exist under Plato's Theory of the Form conception of the world, but not on a fixed and finite physical computer In the same vein you can say that C is a Turing complete language (i.e. you can use C to simulate a Turing machine), so there can be no complete implementation of C on a computer because no computer can simulate a Turing machine (since real computers are only state machines, which are inferior to Turing machines). When talking about computer-science terms like "pure function" or "turing complete" things tend to stay a lot more sane if you just assume that even in the real world you will not run out of memory (just as a lot of programming stays more sane under that assumption).

amelius 10y ago

> If we want to be pedantic, there is no such thing as a pure JavaScript function. If the stack is full, ... Under this definition, Haskell has no pure functions either.

jrockway 10y ago
I think that's a fine assertion to make, because Haskell functions can die at runtime because of pattern match failure or an explicit evaluation of "bottom" (undefined). Prelude> undefined *** Exception: Prelude.undefined Prelude> let x 2 = 4 in x 1 *** Exception: <interactive>:7:5-11: Non-exhaustive patterns in function x Neither of these behaviors is indicated in the type definition: Prelude> :t undefined undefined :: t Prelude> :t let x 2 = 4 in x let x 2 = 4 in x :: (Eq a, Num a, Num a1) => a -> a1 I was promised a -> a but got a runtime exception instead.
- tiagobraw 10y ago
  isn't bottom part of any data type, including a?
  - jrockway 10y ago
    It is, yes, but people often proclaim "haskell has solved the 'null' problem", and it hasn't because bottom is the exact same thing as null.
    - tome 10y ago
      > bottom is the exact same thing as null No it's not because you can't check for bottom (purely) and thus you can't use it as a flag or sentinel value.
- wyager 10y ago
  You can get full pattern match checking via -fwarn-incomplete-patterns. Crashing on bottom is a concession to the fact that crashing is more useful than infinite loops. The semantics of the program exiting are the same as the semantics of the program infinite looping. So I'd say it's as pure as you can get on a finite state computer.

dottedmag 10y ago

As a matter of fact, if your JS code is running on a pages where other pieces of code could be loaded, then it will regularly encounter native JS methods being overridden (Prototype.js is the worst offender so far).

msl09 10y ago

>When we speak about the Fibonacci sequence, it's nonsensical to talk about f("pie"). Indeed it is, but I think you are taking his example literally. That problem can appear in more subtle ways. Consider some other examples: f(string) Does f works for every string? What if it's unicode. What if it's an empty string? What if it's a sequence type(like an iterator over a stream) that returns the letters of a string? mean(numbers) What is the biggest number I can pass? If I pass a list of integers does it return a float or an integer? If I pass an empty list, does it return 0, -1, null, undefined? There are several situations on which you can encounter similar situations. I do not disagree that all that type information has a cost, your type signature can become more complicated, your cognitive load can be increased, your code can be less flexible, it can be harder to integrate with existing technologies, but since the problem still exists I think it's very reasonable that the author is trying to keep that discussion alive.

klodolph 10y ago
The conventional definition of "pure" is that the result of the function is the same for the same input. You might include "throws an exception" as a possible "result" for a JavaScript function, or you might not (generally not). So the fact that your implementation of mean() returns a float when you expected an int (honestly, there are no ints in JavaScript, just floats which happen to have integer values, why would you expect that?) or returns undefined doesn't mean that the function is impure, it just means that the function doesn't do what you thought that it should do. For example, I can write the function: function addOne(x) { return x + 1; } I think there is no conceivable generally useful definition of "pure" under which this function is not pure, and yet... it could overflow the stack, it could run out of heap memory if you pass a string depending on how much heap memory is available... The generally useful definition of "pure" is just that if f is pure, I can save y = f(x) and use y instead of f(x), or vice versa, or I can eliminate f(x) completely if I don't need the result. The fact that extreme corner cases, like out-of-memory situations, can result in slightly different behavior is something that we like to gloss over.