Асинхронность: почему это никак не сделают правильно?

поменяйте async на non-blocking, пожалуйста.
асинхронность это возможность исполнять несколько действий одновременно, что в рамках однопоточного скрипта невозможно, за исключением воркеров, каждый из которых тоже однопоточный.

Хорошая статья, давно пора на Хабре больше умного писать и меньше перепечатки новостей :)

Я только не понял идею Do. Что мешает вместо continuableFunc(args)(doSomething, errorHandler) писать continuableFunc(args, doSomething, errorHandler);без всяких умных слов и чуть короче? :)

Где-то в примерах была уже реализация асинхронности через yield, подобная ADISP.

Не можете подсказать линк?

Насчёт python и неблокирующего нетворкинга смотрим на gevent.org — почти идеальное решение ;-).

Майкры работают над Async Workflows, вот так это выглядит:

let file = File.OpenRead(«Program.fs»)
let! stuff = file.AsyncRead(250) // Тут считывается файл, неблокируя и асинхронно

printfn "%A" (Encoding.Default.GetString(stuff)) // А тут синхронно печатается в консольку

let req = WebRequest.Create(«www.google.com/search?q=node.js»)
let! resp = req.AsyncGetResponse() // Тут скачивается НТМЛ, тож неблокируя и асинхронно
printfn "%i headers recieved." resp.Headers.Count // Опять синхронно печатается в консольку

Это F#. Все асинхронно, и все неблочаще. Доступно уже года два или больше.

Я у себя в блоге (http://chaliy.name/blog/2010/7/node_dot_net) всегото пару дней тому назад возмущался, что node.js аж нисколечки нечетабельный.

В руби 1.9 можно писать синхронный код используя non-blocking вызововы, достигается это благодаря связке EventMachine + Fibers. Подробней об этой технике можно почитать тут. Есть даже рельсы, которые используют non-blocking io — github.com/igrigorik/async-rails

Вспомнилась жуткая JS-библиотечка Concurrent.Thread
jsthread.sourceforge.net/
Статья авторов на английском в pdf тут.
Треды там условные, но она как раз позволяет писать асинхронный (неблокирующий) код в синхронном стиле. Как это работает? Ваши функции вычитываются в строку через Function.prototype.toString, перепарсиваются, циклы разматываются в goto-style, и в некоторых местах вставляется вызов, передающий управление таск-свитчеру. Затем это снова превращается в функции (то ли через new Function, то ли через eval). В статье есть пример с Ajax-запросом. Страшные тормоза, но красивый код =) Если узкое место — это связь с сервером по Ajax, то эту радость теоретически даже можно использовать. Я сам не пробовал :-)

На мой взгляд, система колбэков — не самая большая проблема неблокирующих вызовов.
Главная проблема — работа с состоянием программы (переменные). Если представить себе программу в виде графа с вершинами-состояниями (она им и является), то обычная синхронная программа описывается более или менее читаемо. На вершинах обычно пишут изменения вектора состояния, предполагая остальные переменные — инвариантами относительно соседних состояний.

А вот когда мы связываемся с неблокирующими вызовами колбэков, это, фактически, может означать что ЛЮБОЙ обработчик может быть вызыван при ЛЮБОМ векторе состояний. Мы, фактически, теряем вообще все инварианты в программе!

Задумайтесь!

Раньше в обработчике вы делали проверку нескольких условий, предполагая, что все остальные вещи будут именно в том виде, как следует (ведь мы гарантируем это в предыдущем коде).
В неблокирующих вызовах инвариантов нет.
Обработчик должен проверять туеву хучу состояний, чтобы удостовериться: да, мыжно выполнить обработку в том или ином виде.

Хотите наглядный пример?
В яваскрипте загружаю набор данных со стороннего сервера. JQuery::json. И всё бы хорошо, но выборку данных формирует пользователь через интерфейс. К тому времени, когда данные придут, пользователь может нащёлкать интерфейс, много чего поменяв в выборке. В обработчике приходится полностью проверять состояние интерфейса и срочно придумывать что из полученной выборки пригодится, если требования пользователя изменились.

И хорошо если интерфейс описывается 2-3 переменными. Когда настроек много, то есть длинный вектор состояний запросов, проверка всего длинного вектора и принятие решение о дополнительной обработке выборки — много дополнительного анализа и работы по его реализации.

Я каждый раз когда смотрю на node.js вижу одну большую монаду на ручной тяге :-)

а зачем вы нарочно нечестно устрашили первый пример? ведь в синхронном вызове ничего не говорилось об обработке ошибок. некрасивый психологический трюк.
я лично со временем так привык к асинхронности, что практически её не замечаю, сидит в мозгу, как родная

var f = syncOpen(args);
checkConditions(f);
var result = syncReadAll(f);
checkResult(result);

asyncOpen(args, function(f){
  checkConditions(f);
  asyncReadAll(f, function(result){
    checkResult(result);
  });
});

Кстати, по-моему у Ruby и Coffeescript самая красивая и короткая лямбда, что важно при асинхронном коде.
Ruby:

asyncOpen('file') { |file|
  file.read { |content|
    checkResult(content)
  }
}

Coffeescript:

asyncOpen ''file', (file) =>
  file.read (content) =>
    checkResult(content)

В Actionscript3 практически всё основано на асинхронных событиях — ничего с читабельностью не случается — код понятен и читаем. А вот анонимные коллбэки — зло.
И не надо говорить что AS3- однопоточен — это не имеет значения.
В C# тоже очень удобно сделаны события (сигнал-слот)
Асинхронность помогает читабельности. А вот анонимные функции в javascript надо вообще отменить отдельным указом — с расстрелом за невыполнение.
Была же классная спека ES4 — почему остались на убогом ES3.5?

Кажется вам нехватает знания понятий со-процедуры (co-procedures) и продолжения (continuations), через которые они реализуются.

Основная засада — синхронный код, приведенный выше, замечательно читается.

Заранее извиняюсь за своё не слишком профессиональное в этих вопросах мнение, но по-моему это говорит о том, что нужен новый язык, в котором всё было бы асинхронно само по себе и всем этим расписыванием занимался бы компилятор/интерпретатор.

> фактически прервет исполнение в точке вызова и когда-нибудь начнет его снова из этой же точки, используя сохраненный контекст

Я может чего-то не понимаю, но это просто описание синхронного программирования фактически :))
Поскольку продолжать исполнение будет ровно тот, кого мы запустили асинхронно и никто другой (нам нужны именно те данные результата, которые только он возвращает.

Другими словами нужно просто весь этот синхронный кусок из 4х синхронных вызовов выделить в отдельный асинхронный поток средствами языка или библиотек. Разве нет?

Или вы предполагаете что этот сохраненный контекст кто-то другой сможет использовать в другом месте? Пока представляется только режим отладчика, который может возобновлять выполнение в разрез с задуманной заранее последовательностью действий.