Как стать автором
Обновить

Комментарии 15

Хм, вроде только была на главной, а теперь нету. Видимо не всем интересно :)
Вообще очень неплохо, но особенно конечно доставляет удовлетворение своей очевидностью способ F#. Кстати сейчас готовлю один перевод про F#, там это упоминается как одно из достоинств. И, в принципе, резонно.
Пока еще на главной.
Повторюсь: Я, конечно, зануда но…
1. Нет такого понятия как анонимные делегаты, есть анонимные методы.
2. Для асинхронной работы помимо библиотеки Рихтера есть еще и TPL, точнее будет в .Net 4. (С Рихтером, кстати, забавно на эту тему весной пообщались)
3. Вообще же такие вещи, там где это поддерживается, делаются посредством continuation passing style (http://en.wikipedia.org/wiki/Continuation-passing_style)
И небезизвестный Эрик Мейер сейчас пишет довольно забавный фреймворк на шарпе для работы в таком стиле через LINQ — вот это действительно круто :)
Посмотреть об этом можно, например, здесь: channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Brian-Beckman-and-Erik-Meijer-Inside-the-NET-Reactive-Framework-Rx/
Не пишите комментарии на зеркала блогов – никто не ответит :)

1. Семантика. Можно погуглить ‘anonymous delegate’ и найти достаточно упоминаний.
2. Никто не спорит что в task-level parallelizm в дотнете все в порядке. Но вот всякие Parallel.For оттуда же – не круто.
3. Continuation passing style работает в простых ситуациях, когда задачу можно разбить на несколько Func<U,V,...>. AsyncEnumerator и F# позволяют формировать цепочки так же, как если бы вы писали синхронный код. То есть там например могут переплетаться изменения состояний, scope’ы, и так далее.
Про Reactive Framework – тут уже на хабре было, в принципе bindable linq неплохо работает :)
Тогда закройте комментарии в зеркале.

1. Например, погуглив по словам «папа римский педофил», тоже много чего найти можно, но это не значит, что так и есть на самом деле, иными словами это лишь доказывает, что ошиблись вы не один… Формально есть термин «анонимный метод», а термина «анонимный делегат» — нет. Хотя для блога простительно, как выразился один мой знакомый — это концерт в халате на лестничной клетке… )
2. Parallel.For — как раз очень круто. Но речь не о нем, а о том, что там тоже есть поддержка континуейшенов в достаточно приемлемом виде.
3. Continuation, как раз и были придуманы для того, чтобы писать асинхронный код, как синхронный, а AsyncEnumerator-ы уже попытка эмулировать это дело, но Reactive кажется удачнее.
Вообще CPS был придуман функциональщиками, где каждая функция независима и общего состояния нет (что здорово) и ими же показана успешность применения такого подхода, отсюда утверждение, что могут переплетаться изменение состояний, и т. д. — звучит как антиреклама… ))
И в принципе, я бы хотел посмотреть на задачу, которую невозможно разбить на несколько независимых функций с явной передачей состояния так, чтобы она не стала от этого понятнее и читаемее… :)
Спасибо. Узнал, что в дотнете живётся не так плохо как я думал )
У нас в дотнете все ажурно. Точнее Azure’но. :)
Интересно но не привычно (после С и ему подобных языков). Еще подробно расписано про данную возможность здесь:
msdn.microsoft.com/ru-ru/magazine/cc967279.aspx
Попробовал прочитать, но, увы… на русском языке читать нереально. English version
НЛО прилетело и опубликовало эту надпись здесь
Я об этом хотел через пост написать. В следующем про обычный граф, в потом — про conditional graph, что у нас и имеется.

Задачка прикольная. И соглашусь — с такими вещами «голый» шарп справляется достаточно плохо.
На Java, например, каждая часть задачи заводилась бы в собственный java.lang.Thread (обеспечение инкапсуляции данных и кода), а те, в свою очередь, «цеплялись» друг к другу через вызов join() и, таким образом, обеспечивали последовательное взаимоувязанное выполнение этапов задачи.
Из нитей, увязанных в граф зависимостей через join(), можно получать весьма нетривиальную функциональность, не теряя управляемости кодом.
А топологическая сортировка зависимостей сама собой произойдет?
В данном случае, что я привёл, топологическая сортировка зависимостей в самом графе — join() ждёт смерти объекта-нити, окончания которой ожидается в текущей нити, прежде чем запустить текущую нить.
Ничего против Вас не имею, но не слишком ли много var?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации