LINUX.ORG.RU

Любопытный факт из истории смоллтока

 , ,


1

3

Оказывается, ранний смоллток был концептуально очень похож на модель Акторов, но позже деградировал. Вероятно, смоллток-80 уже не отражал в полной мере идеи Алана Кея, они были существенно искажены в этой реализации:

The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation. Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as «messages» for what essentially are procedure calls rather than one-way notifications). This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking.

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

Ответ на: комментарий от callbackhell

Модель акторов абстрагирована от среды, она на другом концептуальном уровне находится. Среда относится к вопросам реализации.

Или среда должна протечь в интерфейс экторов и они уже не будут богоподобными, или они будут беспомощным говном, такие дела.

A1
()
Ответ на: комментарий от callbackhell

c 13:30 обсуждается затронутый тобой вопрос

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

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

Слушай, ты понимаешь, что озвученная тобой проблема неразрешима в принципе? Это проблема не концептуального свойства, а физического. Ты отправляешь товарищу посылку, а ее ворует почтальен. Ты разговариваешь с кем то по телефону, и связь отрубается. Ты волшебства какого то ждешь? Хьюит поясняет, что актор содержит надежное хранилище. для решения таких проблем существует обратная связь, многократная пересылка, ты звонишь, связь обрывается, ты перезваниваешь, теряется посылка — друг тебе сообщает, что посылку не получил. Модель акоров прекрасно ложится на модели реального физического мира, настолько, насколько это возомжно, это выкристализованное, рафинированное ООП в чистейшем виде, незамутненное никаким мусором в виде Лисков и прочих кухарок от CS.

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

Слушай, ты понимаешь, что озвученная тобой проблема неразрешима в принципе?

Просто клиент должен решать что делать в каждом конкретном случае. Да, для этого он должен знать про сеть. Правда тут даже близко не пахнет экторами, но что поделать, дружок, реальность бессердечная сука.

A1
()
Ответ на: комментарий от callbackhell

незамутненное никаким мусором в виде Лисков и прочих кухарок от CS.

Соблюдать LSP и прочий SO.ID придется и с экторами, они не про парадигму, а про общие принципы проектирования. Отсоси еще разок.

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

Это все равно что утверждать, что для того чтобы уметь разговаривать и быть услышаннм, надо знать разделы физики занимающиеся тмосфернми явлениями, типа акустики.

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

Это все равно что утверждать, что для того чтобы уметь разговаривать и быть услышаннм, надо знать разделы физики занимающиеся тмосфернми явлениями, типа акустики.

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

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

Соблюдать LSP и прочий SO.ID придется и с экторами, они не про парадигму, а про общие принципы проектирования. Эти «общие принципы проектирования» порочны. Это односторонний подход, птающийся претендовать на общий, с успехом среди энтерпрайзного быдла, но с фейлом среди адекватных разработчиков.

Programming languages like ActorScript [Hewitt 2010] take the approach of extending behavior in contrast to the approach of specializing behavior: Type specialization: If type t1 is a subtype of type t2, then instances of t1 have all of the properties that are provable from the definition of type t2 [Liskov 1987, Liskov and Wing 2001]. Type extension: A type can be extended to have additional (perhaps incompatible) properties from the type that it extends. An extension type can make use of the implementation of the type that it extends. Type extension is commonly used to extend operating system software as well as applications. The term “inheritance” in programming has been used (sometimes ambiguously) to mean both specialization and extension.

http://arxiv.org/pdf/1008.1459.pdf

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

знать буквы и слова

Буквы и слова — это сообщения. С этим в модели Акторов все в порядке.

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

Просто клиент должен решать что делать в каждом конкретном случае.

Тебе никто не запрещает это реализовать поверх модели акторов. Создай абстракцию сети(а сеть, BTW, тоже актор) и выложи интерфейс, которым будут пользоваться другие акторы, для верификации доставки.

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

Эта фраза внезапно ничего не доказывает, это только достаточные свойства. Добро пожаловать в реальный мир опять.

A1
()
Ответ на: комментарий от callbackhell

Тебе никто не запрещает это реализовать поверх модели акторов.

Я и говорю, троллейбус из буханки хлеба может сделать любой идиот. Но зачем? Покажи профит.

A1
()
Ответ на: комментарий от ixrws

Ему под это дело ещё потребуется выпустить камень, умеющий реальное множественное async. Таким камнем может быть например аналог fpga, способный мгновенно переписывать свои области с помощью комманд.

Нахера? O_o

Потому что зачем тогда?

Это я спросил - зачем. Зачем тебе FPGA для асинхронщины?

Если бы железо было таким, тогда имеет смысл.

Что такого умеет гипотетический мгновенно перепрограммируемый FPGA, чего не умеет многоядерный проц, и почему это необходимо для асинхронщины?

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

Ну если по существу, то свой код на все случаи жизни писать не получится, если пишешь что-то более-менее объёмное.

Есть общее правило жизни - в одиночку нельзя сделать что-либо крупное. В одиночку придётся всё равно быть немного аскетом во всём.

С другой стороны, любой кто писал приложение хотя бы под две, пусть даже похожие платформы, знает что приходится делать либы которые решают более общие задачи. Часто на проектирование таких api уходит больше всего времени и ещё чаще, правильно спроектированное общее api экономит как время написания программы так и количество работающего кода. То есть тут внезапно оказывается что твоя позиция просто неверна по сути, она как бы берёт частные примеры плохих либ и говорит нам, что других либ не существует. Но увы существуют, и увы, ты можешь делать такие же плохие либы, если нет квалификации должной.

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

UI события. onClick/onKeyPress/onChange (для инпутов), и т.д. То что генерируется снаружи приложения.

А как же данные которые приходят аяксом?

Э-э-э. Действительно, они подписываются на события изменения стора (sic!) в didMount/didUnmount.

Ну вот да, я после этих примеров так же делаю.

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

Затем чтобы отдельные части программы выполнялись реально асинхронно, то есть именно программный код прошивать в проц в процессе выполнения программы.

Умеет реальную асинхронность, без mainloop, только через посыл сообщений между разными блоками. То есть одна программа будет состоять из сотен блоков, которые работают параллельно относительно друг друга. Многоядерный проц умеет только то число потоков, сколько у него ядер и декодеров. Это заставляет программы дробить на достаточно крупные куски в виде потоков и процессов, которые разделяют общие ресурсы. То есть два потока, которые делают сложные вычисления, запущенные на одном ядре будут работать в полсилы. С другой стороны две функции, прошитые в fpga, будут работать в полную силу, действительно параллельно.

Да конечно, можно пойти другим путём и взять что-нибудь вроде tilera и каждому потоку дать по ядру.

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

По тексту такое впечатление, что ты пьян уже с утра.

То есть одна программа будет состоять из сотен блоков, которые работают параллельно относительно друг друга. Многоядерный проц умеет только то число потоков, сколько у него ядер и декодеров.

И что? FPGA тоже умеет не больше потоков, чем у него «ядер и декодеров», а параллельность (и асинхронность, да) у процессора не менее честная.

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

А как же данные которые приходят аяксом?

Они должны менять глобальный стейт

Ну вот да, я после этих примеров так же делаю.

А профиты? Мало того что ты должен закатывать солнце руками с этой подпиской, так еще для каждого компонента должен городить прокси в стор.

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