Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Callbacks are imperative, promises are functional

blog.jcoglan.com

Post reply on HN
Print view View original

41–50 of 154 posts

Re: Callbacks are imperative, promises are functional

#41

Post by DougBTX »

mbostock wrote: post #32

Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing. If I wanted to compute the size of one file relative to a set, I’d probably do something like this: queue() .defer(fs.stat, "file1.txt") .defer(fs.stat, "file2.txt") .defer(fs.stat, "file3.txt") .awaitAll(functi…

It looks like you're able to return one of those queues from a function and allow some other code to call .await(). Being able to return something is a useful feature of promises too, seems like there might be more overlap there.

Re: Callbacks are imperative, promises are functional

#42

Post by jasondenizac »

mbostock wrote: post #32

Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing. If I wanted to compute the size of one file relative to a set, I’d probably do something like this: queue() .defer(fs.stat, "file1.txt") .defer(fs.stat, "file2.txt") .defer(fs.stat, "file3.txt") .awaitAll(functi…

> I just feel like they might be a bit heavy-weight and a lot of API surface area to solve this particular problem.

The surface area is `.then()`

Re: Callbacks are imperative, promises are functional

#43

Post by jasondenizac »

hippobravo wrote: post #15
ww520 wrote: post #13

I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes. Just like a makefile is not functional but declarative. The dependency of the relationships are enforced to produce action. SQL is another example of declarative language and it is nowhere near as functional.

This was my thought as well. Promises are declarative... making a promise is almost the very definition of declarative programming. 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.

HN comment threads are my favorite learning environment.

Re: Callbacks are imperative, promises are functional

#44

Post by k3n »

crazygringo wrote: post #12

This is an interesting perspective. But to me, even having spent a year on a large node.js project, I just don't see how promises would have simplified things at all. If you have some crazy graph of dependencies, I can see how breaking out promises could help simplify things. But I don't feel like that's a super-common scenario. The author says: > * [Promises] are easier to think about precisely because we’ve delegat…

It's an easy way to avoid race conditions, say you have 2 ajax calls that are required to render your Main view. If either or both of the calls fail, you want to show a Default view.

One answer would be to just do them synchronously, perhaps nesting one of the api calls inside the other's callback (event-handler or otherwise). And then for the Default view, you'd need to have the code that handles the failure in 2 different places (or at least 2 tests for failure).

Another answer would be a state machine which can be grouped and chained (pipe'd) with other similar state machines, to guarantee an order of operations when you need it. With this, you create a promise which is only resolved when both of the promises for the 2 ajax calls are complete, and that promise then pipes the results to the next promise in the chain which renders your view. For the Default view, if either of the ajax calls fail then the parent promise will fail, allowing you to handle the failure in one place.

Code example:

    Deferred.when( ajax1(), ajax2() ).then( /* success */ mainView(), /* fail */ defaultView() );

Re: Callbacks are imperative, promises are functional

#45

Post by ww520 »

erichocean wrote: post #21
ww520 wrote: post #13

I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes. Just like a makefile is not functional but declarative. The dependency of the relationships are enforced to produce action. SQL is another example of declarative language and it is nowhere near as functional.

Excel is not functional. It is declarative. Alan Kay (yes, that Alan Kay[1] -- the guy that's won a Turing award) formalized spreadsheets as a limited form of first-order functional programming.[0] [0] http://en.wikipedia.org/wiki/Spreadsheet#Values [1] http://en.wikipedia.org/wiki/Alan_Kay

With all due respect to Alan Kay, I don't know what he meant by "first order functional programming." If we are talking in relation to high order functions, a high order function is one that can take other functions as parameters or produces functions in return, i.e. a high order function maps functions to functions. All other functions are first order function, i.e. they are ordinary functions mapping values to values.

In that case any languages supporting function is "first-order functional programming." It's kind of meaningless when we are talking about real functional languages. PHP can define a function that takes a value and returns a value, and thus it can do "first-order functional programming." But no one claims PHP is a functional language. (Not to degrade PHP, it's a good language doing what it does best.)

All these twisting the definition of functional programming just produce more confusion.

Re: Callbacks are imperative, promises are functional

#46

Post by TheZenPsycho »

T-R wrote: post #39
TheZenPsycho wrote: post #23

Earlier quoted context omitted.

The point is promises free you from wanting or needing to know about the order that things happen in. I hear you saying you fear promises, because it means it would get in the way of your ability to know that. But the truth is once you embrace them, that need becomes unimportant. The idea that webservers are "all about side effects" gives me a chill. The whole architecture concept of HTTP is no side effects , so to c…

I think his point is that there's usually a very strict ordering to the events on an HTTP server - you parse and sanitize your input, make some database calls, and generate a response - at best, letting something else do the sequencing and composition for you doesn't gain you much, as it might in a reactive GUI. At worst it leaves room for subtle bugs or code that's less clear (arising from the statefulness of the Pr…

What kind of object is in your list of async operations? promises. (though probably your own ad hoc, hand rolled and poorly specified version of them)

Re: Callbacks are imperative, promises are functional

#47

Post by TheZenPsycho »

rtfeldman wrote: post #40
TheZenPsycho wrote: post #23

Earlier quoted context omitted.

The point is promises free you from wanting or needing to know about the order that things happen in. I hear you saying you fear promises, because it means it would get in the way of your ability to know that. But the truth is once you embrace them, that need becomes unimportant. The idea that webservers are "all about side effects" gives me a chill. The whole architecture concept of HTTP is no side effects , so to c…

> The idea that webservers are "all about side effects" gives me a chill. The whole architecture concept of HTTP is no side effects, so to claim that it's all about side effects seems odd. It should only be the case for POST PUT or DELETE methods, and only in very specific ways. There's nothing incongruous about that. It is the case that side effects should only happen on POST, PUT, and DELETE methods (and the like),…

I'm not arguing about that, I am arguing about "all"

Re: Callbacks are imperative, promises are functional

#48

Post by threedaymonk »

steveklabnik wrote: post #3

> If foo takes many arguments we add more arrows, i.e. foo :: a -> b -> c > means that foo takes two arguments of types a and b and returns something of > type c. Nitpick alert: since everything is curried in Haskell, it's actually more like `foo takes an argument a and returns a function that takes one b and returns one c`. Other than that teeny thing, this article is awesome, and I fully agree. Promises are an exce…

> Nitpick alert: since everything is curried in Haskell, it's actually more like `foo takes an argument a and returns a function that takes one b and returns one c`.

Whilst that's true, and is important to the way in which Haskell operates, people normally talk about functions as taking multiple arguments (at least, the people at London HUG, most of whom are better Haskellers than I, seem to).

Even ghci refers to the "second argument":

    Couldn't match expected type `Int' with actual type `Char'
    In the second argument of `foo', namely 'b'
    In the expression: foo 1 'b'
    In an equation for `it': it = foo 1 'b'

Re: Callbacks are imperative, promises are functional

#49

Post by jewbacca »

hippobravo wrote: post #15
ww520 wrote: post #13

I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes. Just like a makefile is not functional but declarative. The dependency of the relationships are enforced to produce action. SQL is another example of declarative language and it is nowhere near as functional.

This was my thought as well. Promises are declarative... making a promise is almost the very definition of declarative programming. 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.

A tyrannical dichotomy.

Functional programming is declarative. Especially when it's lazy and the program's instantaneous state is abstracted out. One of the motivating goals in functional programming is to be able to define a computation once, in terms of other computations, and have that relationship be maintained with minimal regard to the state of the program or its order of execution. Which is what it seems like (this is the first time I've specifically encountered them) Promises are a powerful tool for accomplishing.

In contrast, threading explicit callbacks/continuations through a program, which is explicitly managing the order of execution, is relatively more imperative, which I think is the point of the article -- you don't need the wider control-flow flexibility of explicitly and manually threading callbacks to do the type of computations that most async web stuff does. You can abstract the common callback pattern out into something like Promises, and make all your shit more consistent and concise.

Re: Callbacks are imperative, promises are functional

#50

Post by ww520 »

TheZenPsycho wrote: post #37
ww520 wrote: post #35

Earlier quoted context omitted.

Following that logic, OO is an orthogonal attribute to functional. Both of them can define functions, and thus OO is functional.

First of all, that's not what "functional" means. Second, OO is an orthogonal attribute to functional. Third, your argument commits a formal fallacy of this form: All cats have whiskers Cats can have stripes Tony has stripes therefore tony is a cat. ---The possibility of an attribute in X, and Y containing that attribute does not imply that Y is an X. the point is that whether something is declarative has no bearing…

Ok. I misread what you wrote in my haste and misunderstood what you said. You can ignore my reply to your original comment.

However, my original point was addressing the claim in the blog that functional and declarative are equivalent in that functional has aspect of declarative. And since Excel is declarative, it's functional. I was basically saying that's not the case.

While declarative and functional can be orthogonal, and can both live in a language is an interesting but separate topic that is not really related to the original comment.

Post reply on HN