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];
Callbacks are imperative, promises are functional
61–70 of 154 posts
Re: Callbacks are imperative, promises are functional
#62" 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.
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
#63Earlier 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…
Re: Callbacks are imperative, promises are functional
#64Earlier 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
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
#65Earlier 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].…
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
#66This 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
#67Earlier 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…
The most important aspect of being functional, high order function, is completely missing.
Re: Callbacks are imperative, promises are functional
#68Re: Callbacks are imperative, promises are functional
#69Not 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…
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
#70Earlier 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.
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. :)