21–30 of 170 posts
Earlier quoted context omitted.
Could you elaborate? Coming from Lua I always found the nesting of anonymous functions messy and wondered why they weren't done as in the article.
Promises and async/await. This page is so outdated it shouldn't exist.
As a curious and perhaps naive aside, I've been wondering why the programmer should need to care about asynchronous execution of code at all. Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? The advent of promises, async.js, and other paradigms tell me that people still kind of want to write code that does one thing after another, then another, then another.
Last updated in 2012. A lot has changed since.
This is mentioned in the last section of the article: "What about promises/generators/ES6 etc?"
A website? Really? Why not just write an article on medium?
Earlier quoted context omitted.
Could you elaborate? Coming from Lua I always found the nesting of anonymous functions messy and wondered why they weren't done as in the article.
You can now use async/await directly in node (no transpiler necessary), and both Babel and TypeScript can compile them for browser use. Also there are now many more libraries that use native ES6 promises. Before: function getPhoto(callback) { someCustomHttpGet("/favorite_photo_id", function(err, data) { if (err) { return callback(err) } try { var dataJson = JSON.parse(data) someCustomHttpGet(dataJson.url, function(er…
relevant:
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Earlier quoted context omitted.
You can now use async/await directly in node (no transpiler necessary), and both Babel and TypeScript can compile them for browser use. Also there are now many more libraries that use native ES6 promises. Before: function getPhoto(callback) { someCustomHttpGet("/favorite_photo_id", function(err, data) { if (err) { return callback(err) } try { var dataJson = JSON.parse(data) someCustomHttpGet(dataJson.url, function(er…
Your try catch is useless here, AFAIK JSON.stringify doesn't throw. and you can't catch someCustomHttpGet() "exceptions" if the latter is supposed to be asynchronous. relevant: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Also regarding that article: you can call async functions from non-async functions - you will simply get the Promise object instead of the data.
If you're using TypeScript, your editor will immediately highlight the error if you try to use that Promise object as though it were the data, so zero chance of getting it wrong. Try it yourself - https://goo.gl/vDk3Gz - hover over the `n` inside the `formatName` call.
Not sure this problem goes away by giving names to anonymous functions, which seems to be his suggestion
Nop, but it can be a bit better by using predefined functions rather than inline ones.
I think programming where we have state and things can happen at any time, where programs wait for events or something similar has proven to be difficult to write/understand/maintain. The 30+ years it has taken to write the (unfinished) Herd micro-kernel is a good example.
Seriously, the worst feeling ever is tracing through a huge function tree, only to run into function pointer dereference. Then you have to go on a wild goose chase to find out when, where and what it will be assigned to.
STATIC TYPES PEOPLE.
A website? Really? Why not just write an article on medium?