Hacker News Reader

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.

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"

"The JavaScript community" need not include everyone who has used javascript. Why do you assume GP was intending it to do so?

I made only one assumption - that "the JavaScript community" is a granfalloon. Any further assumptions you assume I made are not valid.

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

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.

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.

> You can get full pattern match checking via -fwarn-incomplete-patterns.

Only at definition site, not use site, for both better and worse.

isn't bottom part of any data type, including a?

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.

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

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

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

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.

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

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)