4 ms·

I'm not saying his design sense is wrong. I'm saying his characterization of promises as functional is so close to being right that it's the worst kind of wron

I'm not saying his design sense is wrong. I'm saying his characterization of promises as functional is so close to being right that it's the worst kind of wrongness. It's worse to say, "The capital of Kenya is Nairobi Central" than to say "The capital of Kenya is London." It is worse because errors that are only slightly wrong and maybe even partially correct are more deceptive, durable, and confusing. A promise is not a functional concept. Functions don't make promises. You CAN, as a thinking human, re-conceptualize the immutable return value of a function as being "pretty much the same" as a promise, but when you re-conceptualize functional programming you are just deconstructing what is already understood to be an arbitrary conceptual construct. Any conceptual construct--especially one based on simple metaphors--can be deconstructed into some other form. This doesn't invalidate the construct and it doesn't equate the construct as such with the deconstructed components. You might as well say that an airplane is not really an airplane. It's just two wings, a cockpit, some jet engines and a fuselage assembled together in a certain way so that it can fly. It's not really an airplane; it's just those things in that way. And those things are really just all made out of aluminium so really it's not an airplane it's just aluminium. Anyone who says an airplane is more than just aluminium is making a tyrannical dichotomy. So according to you promises are functional because under the hood promises have some conceptual similarity to the immutable return values provided in functional programming. But under the hood the Boeing 737 is just scrap metal. Yet it's NOT just scrap metal. The difference is that "the promise" is a precise concept based on some metaphors that is specifically used in declarative styles and not in functional styles. Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary. If people don't think these high level conceptual distinctions are important, why are they even reading this article that is entirely about splitting hairs between these conceptual distinctions? AND the article is even getting it wrong because the author is a self-admitted amateur. Why bother learning from the village loudmouth when there are geniuses who publish books and give lectures just down the hall? The stuff that reaches the front page of HN makes no sense. Most of it is written by terribly ignorant people. Programmers have no respect for expertise.

jewbacca 14y ago
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 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 14y ago
  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 14y ago
    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/html/Prelude.html#v:const 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.

jewbacca 14y ago

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 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 14y ago
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 14y ago
  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/html/Prelude.html#v:const 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.