Live data from Hacker News

Callbacks are imperative, promises are functional

blog.jcoglan.com

21–30 of 154 posts

Re: Callbacks are imperative, promises are functional

#21
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

Re: Callbacks are imperative, promises are functional

#23

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…

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

Re: Callbacks are imperative, promises are functional

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

declarative is an orthogonal attribute to functional. The two attributes are not mutually exclusive. You may as well say something like: "A bicycle isn't a vehicle at all! A Bicycle is a metallic object!"

Re: Callbacks are imperative, promises are functional

#26

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…

"Web server programming is entirely about side-effects" is not terribly interesting, when observing current common practice: if it's typically callback driven, there's nothing else it can be about.

Re: Callbacks are imperative, promises are functional

#27
post #22

[deleted]

This is a ridiculous attitude. Do you laugh at the concept of "complex" and "imaginary" numbers because a group of these so called "mathematicians" have apparently arbitrarily decided to call some numbers imaginary? RIDICULOUS! LAUGHABLE!

Re: Callbacks are imperative, promises are functional

#28
post #17

All the code and such a big abstraction for the first example when it could have done like this: var result = []; paths.forEach(function (i, file){ fs.stat(file, function (err, data){ result.push(data); if (i === 0) { // Use stat size } if (result.length === paths.length) { // Use the stats } }); }); Fairly understandable, more efficient and without introducing logic patterns foreign to many. It also meet his require…

To be fair, you haven't handled the complete case. What if one of the items fails? You need to handle the error, but only if it's the first error, and make sure to tell all later-called callbacks that they're too late and we have already failed. Except, if we got an error on an early callback but the 0th item comes back later, we need to do whatever we were going to do with that one piece of data. var result = []; va…

The example I'm talking about is the one where he doesn't handle errors either, this one: http://pastebin.com/98CarwzU.

And your example is disingenuous too, why do we need to add so much logic instead of collecting the errors if you want to handle them anyway?

    result.push(err || data);
So you don't need to copy around a variable called "hasFail", one line can be enough

    var failed = results.every(Buffer.isBuffer);

Re: Callbacks are imperative, promises are functional

#29

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…

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…

As someone who's started moving from the imperative world, albeit in Java, C# and Ruby based work rather than JavaScript, I can say that letting go is the hardest part.

However, when you learn to stop worrying and let the runtime decide it's so much nicer. It turns out that people have already optimised the framework, so at worst it's just as fast as the code I wrote. At best it's faster because the framework knows more about what it's capable of.

The biggest thing to realise is that while you can easily make things perform well in isolation the runtime can look at the bigger picture. There's no point making an operation run in 300ms if it blocks all other tasks on the server, when it could run in 600ms and allow everything else to keep going.

Re: Callbacks are imperative, promises are functional

#30

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…

I've read a few other blog posts about Promises in the past months, and also was never convinced. Maybe I never read the good ones, because this is the first one that made me sit up a bit in my chair and think that this is really pretty cool. I thought it was really well written and quite illuminating.
Post reply on HN