[jewbacca]

Okay, if you require an appeal to authority, here is Oleg Kiselyov deriving Iteratees in Haskell, a more general formalization of "futures"/"promises": http://okmij.org/ftp/Streams.html

If you insist on setting up semantic games: if Oleg hacking Haskell isn't functional programming then nothing meaningfully is.

----

> Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary.

What does `foldr (+)` return? What about `const 1`?

[hippobravo]

The distinction between functional and imperative is precisely a semantic game and nothing else.

Semantic games are meaningful or this blog post wouldn't be on HN. The title of the post makes it clear that we're playing a semantic game.

Kiselyov is deconstructing the constructs. That's fine. He's playing the semantic game of showing how different concepts share ontology. This doesn't make the concepts identical; it makes their deconstructions identical. These paradigms are not physical things they are conceptual abstractions. Anyway I'm obviously not getting through to you.

const is not a promise, it's a constant. Different concepts, similar ontology.

[jewbacca]

I'm not sure we have the necessary language in common to communicate here. Functional programming is not just about stateless pure functions, it's also about composing computations. I'm curious if you've ever written in a natively lazy functional language like Haskell, or encountered `delay`/`force` promises in Scheme. The `const` I'm referring to is not the `const` of C et al: (http://hackage.haskell.org/packages/archive/base/latest/doc/...) and is just an example.

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. Similarly with Iteratees. They encapsulate specific patterns for building computations out of other computations.

What makes the "promise" pattern relatively less imperative than threading callbacks is that it abstracts out a specific pattern for ordering a computation, so that it doesn't need to be restated every time.

What makes the "promise" pattern relatively less declarative than "purely declarative" is that the control of the computation can be specified in the language itself. It's just abstracted out to the pattern in common. Similarly to re-writing certain stateful `for` loops with `map`.

Promises are a pattern in the functional programming paradigm. The "functional programming community" is where the construct comes from, and using them lets you write code that is closer to the declarative ideals of functional programming than the article's specified alternative, threading callbacks, which has relatively more in common with the explicit control of the order of computation that is implied by imperative programming.

I don't see anything in the article that remotely justifies "It's not functional at all. This reaffirms my belief that blog posts are a terrible place to learn. People who know the least shout the loudest.". In fact, I don't see anything wrong with it at all, or anything that substantially disagrees with what I've said or what I've seen any of the type of (yet-unspecified) authorities of certified expertise that you've appealed to have said. Yes, Promises are relatively more declarative, but they're also relatively more functional, relatively less imperative, and I don't see any basis for calling somebody an idiot for not using those terms with total mutual exclusion.

So please, raise, any specific objections you have which I have not addressed, or else have the honesty to retract the undeserved insults you've thrown at the author of this article.

[hippobravo]

You're defining a promise in terms of what is "under the hood." You actually define promise in terms of what-the-hardware-does. This demonstrates the varying levels of abstraction that we're operating at.

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.

[jewbacca]

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

Who specializes in making that distinction? Point me in the right direction. I am absolutely throwing down the gauntlet, I don't believe for a second you know what you're talking about, and I suspect that your understanding of functional programming does not include the possibility of functions returning functions, and the term "thunk" would be lost on you. If you're going to put so much weight on expertise, please point me in the direction of the researcher who you suspect would take the author of this article to task for his terminology. Or make a positive argument yourself.

"Promise" here refers to a specific computation strategy, it has a well-documented intellectual heritage and has been defined as a lambda calculus. It has its basis in the structuring of computations. With how you've constructed this ontology, I don't see any room for "functional programming" to mean anything at all.

I suppose that does leave a lot of room for calling the OP "the village loudmouth" for having any actual content behind his words.

[hippobravo]

Well, you're right that I'm an asshole. And you're right that I'm not inline with your discipline.

I'm just inline with my own discipline where promise has a different meaning, a super ordinate meaning that includes your meaning. As a consequence, anyone from your discipline just thinks I'm clueless. I'm definitely not going to convince you that the typical definition of promise, the one you're used to, is actually just an operational definition--an instrumental label assigned to a particular instance of a promise-like thing.

I'd cite the tiny field of cranks who think like me, but that would just bring shame on them by association. I'm not doing research in functional programming. I'm working on hair-splitting tyrannical distinctions-without-a-difference. According to your paradigm, I'm an outright fraud spouting bullshit. So enjoy your victory I guess.