Презентация не новая, но попалась мне на глаза только сегодня. Любопытно.
Вообще, смотреть такие презентации без изрядной доли иронии и сарказма я лично не могу. Далеко не новые идеи преподносятся как что-то из области cutting edge :) И это даже если не брать в расчет Erlang, где почти все показанное в презентации эксплуатирует с конца 80-х (правда, широко известен он стал намного позже). Мы в КБСП подобный подход переоткрыли и начали применять в середине 90-х. Что воплотилось затем уже в Интервэйле в наш внутренний инструмент SObjectizer-4, который не много, ни мало, а уже девять лет используется нами для разработки С++ных приложений.
Тем не менее, жизнь забавная штука. Я, например, постоянно забываю, что уже выросло огромное количество разработчиков, которые приобщились к программированию уже после 2000-го и которые начинали с Java, а то и с C#. И, если начало было в обнимку с Java, то наверняка вобрали в себя такую дурную привычку Java-сообщества, как игнорирование полезных вещей до тех пор, пока не появится какой-то раскрученный фреймворк, который протолкнет эти вещи в мейнстрим (да, я большой любитель кидаться камнями в Java-огород). Посему такие презентации очень полезная штука.
По поводу показанных в презентации примеров есть у меня несколько сомнений в правильности выбранных авторами Akka подходов.
Во-первых, для сложных актеров метод onReceive с последующим ручным определением типа сообщения посредством множества обращений к instanceof, на мой взгляд, не есть хорошо. Это черевато некрасивым кодом, провоцирующим ошибки и сложным в сопровождении. Имхо, задача фреймворка определить тип сообщения и вызвать подходящий для сообщения метод. Это как раз то, за счет чего фреймворки вроде MFC упростили программирование под Windows, когда большая WndProc с одним switch-ем внутри была разбита на простые методы, каждый из которых обрабатывает всего одно Windows-сообщение.
Во-вторых, как-то я не очень понял на счет распределенных актеров. Мне показалось, что при работе с такими актерами в коде явно придется проводить грань – вот этот актер локальный, а этот удаленный и к нему нужно подключаться. Если это так, то я бы предпочел иную схему, когда расположение актера не нужно руками в коде. Это должно делаться автоматически на уровне фреймворка и конфигурации приложения.
В-третьих, я не понял, зачем в агентный фреймворк засовывать еще и STM. Шоб было усё и зразу? ;)
Еще одна мысль после просмотра презентации – очень похоже, что агентные фреймворки для нативных и управляемых языков должны развиваться в несколько разных направлениях.
Комментариев нет:
Отправить комментарий