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

51–60 of 154 posts

Re: Callbacks are imperative, promises are functional

#51

Post by TheZenPsycho »

ww520 wrote: post #45
erichocean wrote: post #21

Earlier quoted context omitted.

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 valu…

What most C derivative programming languages call a "function" is not actually a "function" in the sense meant in "functional programming". It is more accurately called a "procedure". While you can write a "functional function" in php, there's nothing inherent about php's "functions" that makes them "functional". it's up to the programmer to make them so.

On the other hand, a "formula" in excel is inherently a "functional" function or "first order function". Why? two things: No side effects, and statelessness- that is, the order of the computation is theoretically implicit: a value can be computed in a number of different arbitrary orders without effecting the final result.-- not explicit- like in php, where you are specifying an exact order of operations by the order of statements in a procedure ("function").

Another thing about statelessness is that given the same input, a "first order function" must always return the same output.

The fact that order is not explicit in excel, that there is no user controlled "state" means that there's certain associative, commutative and compositional properties available to "first order" functions that are not possible with a procedure that is not guaranteed to be a first order function.

it's the difference between deciding to do functional programming in an imperative language, and having functional programming structurally enforced by the language.

Re: Callbacks are imperative, promises are functional

#52

Post by andrus »

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…

Really? Consider

    f :: a -> b -> a
    f a = g a
    
    g :: a -> b -> a
    g a _ = a
It doesn't seem right to say that g "returns a function that takes one b", whereas you could say that about f.

Re: Callbacks are imperative, promises are functional

#53

Post by Jare »

jQueryIsAwesome wrote: post #31
Jare wrote: post #20

Earlier quoted context omitted.

> without introducing logic patterns foreign to many Consider your use of the forEach() abstraction when you could have used a for() loop just as easily. (That said, I agree the article in general could do a better job of describing the "other" side)

Nope, the shared scope would obligate me to create a function with binded params for each iteration so "i" is not the last value (e.g. path.length) in every call. Examples: http://stackoverflow.com/questions/1451009/javascript-infamo...

Exactly, one of the advantages of using a good abstraction like forEach() is that it prevents you from making that kind of mistake. On the other hand, it can be more costly in cases where you don't need the closure. All abstractions by definition have some tradeoffs, some visible or hidden complexity, and some extra knowledge. Promises are no different.

Re: Callbacks are imperative, promises are functional

#54

Post by TheZenPsycho »

ww520 wrote: post #36
gngeal wrote: post #19

Earlier quoted context omitted.

"Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes." Whereas in functional languages, the functions declare relationships between values and the language uses the evaluation model to propagate the results between function evaluation. Where's the difference?

Functional language has the declarative aspect while declarative language lacks the functional aspect. Just because A => B doesn't mean B => A.

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.

Re: Callbacks are imperative, promises are functional

#55

Post by steveklabnik »

andrus wrote: post #52
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…

Really? Consider f :: a -> b -> a f a = g a g :: a -> b -> a g a _ = a It doesn't seem right to say that g "returns a function that takes one b", whereas you could say that about f.

Yes. http://www.haskell.org/haskellwiki/Currying

Re: Callbacks are imperative, promises are functional

#56

Post by steveklabnik »

threedaymonk wrote: post #48
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…

Of course, hence the 'nitpick alert' and admission that it doesn't really affect anything in the text, just a detail about how things work.

Often, conversations are not held to absolute rigor. Not every off-handed statement is absolutely consistent.

Re: Callbacks are imperative, promises are functional

#57

Post by graue »

This code doesn't look right to me:

    // list :: [Promise a] -> Promise [a]
    var list = function(promises) {
      var listPromise = new Promise();
      for (var k in listPromise) promises[k] = listPromise[k];
Perhaps the assignment is supposed to be the other way around?

      for (var k in promises) listPromise[k] = promises[k];

Re: Callbacks are imperative, promises are functional

#58

Post by ww520 »

TheZenPsycho wrote: post #51
ww520 wrote: post #45

Earlier quoted context omitted.

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 valu…

What most C derivative programming languages call a "function" is not actually a "function" in the sense meant in "functional programming". It is more accurately called a "procedure". While you can write a "functional function" in php, there's nothing inherent about php's "functions" that makes them "functional". it's up to the programmer to make them so. On the other hand, a "formula" in excel is inherently a "funct…

The "pure" functions are just a subset of "procedure" functions. One can always restrict to use the "pure" function in PHP and yes, that's "first-order functional programming" in PHP. The question is: do we call PHP a functional language?

Likewise, Excel can do stateful update with side effect. The cell formula function happens to be a subset of all it can do. Sure, we can claim it's "first-order functional programming." But do we want to call it a functional language?

My point is that "first-order functional programming" is a really weak qualifier to call a language functional.

Re: Callbacks are imperative, promises are functional

#59

Post by TheZenPsycho »

ww520 wrote: post #58
TheZenPsycho wrote: post #51

Earlier quoted context omitted.

What most C derivative programming languages call a "function" is not actually a "function" in the sense meant in "functional programming". It is more accurately called a "procedure". While you can write a "functional function" in php, there's nothing inherent about php's "functions" that makes them "functional". it's up to the programmer to make them so. On the other hand, a "formula" in excel is inherently a "funct…

The "pure" functions are just a subset of "procedure" functions. One can always restrict to use the "pure" function in PHP and yes, that's "first-order functional programming" in PHP. The question is: do we call PHP a functional language? Likewise, Excel can do stateful update with side effect. The cell formula function happens to be a subset of all it can do. Sure, we can claim it's "first-order functional programmi…

You can do "Object Oriented programming" in C++. you can also do "OOP" in plain C, but why do we call C++ an "OO Language" but not C? because the design of the language itself encourages and enforces a particular style of "OOP".

In this case, I believe the "Excel is a functional language" meme is using "Excel" not to include ALL the things that excel does, which includes things like VB and Javascript scripting, but as shorthand for the spreadsheet model of application, and more specifically aimed at Excel's formula language, which enforces the creation of first order functions by excluding the possibility of state-fulness and side-effects from the language's design. It is the fact that this is inherent in its design that merits calling it a functional language, while in php there are no such design choices which enforce or even encourage a functional way of writing code.

Re: Callbacks are imperative, promises are functional

#60

Post by tmarthal »

k3n wrote: post #44
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 di…

In POSIX thread programming the "state machine" that you talk about is commonly called a Condition Variable. https://computing.llnl.gov/tutorials/pthreads/#ConVarOvervie...
Post reply on HN