Комментарии 20
Стоит отметить подход к обработке ошибок. Часто акторы не гарантируют доставку сообщений (аналогия с почной работает :-)), и при ошибках принято прото завершать актор.
Акторы в чем-то напоминают процессы ОС со своей виртуальной памятью. Процесс так же может завершиться при ошибке потеряв свое (возможно некорректное) состояние. Это сильно упрощает отладку — каждый актор можно тестировать независимо от остальной системы.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Кстати, забавно, что хотя акторы не подходят под идеи создателя Пролога, первые реализации Erlang написаны именно на Прологе :-). В общем то на Прологе акторы сравнительно легко реализуются — похожая техника применяется например в Mozart/Oz.
Акторы в чем-то напоминают процессы ОС со своей виртуальной памятью. Процесс так же может завершиться при ошибке потеряв свое (возможно некорректное) состояние. Это сильно упрощает отладку — каждый актор можно тестировать независимо от остальной системы.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Кстати, забавно, что хотя акторы не подходят под идеи создателя Пролога, первые реализации Erlang написаны именно на Прологе :-). В общем то на Прологе акторы сравнительно легко реализуются — похожая техника применяется например в Mozart/Oz.
+3
Стоит отметить подход к обработке ошибок. Часто акторы не гарантируют доставку сообщений (аналогия с почной работает :-)), и при ошибках принято прото завершать актор.
Согласен, что это проверенный и работающий подход к обработке ошибок. Про него я узнал из Erlanga, но не знаю, был он там применен впервые или заимствован из другого языка. В этом плане первоисточник был бы интересен — может быть есть еще какие-нибудь хорошие идеи. Если кто может подсказать, пожалуйста, напишите.
При этом модель авторов не налагает никаких ограничений на обработку ошибок, Существуют другие приемы, которые показали себя на практике. О некоторых из них, я и хотел рассказать в следующих статьях.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Согласен, что ФП имеют много разных преимуществ. Только не пойму, как в императивных языках встроить тайминги, чтобы не потерять тот же эффект? Первое, что приходит в голову, это встроить тайминг, например, в конце тела каждого составного оператора. Но как это скажется на производительности? Может быть есть такие реализации или исследования на эту тему?
0
Ходил как то на митап по языку Go, там говорили, что есть 2 вещи, куда имеет смысл воткнуть проверку для прерывания выполнения процесса: в вызовы функций (это они реализовали в версии 1.2) и в каждую итерацию for / while цикла (ещё не реализовали).
В Erlang оба этих случая сводятся к одному, т.к. реализовать цикл без вызова функции невозможно в принципе (только рекурсия).
В Erlang оба этих случая сводятся к одному, т.к. реализовать цикл без вызова функции невозможно в принципе (только рекурсия).
0
Спасибо за статью! Конечно пишите, тема очень интересная.
Вы случайно не сталкивались с акторными моделями применительно к Smalltalk? Как мне кажется, его модель сообщений очень аккуратно ложится в концепцию акторов. По моему, я даже где-то подобное видел, вроде диалекта Smalltalk с поддержкой акторов.
Вы случайно не сталкивались с акторными моделями применительно к Smalltalk? Как мне кажется, его модель сообщений очень аккуратно ложится в концепцию акторов. По моему, я даже где-то подобное видел, вроде диалекта Smalltalk с поддержкой акторов.
+2
Нет, сам я не работал со Smalltalk. У Carl Hewitt есть статья, датированная 2012 годом, Actor Model of Computation: Scalable Robust Information Systems — это обзор сделанной работы и достижений. Так вот, буквально в первом абзаце он пишет: «Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching.» Так что, судя по всему ранние версии Smalltalk выступили источником идей. Как я понимаю, был заимствован сам принцип обмена сообщениями.
+2
Как ни странно, но в Википедии эти моменты отражены достаточно подробно: en.wikipedia.org/wiki/History_of_the_Actor_model#Smalltalk
Ссылок много (даже такие), но тот факт, что Кэй для считает первичной особенностью Smalltalk именно концепцию отправки сообщений, достаточно последовательно им же и озвучивается.
По поводу имплементации в Smalltalk -80 можно действительно найти много ссылок на работу Jean-Pierre Brio, и, как пример, реализация поместилась в нескольких слайдах тут
Ссылок много (даже такие), но тот факт, что Кэй для считает первичной особенностью Smalltalk именно концепцию отправки сообщений, достаточно последовательно им же и озвучивается.
По поводу имплементации в Smalltalk -80 можно действительно найти много ссылок на работу Jean-Pierre Brio, и, как пример, реализация поместилась в нескольких слайдах тут
+1
Извините за оффтопик, но почему Actors переводят на русский как «акторы», а не «актёры»?
+1
Скорее всего, Вот поэтому
0
+1
Мне кажется это способ ограничения круга возможных сущностей под именем Актер до единственной — связанной с конкретной областью и контекстом — Актор. Легче узнается и воспринимается на слух.
0
в мире императивного программирования практически ничего неизвестно о функциональном – его как бы нет, по крайней мере, это было до недавнего времени, а в мире функционального программирования императивное подвергается критике. Может есть у кого мысли, почему так произошло?
Я вам не скажу за всю Одессу… Но у меня лично просто по-другому мозг устроен. Мне проще мыслить в категории «разделяй и влавствуй». «Сделал что-то с состоянием, получил новое состояние, сделал то же самое с новым состоянием… О, а вот же и терминальное условие = решение»
Тема на самом деле интересная. Если будете организовывать какие-либо конференции — пишите, приглашайте! Особенно интересует матчасть.
Стиль изложения у вас тоже неплохой. Можно чуть больше визуализации — схем\графиков(вместо списков). Аналогии в тексте проводите весьма ясно и понятно. Для графиков можете использовать yEd
+2
Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
+2
Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
Отладчик в Erlang есть. В этом месте говорится немного о другом: в общем случае, в акторных системах может отсутствовать причинно-следственная связь между текущим состоянием и предыдущим. Об этом же я написал в статье в абзаце под заголовком Ложка дегдя… А при отладке мы как раз пытаемся установить причину некоторого некорректного состояния. Это не значит, что отладка невозможна вообще, но, по крайней мере, она значительно затруднена.
Проблема с таймаутами, которые Вы описываете, существует и при отладке обычных многопоточных приложений.
И, конечно, такой метод не годится для отладки продакшн системы на лету.
Согласен, отладка не для продакшена.
Что касается отладки во время разработки, то, во-первых, таймауты можно сделать конфигурируемыми. Это позволит успеть выполнить все проверки прежде, чем хотя бы один из истечет. Во-вторых, можно писать юнит-тесты с использованием Mock-объектов и заглушек. Когда мы начинали осваивать акторы, первое впечатление которое у нас возникло — хрустальная система. Идея — все отлично, по отдельности каждый маленький компонент — все здорово, но как только начинаешь собирать что-то более-менее крупное — все сыпется, а причину найти, порой сложновато. Вообщем, считаю, что в нашем случае, тесты очень сильно помогли. Есть еще ряд идей, чем можно компенсировать сложности отладки — об этом я собираюсь написать в одной из следующих статей.
0
На мой взгляд, подсчет тайминга нужно реализовывать на уровне исполнения команд переходов ядром процессора. Команда перехода — очень хороший момент для проверки возможности переключения на другой поток.И, интересно, компилятор насколько точно может оценивать относительную продолжительность выполнения того или другого фрагмента кода? Можно принудительно вставлять команды передачи управления в каждой некритической секции, а в критических, исполнение которой по оценке превышает некоторый предел — выдавать предупреждение, но не только разработчику, но так же и оставлять некий вызов системы при запуске приложения, о том, что приложение содержит длительно выполняющиеся критические секции, чтобы пользователь знал, что это приложение может подмораживать переключение процессов и мог принять решение — использовать это приложение или нет.
0
НЛО прилетело и опубликовало эту надпись здесь
Здравствуйте, merhalak. Так получилось, что только сейчас увидел Ваш комментарий. Спасибо за замечание. Исправление внесено вот в таком виде (все что ниже — это правка)
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модели акторов 40 лет