story
You define promise:
>A "promise" is a delayed computation. It's a stand-in for a value, and the computation referencing it will suspend its execution until a value is available for it to consume.
I define promise:
>A "promise" is a declaration or assurance that one will do a particular thing or that guarantees that a particular thing will happen.
My definition of promise is conceptually and formally more accurate than yours, because your definition raises issues like "what is a computation" and "what is a value" and "what is a stand-in" and "what is execution" and "what does consume mean"
As programmers, we understand what these words mean concretely in terms of lower-level abstractions or in some cases actual hardware operation.
My point is that the declarative ideal that you reference is not defined in terms of lower level programmer abstractions, but rather in terms of natural conceptual metaphors.
Since functional programming is generally seen as a subset of declarative programming, it's natural that functional programmers use declarative concepts and it's even understandable that they call those concepts functional. But they're mixing metaphors and creating conceptual confusion. They're losing track of the original metaphors that draw hair-splitting analytic distinctions between concepts in order to create clarity. It's semantics.
Like I already said, I'm not criticizing his design sense and I'm not criticizing yours. I'm criticizing his and your use of language and I'm asserting that your language is degraded and impure.
To me, aside from the design advice he gives, his blog post is about drawing semantic distinctions. I just find the way he does this to be horribly flawed in a way is "so close to being right that it's the worst kind of wrong."
Similarly, I would describe your definition of promise in this way. So close to being right that it's the worst kind of wrong. Your definition of promise is not a definition; it's a deconstruction. It's actually an imperative deconstruction--you're describing the promise using imperative language--concepts like execution and computation.
HN is full of very "practical" people who have a view that goes something like, "I'm correct enough for this to WORK, I'm correct enough to get the correct answer, therefore I'm correct." It's a reductionist view of truth; that which I can deconstruct, I understand. I don't share this view.
I would say, you ARE correct, but you're not as correct as you could be. Likewise with the author.
When I want to learn about the distinction between declarative paradigms and functional paradigms I talk to people who specialize in drawing that distinction. Since the blog post is prima facie drawing a distinction between functional and imperative, the value I'm looking for is an analytically rigorous distinction between abstract concepts.
That's not what I found, so I'm critical. Sorry. This just isn't the author's area of expertise and it shows. Perhaps most of his readers don't care. More power to them. But if you want to engage in intellectual life you can't throw down the gauntlet every time someone criticizes you.
