Hacker News Reader

The nice thing about infinite loops, `undefined` and `error "foo"` is that nothing can use their result (i.e. nothing happens "after", although that's a tricky concept with lazy evaluation!)

In other words, Haskell doesn't have try/catch for things like `undefined`, so we do have to worry about them occuring, but we don't have to worry about them causing the code to misbehave; it'll either behave or it will stop progressing (either halting or looping infinitely).

On the other hand, the "IO" DSL built in to Haskell can do try/catch; but once you're in IO, all bets are off.

Oh, I'm not saying Haskell doesn't let you express functions. What I'm saying is that functions are expressed as procedures that compute them.

The nice thing about Haskell is that it distinguishes between procedures that may only compute functions (or diverge), and procedures with arbitrary effects.

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

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.

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.

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

> a perfectly valid (and, in fact, the only valid) approach

I thought as much and it would really help if you would just say these sorts of things outright so the comments are actually useful instead of deeply nested wording quibbles.

With that out of the way: you can define a subset of JavaScript that satisfies your third condition by saying “don’t compare functions”. That’s why I didn’t consider it a meaningful condition.

Functional programming works best as a paradigm and then we can just call languages where it’s standard “functional languages”. Much simpler.

> I thought as much and it would really help if you would just say these sorts of things outright so the comments are actually useful instead of deeply nested wording quibbles.

I find it absolutely essential to make perfectly clear what exactly I'm refuting.

> With that out of the way: you can define a subset of JavaScript that satisfies your third

Second.

> condition by saying “don’t compare functions”.

That's a different language. Do you know of any implementation of it?

> Functional programming works best as a paradigm and then we can just call languages where it’s standard “functional languages”. Much simpler.

Nope. A functional language is one that makes it easy to write functional programs, by satisfying the conditions I gave above. A programming language is first and foremost its semantics, whatever the culture of its users.

> Nope. A functional language is one that makes it easy to write functional programs, by satisfying the conditions I gave above.

Except you’ve still given no source for the conditions, condition -1 (“a functional language is a procedural language”) is wrong, and a language satisfying the conditions in no way makes it easier to write a functional program just by virtue of satisfying the conditions (because they can be satisfied entirely by removing features you don’t have to use). Maybe you meant “harder to write non-functional programs”.

> Second.

The last item in a list of three items is not the second item.

> condition -1 (“a functional language is a procedural language”) is wrong

It's correct. In a procedural language, computations are structured as procedures that may call each other. In a functional language, that condition (plus three additional ones) hold.

> and a language satisfying the conditions in no way makes it easier to write a functional program just by virtue of satisfying the conditions

Removing pointer arithmetic makes it easier to write programs that don't contain memory errors. Removing spurious distinctions between memory blobs that hold the same value makes it easier to program with mathematical functions.

> (because they can be satisfied entirely by removing features you don’t have to use)

Removing features creates a different language. Often a nicer one!

> Maybe you meant “harder to write non-functional programs”.

Nope. That would exclude any general-purpose programming language. Lest you think otherwise: it's very easy to write imperative programs in Haskell and ML.

> The last item in a list of three items is not the second item.

Zeroth, first, second.

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

Erm, yes you can. You don't need "a rock-solid notion" of anything in order to talk about anything. It's certainly nice to have such well-defined concepts/terms, but requiring them is preposterous.

JavaScript doesn't have compound values. This is a fact. When you evaluate the JavaScript expression `{ first: "hello", second: "hello" }`, what you get is a pointer (or reference if you will) to an object with two fields. The object is compound, but the pointer is a primitive, indivisible value.

> The object is compound, but the pointer is a primitive, indivisible value.

So? Is the problem here that you can’t compare objects equivalent according to this with `==`? You can make a comparison to do this properly. (This is why functional programming as a paradigm works better and functional languages are just those where it’s the obvious standard.)

> You can make a comparison to do this properly.

That's not the point! Even if I made a custom equality comparison that says two different objects are “equal”, it would be unsound to treat them as equal, because there exist other constructs in JavaScript that will let me distinguish them. For example, if I mutate one of the objects, the other will remain in its original state. This is exactly why a usable functional language must provide a good notion of compound value!

> Even if I made a custom equality comparison that says two different objects are “equal”, it would be unsound to treat them as equal

I didn't see anyone making claims about soundness. From a Curry-Howard perspective, all JS code is sound: it's unityped, so all programs are proofs of the trivial theorem "true".

From the perspective of equality functions/operators, you're right that it won't be sound; but so what? It's pretty much given that "Javascript foo" is a poor model of "foo", for all values of "foo" (function, integer, boolean, etc.); why should equality make any difference?

Just add "==" and "===" to your list of things to avoid, alongside mutation, random numbers, user input and other things which aren't referentially transparent. To be honest, equality isn't particularly bad if your code has some notion of types/contracts (whether enforced or not); e.g. it's perfectly safe to use "==" when you know that both sides will be strings, for example.

> For example, if I mutate one of the objects, the other will remain in its original state.

Mutation doesn't seem like a great example when discussing (pure) functional programming patterns.

> This is exactly why a usable functional language must provide a good notion of compound value!

You introduction of the term "usable" seems like a moving goalpost/no true scotsman.

> From a Curry-Howard perspective, all JS code is sound: it's unityped, so all programs are proofs of the trivial theorem "true".

Haskell and ML aren't unityped, but, in both, every type is inhabited by expressions. (Caveat: In ML, not all types are inhabited by values, but that doesn't matter, because programs correspond to expressions, not values.) So this doesn't distinguish them from JavaScript.

> From the perspective of equality functions/operators, you're right that it won't be sound; but so what? It's pretty much given that "Javascript foo" is a poor model of "foo", for all values of "foo" (function, integer, boolean, etc.); why should equality make any difference?

Equality matters, because the very first condition to determine whether a procedure computes a function is to see whether it maps equal inputs to equal outputs!

> Just add "==" and "===" to your list of things to avoid, alongside mutation, random numbers, user input and other things which aren't referentially transparent.

That's a different language. Do you know of any good implementations of it? And, FWIW, procedures that compute random numbers are totally fine. You can't rule out procedures that don't compute mathematical functions. You can only keep their use to the minimum necessary.

> To be honest, equality isn't particularly bad if your code has some notion of types/contracts (whether enforced or not); e.g. it's perfectly safe to use "==" when you know that both sides will be strings, for example.

In my day-to-day programming I manipulate more complex data structures than strings.

> Mutation doesn't seem like a great example when discussing (pure) functional programming patterns.

I'm not talking about pure anything. I'm saying that mathematical functions are value mappings, and if the language doesn't let you define compound values (tuples, lists, trees, whatever), then it can only conveniently implement very trivial functions - not enough for practical programming.

> You introduction of the term "usable" seems like a moving goalpost/no true scotsman.

I'm not moving anything. A functional language is one that makes it easy to write functional programs. The lack of compound values means that I'm given two unpleasant choices:

(0) Use Gödel numbers to encode compound values. Would you?

(1) Do imperative programming.

Yes it makes sense for a mathematical function to diverge. You just need to change the domain and range to their "lifted" version. See [https://en.wikibooks.org/wiki/Haskell/Denotational_semantics]

That gives you the <sarcasm>very pleasant</sarcasm> choice of working in a category without sums or tensor products distributing over sums! No thanks.

In practice, Haskellers don't think this way about their programs. Haskell's library ecosystem attests to the fact they think of Hask as some moral analogue of the category of sets, which has both sums and tensor products. And the worst sin a semantics can commit is to not reflect how programmers actually think about their code.