4 ms·

>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 prob

by 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.

by msl09 10y ago

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.