Live data from Hacker News

Callbacks are imperative, promises are functional

blog.jcoglan.com

61–70 of 154 posts

Re: Callbacks are imperative, promises are functional

#61
post #57

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];

I agree, I was going to ask the same question. Unless there's some subtlety that I'm missing, the order you propose makes much more sense.

Re: Callbacks are imperative, promises are functional

#62
post #4

" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.

> Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed.

Sure, but there were languages back then that made programming with callbacks more pleasant due to features like coroutines or first class continuations. While these might not have been on the radar for most Javascript developers the technology certainly existed back then.

Re: Callbacks are imperative, promises are functional

#63
post #58

Earlier quoted context omitted.

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

Another point to make is that the "Excel is functional" meme is so useful is because, as soon as you tell most programmers that "functional programming" has no variables, no state, and no side-effects, they can't imagine how it's possible to actually do anything useful in a functional language. On the other hand, most programmers do know how to do useful things in a spreadsheet program- which happens to be effectively equivalent to a stateless side-effect free "pure" functional programming language.

Re: Callbacks are imperative, promises are functional

#64
post #52

Earlier quoted context omitted.

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

Thank you for clarifying! I did not know that all functions in Haskell are considered curried. My surprise stemmed in part from reading a bit about "arity" from [1].

It's interesting how the theoretical model of Haskell--"all functions in Haskell take just single arguments"--differs from implementation, where, for functions of known arity, GHC in particular does not actually "follow the currying story literally" [2].

[1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Hask...

[2] http://community.haskell.org/~simonmar/papers/eval-apply.pdf

Re: Callbacks are imperative, promises are functional

#65
post #64

Earlier quoted context omitted.

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

Thank you for clarifying! I did not know that all functions in Haskell are considered curried. My surprise stemmed in part from reading a bit about "arity" from [1]. It's interesting how the theoretical model of Haskell--"all functions in Haskell take just single arguments"--differs from implementation, where, for functions of known arity, GHC in particular does not actually "follow the currying story literally" [2].…

Any time. It's one of the more interesting parts of Haskell to me, so it's one I always remember.

You're absolutely right to point out that implementations and theory often differ; compilers often do tricky things behind the scences.

Re: Callbacks are imperative, promises are functional

#66
post #57

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];

I'm glad someone else thought that looked odd.

Re: Callbacks are imperative, promises are functional

#67

Earlier quoted context omitted.

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

Another point to make is that the "Excel is functional" meme is so useful is because, as soon as you tell most programmers that "functional programming" has no variables, no state, and no side-effects, they can't imagine how it's possible to actually do anything useful in a functional language. On the other hand, most programmers do know how to do useful things in a spreadsheet program- which happens to be effectivel…

That's kind of false advertisement. Excel (or spreadsheet in general) is great and easy to use because of declarative programming, not because of functional programming. The functional programming aspect of it is minimal. No variables, no state, and no side-effects are mainly attribute of declarative programming.

The most important aspect of being functional, high order function, is completely missing.

Re: Callbacks are imperative, promises are functional

#69

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…

>> but reading files in parallel would presumably be slower since you'd be jumping around on disk

There is a lot of engineering that goes into making parallel reads go fast. Some combination of the file system and disk controller will probably be smart enough to recognize the opportunity for sequential reads and execute them as such if possible.

This is not always true, and it does not undermine the rest of what you have written. I just think it's interesting to keep in mind that operating systems implement a lot of helpful machinery that user-level programmers forgot about.

Re: Callbacks are imperative, promises are functional

#70
post #67

Earlier quoted context omitted.

Another point to make is that the "Excel is functional" meme is so useful is because, as soon as you tell most programmers that "functional programming" has no variables, no state, and no side-effects, they can't imagine how it's possible to actually do anything useful in a functional language. On the other hand, most programmers do know how to do useful things in a spreadsheet program- which happens to be effectivel…

That's kind of false advertisement. Excel (or spreadsheet in general) is great and easy to use because of declarative programming, not because of functional programming. The functional programming aspect of it is minimal. No variables, no state, and no side-effects are mainly attribute of declarative programming. The most important aspect of being functional, high order function, is completely missing.

From Wikipedia[0]:

Common declarative languages include those of database query languages (e.g., SQL, XQuery), regular expressions, logic programming, and functional programming.

I guess you're both right then. :)

[0] http://en.wikipedia.org/wiki/Declarative_programming

Post reply on HN