LINUX.ORG.RU

Акторы и императивное программирование.

 , ,


0

1

Выдержка из бумаги [A Universal Modular ACTOR Formalism for Artificial Intelligence] от создателя модели акторов Карла Хьюита [соавторы: Peter Bishop, Richard Steiger]:

Наша цель - создавать прочный фундамент для решения проблем.

Фундамент должен быть той средой, в которую эффективно и естественно вписываются методы решений проблем реального мира. Мы должны представлять реализуемые идеи в терминах частей нашего знания и интерфейсов между ними. При конструировании моделей мы должны иметь возможность добавлять туда новые компоненты, расширять модели, без необходимости переписывать их с нуля. Многие из этих компонентов могут быть добавлены при помощи декларативных формализмов, таких как исчисление кванторов, путем простого введния новых аксиом. Императивные формализмы, такие как акторы, не могут быть автоматически расширены так же легко. Однако, мы вводим механизмы, которые позволяют добиваться огромной гибкости при добавлении новых процедурных компонентов.

Для тех, кто сомневается в надлежащем качестве перевода, привожу оригинальный кусок:

Our aim is to build a firm procedural foundation for problem solving. The foundation attempts to be a matrix in which real world problem solving knowledge can be efficiently and naturally embedded. We envisage knowledge being embedded in a set of knowledge boxes with interfaces between the boxes.

In constructing models we need the ability to embed more knowledge in the model without having to totally rewrite it. Certain kinds of additions can be easily encompassed by declarative formalisms such as the quantificational calculus by simply adding more axioms. Imperative formalisms such as actors do not automatically extend so easily. However, we are implementing mechanisms that allow a great deal of flexibility in adding new procedural knowledge.

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



Последнее исправление: anonimous (всего исправлений: 2)

Объясните, почему все её называют «модель акторов»? Либо уж переводить до конца «модель актёров», либо «actors model», если уж нравится пачкать русскую речь.

BattleCoder ★★★★★
()
Последнее исправление: BattleCoder (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

Объясните, почему все её называют «ракета»? Либо уж переводить до конца «веретено», либо «rоссhеttа», если уж нравится пачкать русскую речь.

По лицензии GPL, оригинал: Боевой Кодер, раз уж на то пошло:)

anonimous
() автор топика

Не помню, что там с ерлангом, но скала точно не ФП. В ней можно писать как на ФП, но я лично чаще пишу императивно.

Ну и не надо считать, что раз человек придумал идею, значит он теперь пророк и каждое его слово - истина. Раз легла модель акторов на ерланг, значит нормально оно с ФП вяжется.

Legioner ★★★★★
()
Ответ на: комментарий от BattleCoder

Объясните, почему все её называют «модель акторов»? Либо уж переводить до конца «модель актёров», либо «actors model», если уж нравится пачкать русскую речь.

Актёры в кино играют, а акторы это концепция в программировании. Зачем плодить омонимы, когда можно этого не делать? По-мне «актёры» звучит по-дурацки. В английском, кстати, тоже, но я не носитель и мне это ухо не режет. А вот «акторы» - и понятно всем и ухо не режет, совсем другое слово.

Legioner ★★★★★
()
Ответ на: комментарий от BattleCoder

Этимологии тред

Либо уж переводить до конца «модель актёров»

Объясните, почему все её называют «модель»? Либо уж переводить до конца [от старославянского] «образ», либо « modello» [из вульг. лат. *modellus], если уж нравится пачкать русскую речь.

anonymous
()
Ответ на: комментарий от Legioner

А мне наоборот ваше «акторы» ухо режет куда сильнее. А концепцию именно так и назвали, что актёры - они играют (необязательно в кино) на сцене, в театре. Действуют. Реагируют на события. Потому так и назвали.

BattleCoder ★★★★★
()

эрланг и скала, которые являются ФП с примесью ООП

scala - ООП язык с примесью ФП. И агенты там очень таки императивные.

В c# TPL DataFlow агентов можно было бы соединять каналами связи декларативно, но внутри они все равно остаются императивщиной.

Что там у эрланга - не в курсе.

RedPossum ★★★★★
()
Ответ на: комментарий от blexey

Они там вообще отдельной библиотекой (хотя недавно стала частью языка). Причём её можно даже из Java цеплять. Вот в Java наверное и правда не к месту... (не пробовал)

BattleCoder ★★★★★
()
Ответ на: комментарий от Legioner

В английском, кстати, тоже

В английском это слово имеет также значения деятель, агент, персона (doer, personality, agent), поэтому, там все норм.

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

anonimous
() автор топика
Ответ на: комментарий от RedPossum

А Вы ставите знак равенства между ООП и императивщиной? Там какое ООП, класс-ориентированное? Если да, то это скорей порождение ФП в современной его трактовке, ящетаю.

anonimous
() автор топика
Ответ на: комментарий от anonimous

Откуда у тебя взялось какое-то мнение на эту тему, если в ФП ты ничего не понимаешь?

anonymous
()

Во-первых, не все ли равно?
Во-вторых, лично я всегда думал, что акторы - это ближе к ООП. Есть актор (некая изолированная сущность), он получает от других акторов сообщения, выплевывает результат. Черный ящик, не?

kovrik ★★★★★
()
Ответ на: комментарий от kovrik

Есть актор (некая изолированная сущность), он получает от других акторов сообщения, выплевывает результат. Черный ящик, не?

То что Вы описали, в точности соответствует определению функции с локальным скопом (черный ящик), это ФП. Современное ООП скопировало эту модель, и в этом смысле ничем не отличается от ФП. Оно отличается только от «чистого ФП», где состояние объекта нельзя менять не только снаружи, но и изнутри.

anonimous
() автор топика
Ответ на: комментарий от anonimous

А Вы ставите знак равенства между ООП и императивщиной?

Нет нет, я не про ООП, а про сами акторы. Избавляться от имеративщины при конструировании агентной системы сложно:

Даже если рассматривать агенты как некую функию(Message=>Message), а соединение акторов в сеть описывать декларативно, остаётся рутинг, который таки придётся делать в сколь-нибудь сложной системе в процессе её(системы) работы, и я себе слабо представляю как это сделать декларативно. Это подход TPL WorkFlow.

А если рассматривать агенты как в akka, то там вообще есть состояние (become/unbecome), меняющее как метод обработки сообщений, так и рутинг.

Вот как то так я на это смотрю, то есть, я уверен, что можно и все сразу сделать декларативно, но это как линукс на десктопе, если вы понимаете о чем я.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

И я так подумал, TPL действительно ближе к CSP, чем к авторам вообще, хотя они сами по себе близки до смешения.

RedPossum ★★★★★
()

скала, которые являются ФП с примесью ООП,

У тебя какое-то своебразное представление о скале. Скала это аналог плюсов для джавы. Да в ней можно использовать ФП, но в реальном продакшен коде на скале этого ФП столько же сколько и в коде на каком-нибудь питоне.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Да, поспешил наверное, посмотрел в вике:

сочетающий возможности функционального и объектно-ориентированного программирования.

и подумал, что он преимущественно функциональный, вроде схемы.

anonimous
() автор топика
Ответ на: комментарий от anonimous

Акторы часто имеют изменяемый сообщениями state, так что они ближе к объектам чем к функциям. Не говоря уже про то, что в качестве реакции на сообщение актор может послать сообщения в несколько разных акторов не связанных с источником оригинального сообщения

maxcom ★★★★★
()

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

anonymous
()

Состояние эктора все время крутится в рекурсивной функции, которой оно передается как аргумент. Тем не менее, оно меняется. Это и имеется, по-видимому в виду, когда говорится об императивности.

geometer
()
Ответ на: комментарий от maxcom

Ну, во многих языках, например в JS, функции могут иметь собственное изменяемое состояние, с возможностью модификации изнутри функции. В этом смысле они ничем не отличаются от объектов.

что в качестве реакции на сообщение актор может послать сообщения в несколько разных акторов не связанных с источником оригинального сообщения

Функция может сделать ровно то же самое, она это и делает, когда вызывает изнутри себя другие ф-ции. Даже чистые функции с иммутабельным состоянием, могут это сделать.

anonimous
() автор топика
Ответ на: комментарий от anonymous

Та, неважно, понятно было из контекста:)

anonimous
() автор топика
Ответ на: комментарий от anonymous

на акторный пролог

Да, и кстати, тут всплывает интересный момент, насколько я помню, у Хьюита были трения с создателями оригинального пролога. Вот цитата с хабра:

В 1988 году Роберт Ковальски, создатель языка Пролог, выдвинул тезис, что «вычисления могу быть сгруппированы по логическим выводам». Это справедливо для последовательных вычислений и для некоторых моделей параллельных. Но в 1988 году Hewitt и Agha опубликовали статью Guarded Horn clause languages: are they deductive and Logical?, в которой показали, что для модели акторов это неверно в следующем смысле: текущее состояние программы может дедуктивно не следовать из предыдущего. Что это значит на практике: отладка программы на основе модели акторов не так эффективна, как в случае последовательных программ.

источник

anonimous
() автор топика
Ответ на: комментарий от buddhist

Ага, вы правы. Я думаю, английское слово «paper» тут правильнее было бы перевести по-другому, например, как «документ». Ложные друзья переводчика, или близко по смыслу (кто-то на лоре уже ссылкой туда бросался).

Во мне умер переводчик. К сожалению. Наверное. Всё-таки java-прогерам платят побольше в нашей деревне.

BattleCoder ★★★★★
()
Ответ на: комментарий от BattleCoder

Вы не понимаете одной простой вещи. Есть такое явление, как устоявшиеся выражения, в том числе, англицизмы. Русский, вообще, состоит из заимствований чуть более, чем на 99%. Тот подход, что Вы проповедуете, обычно часто можно услышать от тех, кто переводит тексты исключительно по словарю. Это дилентантство в крайнем своем проявлении.

anonimous
() автор топика
Ответ на: комментарий от vonenij

А почему бы нет:)

Если серьезно, я только бегло ознакомился, и пока очень смутно представляю тему. В частности, не слишком очевидно, чем она отличается от тру ООП в Аланкеевском смысле. Запостил, чтоб самому легче было разобраться. А почему бы, собственно не ввести моду? Это преподносится обычно как панацея, учитывая, что ресурс увеличения тактовой частоты исчерпан. А акторы - это ведь тру-паралеллизм, весьма актуальная тема.

anonimous
() автор топика
Ответ на: комментарий от Legioner

Актёры в кино играют, а акторы это концепция в программировании.

Вообще-то слово актер обозначает именно вот это. Acting is a work of an actor.

r ★★★★★
()
Ответ на: комментарий от anonimous

Докатились, anonimous с авторитетным видом вещает в сторону взрослых дядек про дилетантство. А завтра что, картинки на лоре можно будет в посты вставлять?

anonymous
()
Ответ на: комментарий от Reset

Продакшен на скале ващета разный. Вот у нас с чуваками на раёне^Wпроекте есть legacy-код и он да, написан как на яве, только на скале. И есть фреймворк, который мы пилим на замену. И вот там как раз подходом по умолчанию является функциональщина, монады и аппликативные функторы.

Zenom ★★★
()

У акторов есть состояние. ФП - стиль программирования. В скала акторы могут беспрепятственно использовать состояние или описываться в ФП стиле через become/unbecome. Но они остаются машинами состояний

vertexua ★★★★★
()
Ответ на: комментарий от Legioner

На скале можно писать тремя способами - в основном императивно, в основном функционально и решать хаскелль-проблемы. Второй - самый лучший.

vertexua ★★★★★
()
Ответ на: комментарий от Zenom

Ну эти понятно, может еще Validation*. Я думал вы часто свои пишете или ононируете в стиле State-монады. А когда у вас аппликативные функторы используются?

vertexua ★★★★★
()

императивщина + акторы = ерланг

java + фп + перегруженный синтаксис + перегруженная модель ООП = scala

а акторы есть и в питоне (см. pykka, как я понял, слизано с скаловской akka)

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

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

anonimous
() автор топика
Ответ на: комментарий от vertexua

Ну, стейт то действительно онанизм, чай не хаскель. А своего ничего писать пока не приходилось.

С аппликативными функторами та же история. Того, что реализовано в scalaz хватает.

Zenom ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.