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

91–100 of 154 posts

Re: Callbacks are imperative, promises are functional

#91

Post by chousuke »

gruseom wrote: post #87
TheZenPsycho wrote: post #54

Earlier quoted context omitted.

You are correct that the fact that excel is declarative does not, on its own, make it "functional"... the fact that excel formulas adhere (by the definition of what an excel formula is) to the statelessness, and referential transparency requirements of "first order functions" does make it functional.

But Excel doesn't have first order functions. You can't even define a function in spreadsheet cells, let alone pass one around as a value.

The cells are the functions.

Re: Callbacks are imperative, promises are functional

#92

Post by gruseom »

chousuke wrote: post #91
gruseom wrote: post #87

Earlier quoted context omitted.

But Excel doesn't have first order functions. You can't even define a function in spreadsheet cells, let alone pass one around as a value.

The cells are the functions.

A cell formula defines a computation, but not a function. For it to be a function you have to be able to reuse it (call it as a function) in multiple places.

For example, you can't define the abstraction "square" in Excel. You can compute 2 * 2, A1 * A1 and so on. But there's no way to define a construct which given x produces x * x, then reuse that construct everywhere you want to square things. Everywhere you want to square something, you must inline the computation. That's the absence of functional abstraction.

Re: Callbacks are imperative, promises are functional

#93

Post by dchichkov »

tel wrote: post #76
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…

do f1 Or, if you prefer a list do fs And that seems to be one small example of why you may have already invented monads. I've been loving the impact of Javascript—modify and immediately see it on the browser—but every time I'm not using Haskell I miss it dearly.

Please use more readable names in your code. Use of names like 'fs' in key places makes it unreadable.

Re: Callbacks are imperative, promises are functional

#94

Post by hippobravo »

jewbacca wrote: post #49
hippobravo wrote: post #15

Earlier quoted context omitted.

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…

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.

Re: Callbacks are imperative, promises are functional

#95

Post by schrototo »

dchichkov wrote: post #93
tel wrote: post #76

Earlier quoted context omitted.

do f1 Or, if you prefer a list do fs And that seems to be one small example of why you may have already invented monads. I've been loving the impact of Javascript—modify and immediately see it on the browser—but every time I'm not using Haskell I miss it dearly.

Please use more readable names in your code. Use of names like 'fs' in key places makes it unreadable.

Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").

Re: Callbacks are imperative, promises are functional

#96

Post by ricardobeat »

mjackson wrote: post #81
ricardobeat wrote: post #72

Ryan Dahl in February 2010, when Promises were removed from core: Because many people (myself included) only want a low-level interface to file system operations that does not necessitate creating an object, while many other people want something like promises but different in one way or another. So instead of promises we'll use last argument callbacks and consign the task of building better abstraction layers to use…

> There still isn't a canonical Promises specification. Yes, there is: https://github.com/promises-aplus/promises-spec

Promises/A+ surfaced less than 6 months ago, and is not implemented by most widely-used frameworks. Still a bit far from canonical.

Re: Callbacks are imperative, promises are functional

#97

Post by Derander »

zmmmmm wrote: post #79
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 point is promises free you from wanting or > needing to know about the order that things happen in > ... But the truth is once you embrace them, > that need becomes unimportant This smells like the classic leaky abstraction though. Like when people tried to paper over the difference between remote calls and local calls with abstract interfaces (CORBA, RMI, etc.). Everyone would say it was so awesome, remote cal…

The need for that form of reasoning seems to me to be a symptom of the way that we go about writing code. We don't need to worry about if line 10 executes before line 11 within a given scope -- we just know this. If we come up with a similarly simple way of writing asynchronous operations that have dependencies then we can read it just as fluently.

In my experience, promises do fill this role if they're used in a suitable scenario.

Re: Callbacks are imperative, promises are functional

#98

Post by T-R »

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

Earlier quoted context omitted.

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)

Just plain-old native functions - that's the whole point.

Re: Callbacks are imperative, promises are functional

#99

Post by ww520 »

gruseom wrote: post #92
chousuke wrote: post #91

Earlier quoted context omitted.

The cells are the functions.

A cell formula defines a computation, but not a function. For it to be a function you have to be able to reuse it (call it as a function) in multiple places. For example, you can't define the abstraction "square" in Excel. You can compute 2 * 2, A1 * A1 and so on. But there's no way to define a construct which given x produces x * x, then reuse that construct everywhere you want to square things. Everywhere you want…

The reusability test of function nails it. Thanks for clarifying it. Sometimes we just need to go back to the basic definition to make things clear.

Re: Callbacks are imperative, promises are functional

#100

Post by skrebbel »

schrototo wrote: post #95
dchichkov wrote: post #93

Earlier quoted context omitted.

Please use more readable names in your code. Use of names like 'fs' in key places makes it unreadable.

Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").

> (it also makes it look very "mathematical")

Has that ever been an advantage?

Post reply on HN