Callbacks are imperative, promises are functional
blog.jcoglan.com
blog.jcoglan.com
We actually extracted our promises implementation from the work we've been doing, and released it as RSVP.js[1]. While other JavaScript promises libraries are great, we specifically designed RSVP.js to be a lightweight primitive that can be embedded and used by other libraries. Effectively, it implements only what's needed to pass the Promises/A+ spec[2]. For a comparison of RSVP.js with other promises-based JavaScript asynchrony libraries, see this previous discussion on Hacker News[3].
1: https://github.com/tildeio/rsvp.js
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(function(error, stats) {
if (error) throw error;
console.log(stats[0].size / stats.reduce(function(p, v) { return p + v.size; }, 0));
});
var q = queue();
files.forEach(function(f) { q.defer(fs.stat, f); });
q.awaitAll(…); // as before
A related question is whether you actually want to parallelize access to the file system. Stat'ing might be okay, but reading files in parallel would presumably be slower since you'd be jumping around on disk. (Although, with SSDs, YMMV.) A nice aspect of queue-async is that you can specify the parallelism in the queue constructor, so if you only want one task at a time, it’s as simple as queue(1) rather than queue(). This is not a data dependency, but an optimization based on the characteristics of the underlying system.
Anyway, I actually like promises in theory. I just feel like they might be a bit heavy-weight and a lot of API surface area to solve this particular problem. (For that matter, I created queue-async because I wanted something even more minimal than Caolan’s async, and to avoid code transpilation as with Tame.) Callbacks are surely the minimalist solution for serialized asynchronous tasks, and for managing parallelization, I like being able to exercise my preference.
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.
do f1 <- fsStat "file1.txt"
f2 <- fsStat "file2.txt"
f3 <- fsStat "file3.txt"
let ratio = (size f1) / (sum $ map size [f1, f2, f3])
print ratio
do fs <- mapM fsStat files
let ratio = (size . head $ fs) / (sum . map size $ fs)
print ratio
Perhaps people don't spot the link as easily because monads are usually explained in terms of a type system, and javascript is untyped? (Or perhaps just because Monad is a very abstract abstraction :)
Has that ever been an advantage?
EDIT:
I'm not implying it's useful just for programming "math stuff", after all, everything can be reduced to a mathematical problem - including game engines[1], web application frameworks[2], etc.
[1] http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf [2] https://github.com/yesodweb/yesod
In Haskell, if you see a short name, look up and down 3 lines for the definition. If you can't find it then complain.
Well... more power to python, and culture that embraces 'what your see is what your get' and super-readable code.
map f [] = []
map f (x:xs) = f x : map f xs
Compare:
map f [] = []
map f (x:xs) = f x : map f xs
map f xs = [f x | x <- xs]
map = lambda func, iterable: [func(x) for x in iterable]
First one requires looking up and down in order to understand what is going on. Second one is better, context is limited to one line. And the last one doesn't require you to remember context at all.
map f xs = [f x | x <- xs]
I find the python version hardest to read (even though it's also "cheating"), which is largely because both the identifiers and the control constructs are alphabetic.
[func(x) for x in iterable]
[call func x for x in iterable]
[f x | x <- iterable]
The only other thing is that because "iterable" is such a long word I expect it to be an identifier imported from a library or somewhere else in the program, and certainly not earlier in the line.
In summary, I think a lot of what we find "readable" depends on what we are used to.
I think a general rule is that source code readability is inverse to the amount of context information that one needs to remember in order to interpret and understand the code.
If you can look at the code at any place (and at any scale, ranging from a single line to the whole call graph), and without any context understand what is happening at this particular place - code is readable. And on the opposite, if you need to know a lot about the context of each particular line of code - code is unreadable.
In C or C++ this newer was the case, because type information was never implied (until recently, when auto was introduced). And in dynamic languages, like Python, this is also almost never the case, because good mainstream developers use object names consistently.
In the functional world however, mainstream (if there is any mainstream, as I often see each developer working in his/her own unique style) folks just say phrases like 'true documentation comes from the types' and write their recursions freely, and with no regard to the reader.
So yes. We'll have to agree to disagree.
[1] http://hackage.haskell.org/package/abstract-par/ [2] http://hackage.haskell.org/package/monad-par/
The surface area is `.then()`
var queue = new Promises;
fs.stat("file1.txt", queue.cb());
fs.stat("file2.txt", queue.cb());
fs.stat("file2.txt", queue.cb());
queue.all()
.then()
.fail();
pub.on('foo', function() {
promise1.fulfill();
});
pub.on('bar', function() {
promise2.fullfill();
});
Vow.all([promise1, promise2]).then(...).fail(...); > 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.
Other than that teeny thing, this article is awesome, and I fully agree. Promises are an excellent thing, and while I'm just getting going with large amounts of JavaScript, they seem far superior to me.
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 "second argument":
Couldn't match expected type `Int' with actual type `Char'
In the second argument of `foo', namely 'b'
In the expression: foo 1 'b'
In an equation for `it': it = foo 1 'b'Often, conversations are not held to absolute rigor. Not every off-handed statement is absolutely consistent.
f :: a -> b -> a
f a = g a
g :: a -> b -> a
g a _ = a
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
You're absolutely right to point out that implementations and theory often differ; compilers often do tricky things behind the scences.
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 delegated part of our thought process to the machine. When using the async module, our thought process is:*
> A. The tasks in this program depend on each other like so,
> B. Therefore the operations must be ordered like so,
> C. Therefore let’s write code to express B.
> Using graphs of dependent promises lets you skip step B altogether.
But in most cases, I don't want to skip B. As a programmer, I generally find myself preferring to know what order things are happening in. At most, I'll parallelize a few of database calls or RPC's, but it's never that complex. (And normal async-helper libraries work just fine.)
I swear I want to wrap my head around how this promises stuff could be useful in everyday, "normal" webserver programming, but it just always feels like over-abstraction to me, obfuscating what the code is actually doing, hindering more than helping. I want to know, specifically, if one query is running before another, or after another, or in parallel -- web programming is almost entirely about side effects, at least in my experience, so these things often matter an awful lot.
I'm still waiting for a real-world example of where promises help with the kind of everyday webserver (or client) programming which the vast majority of programmers actually do.
> Getting the result out of a callback- or event-based function basically means “being in the right place at the right time”. If you bind your event listener after the result event has been fired, or you don’t have code in the right place in a callback, then tough luck, you missed the result. This sort of thing plagues people writing HTTP servers in Node. If you don’t get your control flow right, your program breaks.
I have literally never had this problem. I don't think it really plagues people writing HTTP servers. I mean, you really don't know what you're doing if you try to bind your event listener after a callback has fired. Remember, callbacks only ever fire AFTER your current imperative code has finished executing, and you've returned control to node.js.
Promises make async code easy to manage, even at scale. Each API request gets its own promise. What happens inside that promise doesn't matter, as long as it returns a result or an error. If talking to the API takes one request or two, it does not matter with promises. We can abstract these API requests in such a way that even if document retrieval is a multi-step process or a one-step process for each document source, the collation process can know nothing about the retrieval process to work.
In other words, promises allow us to separate concerns. Document retrieval is one concern, collation another. Promises, by abstracting asynchronous control flow into synchronously appearing objects, allow us to write simple programs at higher levels. Separating concerns makes the server easier to test and easier to extend.
If you want to see how I've used promises, you can take a look at my work on Github [2].
Other programming languages have this too. They're called a 'METHOD'. Sorry, couldn't resist.
On a serious note, look at your code in here:
https://github.com/fruchtose/muxamp/blob/master/lib/playlist...
And look at your 'playlistCount' function on line 39 (which for no apparent reason you've made a variable).
Now I can't understand how a promise there is helping your programming. In fact it seems to have vastly increased the complexity of the code and it is now completely unclear from a quick scan how the method works, what the program flow actually is.
It should be a much shorter function, literally just this:
function playlistCount(){
return db.query('SELECT COUNT(id) AS count FROM Playlists;', function(rows) {
return parseInt(rows[0]['count']);
});
}
28 LINES. HOW? For a simple COUNT!
Actually to be fair to promises, 50% of the problem here is that you've not abstracted your db code and unnecessarily repeat boiler plate connection code again and again and again.
But a big part of the problem is that you can't just throw an exception and let it bubble up the stack, you're constantly having to baby sit the code, and that is the promises fault.
(unrelated, but as a mini-code review though I've never used node.js but the oft repeated line of `dbConnectionPool.release(connection);` in the connection failure code is an immediate code smell to me, it looks like rain dance code, why would you have to release a failed connection? It failed, how can it be released?)
I'm thinking of something like the below as a dbHelper class.
Note I'm passing the error messages into the deferred reject method rather than using console logging. I'm not sure if the q API supports that as you don't, but if it doesn't that seems like a bit of an odd design decision by the library authors, how else are you supposed to pass errors back? Unless I'm misunderstanding promises. If you want to have console logging of failed defers I would recommend either editing the source of Q or monkey patching the reject method to do it automatically.
It's also worth noting I am deliberately not checking rows length, etc. You should let exceptions do what they're supposed to do as something very serious has gone wrong if rows.length == 0 or rows[0] is null or rows[0]['count'] doesn't exist. A SELECT COUNT should always return 1 row and if you've named the column it should definitely be there.
//this is totally untested code to show the idea of
//how you should abstract the boilerplate from your code
var dbHelper = function() {
var db = require('./db'),
Q = require('q');
var dbHelperInner = {
query : function(query, onComplete) {
var dfd = Q.defer();
try {
var cmd = new DbCommand(dfd);
cmd.execute(query, onComplete);
} catch(e) {
dfd.reject(e);
}
return dfd.promise;
}
}
function DbCommand(dfd) {
if (!db.canRead()) {
throw "db unavailable";
}
this.dfd = dfd;
}
DbCommand.prototype.execute = function(query, onComplete) {
var self = this;
dbConnectionPool.acquire(function(acquireError, connection) {
if (acquireError) {
self.dfd.reject(acquireError);
return;
}
connection.query(query, function(queryError, rows) {
if (queryError) {
self.dfd.reject(queryError);
} else {
try {
self.dfd.resolve(
onComplete(rows));
} catch (e) {
self.dfd.reject(e);
}
}
dbConnectionPool.release(connection);
});
});
}
return dbHelperInner;
}();
//and then you could use it like this
//which is almost identical to the code I posited above
function playlistCount(){
return dbHelper.query('SELECT COUNT(id) AS count FROM Playlists;', function(rows) {
return parseInt(rows[0]['count']);
});
}You're right that 28 lines is pretty ridiculous, but it's because I never abstracted out that code. The playlist code is some of the ugliest in that project, because I got pretty lazy with it. I know it's terrible. The console logging stuff is part of that.
Q actually allows exceptions to cause promise rejections, which is both a nifty feature and a potential curse (e.g. throwing an exception before releasing a resource).
I like the changes you propose (not considering testing), but with slightly different implementation. the DbCommand should be creating its own deferreds, rather than accepting one as a parameter. This kind of promise handling is best left up to DbCommand to implement, rather than the caller. In Q it's easy to chain promises, like so:
Q.fcall(someFunction).then(function(result) {
return functionThatReturnsAPromise();
}).then(function(secondResult) {
console.log(secondResult);
}).done();
DbCommand.prototype.execute = function(query, onComplete) {
var self = this;
Q.denodeify(dbConnectionPool.acquire).then(function(connection) {
self.connection = connection;
return Q.denodeify(connection.query);
}).then(function(rows) {
return onComplete(rows);
}).finally(function() {
self.connection && dbConnectionPool.release(self.connection);
}).done();
};
However, I am not sold on the idea of creating a prototype for DB commands. There's no state that needs to be held, and the code is abstract enough without introducing a prototype.
Again, thanks for the code review. The playlist DB code needs a lot of refactoring, since right now there's too much repetition I've been too lazy to fix. If you want to talk some more, feel free to email me.
playlistCount :: PromiseDB Int
playlistCount = withConn $ \conn -> do
result <- query 'SELECT COUNT(id) AS count FROM Playlists;' conn
return (parseInt $ get 'count' result)
withConn $
query 'SELECT COUNT(id) AS count FROM Playlists;'
>=> return . parseInt . get 'count'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.
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.
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 calls look the same as local calls! But it wasn't awesome, it was horrible, because the details of the abstraction 'leaked' through and you got all kinds of problems from having delegated away what was actually one of the most critical, sensitive parts of your code to a layer you had no control over. 15 years later we're back to nearly everybody using REST because it turns out to be way better not to shove those abstractions on top of your most important code.
Now, I'm not saying that analogy is perfect here ... but it does remind me of it. Why should you care about the order of things? Just to suggest something, sometimes it's just useful to be able to reason about it. "We know the first operation definitely happened before the others, so an earlier one failing can't be a side effect of something a later one did ... oops, we don't know that any more. We actually have no idea what order they happened in."
In my experience, promises do fill this role if they're used in a suitable scenario.
There's nothing incongruous about that. It is the case that side effects should only happen on POST, PUT, and DELETE methods (and the like), but almost all webservers are written because of a need to use these.
If your webserver is all GETs and HEADs, then it is either trivial and you would have used someone else's instead of writing your own, or its sole purpose is to repackage and serve existing data from other sources - a rare use case among all webservers.
If you were to take an inventory of all the webservers out there, you would doubtless find that almost all of them exist in large part in order to create side effects.
A cache gets refreshed or added to. A user's viewcount is incremented. A new statistic is calculated and then stored. An item is marked as viewed. And these are all just on a GET.
On complex sites with a logged-in user, side effects are pretty much the norm.
Using a Promises, as opposed to reducing a list of computations async-style, also limits you to the Promise object's interface, so you lose (or at least add cruft to) the flexibility and composability of using native lists. By sequencing computations with lists, if I want some insight into what's happening, I just List.map(apply compose, logFunc). With promises, I have some work to do.
Promises have their uses, but it's definitely a tradeoff, and for most HTTP servers, I'd argue that their utility does seem a bit limited. I'd similarly say that making a point of using FRP to build a server would probably be a bit overkill for the task.
Because, in the end, what, semantically, is the difference between:
runqueue([func1,func2,func3,func4]); and func1().then(func2).then(func3).then(func4);
No significant difference at all, really. except the promises permit you much more flexibility and options.
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 different places (or at least 2 tests for failure).
Another answer would be a state machine which can be grouped and chained (pipe'd) with other similar state machines, to guarantee an order of operations when you need it. With this, you create a promise which is only resolved when both of the promises for the 2 ajax calls are complete, and that promise then pipes the results to the next promise in the chain which renders your view. For the Default view, if either of the ajax calls fail then the parent promise will fail, allowing you to handle the failure in one place.
Code example:
Deferred.when( ajax1(), ajax2() ).then( /* success */ mainView(), /* fail */ defaultView() );Anytime you need to perform more than one interaction with external services in parallel, it's a lot easier to wrap the results as futures and interact with the promise objects than to cope with callback spaghetti.
This is particularly critical anytime you're working in an SOA environment.
I could see why it's easy to believe that you don't need promises if you're averaging 1-2 database queries and 0 API calls per web page/API call reply, but once your scenario gets even slightly more complex - you're fucked.
Promises are one of the big reasons I like Clojure's concurrency better than Go's.
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]
Kay's interest in spreadsheets wasn't about functional programming, it was about interactive and dynamic computation. I have a pdf of the 1984 Scientific American article that Wikipedia is quoting from. It does include the phrase "value rule"—by which he simply meant what we would call a spreadsheet formula—but I'm pretty sure it makes no argument about functional programming (it's all images so I can't search to be sure). If you'd like a copy, email me. It's a pretty neat article, ahead of its time as one would expect from Alan Kay.
I guess we'll agree to disagree, I don't think someone needs to use the phrase "first-order functional programming" when they give the very definition of it, which is what Wikipedia does: summarize Kay's argument.
I do agree the article itself was quite interesting, and certainly ahead of its time.
I was making a textual point about the Wikipedia article. Its use of the phrase "first-order functional programming" is hyperlinked to http://journals.cambridge.org/action/displayAbstract?aid=727.... It's not citing Alan Kay.
I have no idea if Alan Kay ever used the latter phrase, but it was easier to use that phrase here on HN than Alan Kay's made up phrase, which would have be difficult to understand without the content of the article explaining it.
Totally agree. My startup is using hierarchical grids as our core datatypes for just that reason (we also support Function cells that are used as values).
"Naming" is one of the core problems in computer science, and grids/spreadsheets elegantly solve that problem for many ad hoc use cases, where functional programming (in all its forms) does not.
In that case any languages supporting function is "first-order functional programming." It's kind of meaningless when we are talking about real functional languages. PHP can define a function that takes a value and returns a value, and thus it can do "first-order functional programming." But no one claims PHP is a functional language. (Not to degrade PHP, it's a good language doing what it does best.)
All these twisting the definition of functional programming just produce more confusion.
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.
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.
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.
The most important aspect of being functional, high order function, is completely missing.
One FP attribute that spreadsheets do have is referential transparency: the same inputs given to the same formula will always produce the same result.
let x = 3, y = 5 in
x + y
You're right, of course. But it depends on how you draw the boundaries of the system. If you think of the numbers in your example as code, then the program is stateless, and each time you change a number you get a new program. But if you think of them as parameters that live outside the code, then the edit-recompute cycle is a state change. In a similar if trivial way, if you take (say) a Java program running over a database and decide that the data in the database is "code", that "program" (consisting of Java code plus database) is now "stateless" too, and anyone who updates a database record is changing the "program".
Given that "stateful" vs. "stateless" depends on how you draw the boundaries of the system, the question is how best to draw the boundaries of a spreadsheet. I'm not arguing there's a single correct way to do that, but in my view the user's mental model of a spreadsheet is closer to "a calculating machine with state that I can update" than it is to "a stateless calculating machine with a lot of hard-coded literals".
Psychologically, updating the numbers in a spreadsheet doesn't feel like editing the source code of a program and re-running it. It feels stateful, like mutating something that triggers a cascade of side effects (recalculation). For this reason I think that spreadsheets are closer to the Smalltalk vision of a world of objects that respond to user interaction (as well as to each other) than they are to the functional programming vision of pure code. Put differently, the spreadsheet's I/O, its grid UI, is part of its essence. You can't abstract away from that without losing the heart of the thing. So the analogy with functional programming, though tempting, leads in the wrong direction. Every individual formula that lives in a cell is certainly a functional program when taken in isolation—but the memory model by which the cells reference one another and get updated is stateful.
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. :)
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?
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.
A mathematical (ie pure) function is declarative in nature as it defines a relation between sets. However, in practice you often use it imperatively, ie as a means to get an output from some input.
An object is imperative in nature as it encapsulates mutable state. However, the set of messages defines an abstract interface which is arguably declarative.
In principle, a purely functional language cannot be object-oriented, and a purely object-oriented language cannot be functional. In practice, this doesn't matter as pure languages are rare.
Second, OO is an orthogonal attribute to functional.
Third, your argument commits a formal fallacy of this form:
All cats have whiskers
Cats can have stripes
Tony has stripes
therefore tony is a cat.
---The possibility of an attribute in X, and Y containing that attribute does not imply that Y is an X.
the point is that whether something is declarative has no bearing on whether it is functional or not. It's an irrelevant point to bring up. Whether something is OO is equally irrelevant. That is what "orthogonal" means. I would go on to define for you "functional" "declarative", "formal fallacy" "logic", but this seems like a bottomless rabbit hole. I can only hope you'll try and find out what these words actually mean yourself.
However, my original point was addressing the claim in the blog that functional and declarative are equivalent in that functional has aspect of declarative. And since Excel is declarative, it's functional. I was basically saying that's not the case.
While declarative and functional can be orthogonal, and can both live in a language is an interesting but separate topic that is not really related to the original comment.
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.
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 (this is the first time I've specifically encountered them) Promises are a powerful tool for accomplishing.
In contrast, threading explicit callbacks/continuations through a program, which is explicitly managing the order of execution, is relatively more imperative, which I think is the point of the article -- you don't need the wider control-flow flexibility of explicitly and manually threading callbacks to do the type of computations that most async web stuff does. You can abstract the common callback pattern out into something like Promises, and make all your shit more consistent and concise.
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.
If you insist on setting up semantic games: if Oleg hacking Haskell isn't functional programming then nothing meaningfully is.
----
> Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary.
What does `foldr (+)` return? What about `const 1`?
Semantic games are meaningful or this blog post wouldn't be on HN. The title of the post makes it clear that we're playing a semantic game.
Kiselyov is deconstructing the constructs. That's fine. He's playing the semantic game of showing how different concepts share ontology. This doesn't make the concepts identical; it makes their deconstructions identical. These paradigms are not physical things they are conceptual abstractions. Anyway I'm obviously not getting through to you.
const is not a promise, it's a constant. Different concepts, similar ontology.
A "promise" is a delayed computation. It's a stand-in for a value, and the computation referencing it will suspend its execution until a value is available for it to consume. Similarly with Iteratees. They encapsulate specific patterns for building computations out of other computations.
What makes the "promise" pattern relatively less imperative than threading callbacks is that it abstracts out a specific pattern for ordering a computation, so that it doesn't need to be restated every time.
What makes the "promise" pattern relatively less declarative than "purely declarative" is that the control of the computation can be specified in the language itself. It's just abstracted out to the pattern in common. Similarly to re-writing certain stateful `for` loops with `map`.
Promises are a pattern in the functional programming paradigm. The "functional programming community" is where the construct comes from, and using them lets you write code that is closer to the declarative ideals of functional programming than the article's specified alternative, threading callbacks, which has relatively more in common with the explicit control of the order of computation that is implied by imperative programming.
I don't see anything in the article that remotely justifies "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.". In fact, I don't see anything wrong with it at all, or anything that substantially disagrees with what I've said or what I've seen any of the type of (yet-unspecified) authorities of certified expertise that you've appealed to have said. Yes, Promises are relatively more declarative, but they're also relatively more functional, relatively less imperative, and I don't see any basis for calling somebody an idiot for not using those terms with total mutual exclusion.
So please, raise, any specific objections you have which I have not addressed, or else have the honesty to retract the undeserved insults you've thrown at the author of this article.
You define promise:
>A "promise" is a delayed computation. It's a stand-in for a value, and the computation referencing it will suspend its execution until a value is available for it to consume.
I define promise:
>A "promise" is a declaration or assurance that one will do a particular thing or that guarantees that a particular thing will happen.
My definition of promise is conceptually and formally more accurate than yours, because your definition raises issues like "what is a computation" and "what is a value" and "what is a stand-in" and "what is execution" and "what does consume mean"
As programmers, we understand what these words mean concretely in terms of lower-level abstractions or in some cases actual hardware operation.
My point is that the declarative ideal that you reference is not defined in terms of lower level programmer abstractions, but rather in terms of natural conceptual metaphors.
Since functional programming is generally seen as a subset of declarative programming, it's natural that functional programmers use declarative concepts and it's even understandable that they call those concepts functional. But they're mixing metaphors and creating conceptual confusion. They're losing track of the original metaphors that draw hair-splitting analytic distinctions between concepts in order to create clarity. It's semantics.
Like I already said, I'm not criticizing his design sense and I'm not criticizing yours. I'm criticizing his and your use of language and I'm asserting that your language is degraded and impure.
To me, aside from the design advice he gives, his blog post is about drawing semantic distinctions. I just find the way he does this to be horribly flawed in a way is "so close to being right that it's the worst kind of wrong."
Similarly, I would describe your definition of promise in this way. So close to being right that it's the worst kind of wrong. Your definition of promise is not a definition; it's a deconstruction. It's actually an imperative deconstruction--you're describing the promise using imperative language--concepts like execution and computation.
HN is full of very "practical" people who have a view that goes something like, "I'm correct enough for this to WORK, I'm correct enough to get the correct answer, therefore I'm correct." It's a reductionist view of truth; that which I can deconstruct, I understand. I don't share this view.
I would say, you ARE correct, but you're not as correct as you could be. Likewise with the author.
When I want to learn about the distinction between declarative paradigms and functional paradigms I talk to people who specialize in drawing that distinction. Since the blog post is prima facie drawing a distinction between functional and imperative, the value I'm looking for is an analytically rigorous distinction between abstract concepts.
That's not what I found, so I'm critical. Sorry. This just isn't the author's area of expertise and it shows. Perhaps most of his readers don't care. More power to them. But if you want to engage in intellectual life you can't throw down the gauntlet every time someone criticizes you.
Who specializes in making that distinction? Point me in the right direction. I am absolutely throwing down the gauntlet, I don't believe for a second you know what you're talking about, and I suspect that your understanding of functional programming does not include the possibility of functions returning functions, and the term "thunk" would be lost on you. If you're going to put so much weight on expertise, please point me in the direction of the researcher who you suspect would take the author of this article to task for his terminology. Or make a positive argument yourself.
"Promise" here refers to a specific computation strategy, it has a well-documented intellectual heritage and has been defined as a lambda calculus. It has its basis in the structuring of computations. With how you've constructed this ontology, I don't see any room for "functional programming" to mean anything at all.
I suppose that does leave a lot of room for calling the OP "the village loudmouth" for having any actual content behind his words.
I'm just inline with my own discipline where promise has a different meaning, a super ordinate meaning that includes your meaning. As a consequence, anyone from your discipline just thinks I'm clueless. I'm definitely not going to convince you that the typical definition of promise, the one you're used to, is actually just an operational definition--an instrumental label assigned to a particular instance of a promise-like thing.
I'd cite the tiny field of cranks who think like me, but that would just bring shame on them by association. I'm not doing research in functional programming. I'm working on hair-splitting tyrannical distinctions-without-a-difference. According to your paradigm, I'm an outright fraud spouting bullshit. So enjoy your victory I guess.
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 user libraries.
Yes, there is: https://github.com/promises-aplus/promises-spec
Promises don't somehow magically make asynchronous code easy to write while leaving callbacks out in the cold. They have very similar strengths and weaknesses and I didn't find any of the OP's arguments compelling.
In fact, if I had to choose, I would take the opposite view and say callbacks are neater, cleaner and more consistent than promises.
I actually didn't know about futures until I learned about scala and finagle. I watched a talk on twitter's service stack given by marius eriksen and was blown away. My coworkers heard me rambling on about futures for weeks afterwards, and I found that it was difficult to explain what was so great about them. So I'm not surprised at the negative reactions in the comments here (although jcoglan did a much better job of exlaining them than I ever did).
// list :: [Promise a] -> Promise [a]
var list = function(promises) {
var listPromise = new Promise();
for (var k in listPromise) promises[k] = listPromise[k];
for (var k in promises) listPromise[k] = promises[k];Promise libraries, like RSVP.js [1] he referred to, typically implement a way to construct a promise with a depends-on-many relationship, as a function possibly called `all([p1, p2, ...])` (with the same type signature as for `list`), `and(p1, p2, ...)` or something similar.
IMO, defining the `list` function that way would've been clearer to the reader and more FP'ish, treating the `promises` argument in as a value and not a mutable object.
[1]: https://github.com/tildeio/rsvp.js/blob/master/lib/rsvp/all....
var listPromise = new Promise();
for (var k in listPromise) promises[k] = listPromise[k];
Coming from a Python background, I think I would have found this more obvious if the variable "k" were instead called "method" or "attr". If it was `for (var method in listPromise)` it'd be much clearer what's going on, whereas single-letter variables like i, j, and k are, to me, stand-ins for integers.
It was also confusing, as you said, that the function uses destructive update rather than treating the input as a value. James did mention this ("augmenting the list with promise methods"), but it's still unexpected, especially when the function is preceded by a Haskell type signature.
The reason I only say I'm closer to understanding, and not quite there yet, is I'm not sure what it means to do `new Promise()` or what is being copied over in the above for-loop. I tried James's code with a Promises/A+ implementation, rsvp.js (https://github.com/tildeio/rsvp.js), but it won't let me do `new Promise()` because it works differently:
> var promise = new RSVP.Promise();
TypeError: You must pass a resolver function as the sole argument to the promise constructor
var promise = new RSVP.Promise(function(resolve, reject){
// set up a callback that calls either resolve(...)
// or reject(...)
});
I still think this is a great article, but that code snippet has proven to be quite a puzzle.
This is especially noticeable when you have branching behavior / want to resolve a promise early[1]:
Branching with promises:
function doTask(task, callback) {
return Q.ncall(task.step1, task)
.then(function(result1) {
if (result1) {
return result1;
} else {
return continueTasks(task);
}
})
.nodeify(callback)
}
function continueTasks(task) {
return Q.ncall(task.step2, task);
.then(function(result2) {
return Q.ncall(task.step3, task);
})
}
function doTask(task, callback) {
$$([
$$.stepCall(task.step1),
function($, result1) {
if (result1) return $.end(null, result1)
},
$$.stepCall(task.step2),
$$.stepCall(task.step3)
], callback)
}
[1] http://stackoverflow.com/questions/11302271/how-to-properly-...
[2] https://github.com/Schoonology/stepdown (docs need updating, view tests for documentation)
SomeClass.prototype.someActionPromise = function(){
var deferred = makeADeferred();
SomeClass.prototype.someAction.call(this, function(err){
err ? deferred.reject() : deferred.resolve();
});
return deferred.promise();
};
I'm interested in your opinion RE: his argument for why callback APIs are imperative - because I think he has a very good point and has supported it with a solid argument and you haven't offered any rebuttal.
After reading it, I think I have to agree that I had never thought about it that way. It makes a lot more sense that a promise is just a declaration of some unit of work, and when you can use a promise like any other data, you aren't just giving imperative commands, but rather describing work to be done and using that as a fundamental part of your code, which is why it drastically simplifies async programming (the relation of promises to monads is quite nice, too). Definitely a good article, thanks for kicking me :).
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.
The XHR object is effectively a request and a response bundled up into one object that has promise-like traits. You attach event handlers to it to handle various state changes and scenarios, and then once you issue the request, the event handlers get invoked 0-N times. If it really was JavaScript callback-style, XHR would look like this:
window.xmlHttpRequest("GET", url, function (result, error) { ... } );
Honestly, the only way to classify node's callback-heavy design as a 'no-brainer' is if you excuse the design by saying no thought was put into it beyond simply doing what a bunch of other people were doing. If you put enough thought into how large applications will be built, and how difficult it is to build scalable, maintainable libraries, callback-passing style easily loses compared to promises.
Here's a discussion about removing promises from node.js in 2010:
https://groups.google.com/d/msg/nodejs/RvNoQtoWyZA/ar_lYLhK8...
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.
See the second paragraph of the article for the authors take on this. Specifically, the concept of values is very important.
It's one of the reasons why i started learning haskell.
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
}
});
});
var result = [];
var hasFailed = false;
paths.forEach(function (i, file){
fs.stat(file, function (err, data){
// if previous callback failed, give up.
// unless this is the first item, which we still need
if(hasFailed && i !== 0) return;
if(err) {
hasFailed = true;
// do something with the error
if (i === 0) // do something special for error on first item.
return;
}
result.push(data);
if (i === 0) {
// Use stat size
// remember we might have already failed, in which case don't add the first item to the general result
if(hasFailed) return;
}
if (result.length === paths.length) {
// Use the stats
}
});
});
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);
var failed = results.every(Buffer.isBuffer);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)
And in such case you would only do this once outside the listeners of http/or-whatever connections so it would be done just once regardless of the number of concurrent activity.
fs.statMany(filenames, function (stats) { ... });
var statsPromise = fs.statMany(filenames);
Hell, with ES6 generator-y expressions you could make it even more succinct, something like:
var result;
fs.statMany(filenames, function (stats) { result = [... for x in stats]; });
Why don't we all just go back to manually pushing/popping arguments on the stack like in assembly language while we're at it?
Deleted comment