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

Может ты уже наконец запилишь идеальные хуитовские экторы на ио, и покажешь как легко и просто решаются прикладные задачи? Отрисовка круга, например. Ты чо реально думаешь что ЗОГ против волшебства модели, которая мощнее MT?

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

Кстати, на Io акторы и так запилены. Но суть в том, что, если верить данной цитате, ранний смоллток был акторный чуть более чем полностью.

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

Я тут постил кодец недавно

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

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

Допустим, несколько взаимозависимых форм на странице в гуе.

Которые гораздо проще и очевиднее делаются на react-like с однонаправленным датафлоу. Подписка на события не работает в сложной гуйне, так как лапша из лисенеров не позволяет строить формализмы, отвратно тестируется и отлаживается. Попробуй написать что-нибудь прикладное — все илюзии растают.

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

Так в любом случае модель как минимум не плоха, что, вроде, доказывает эрланг. И я бы хотел попробовать ООП на асинхронных акторах.

loz ★★★★★ ()

да, поэтому читать надо первоисточники.

а не то что потом надмозги недоперевели.

например: двигатель Шкондина и эффект размагничивания при вращении. оказывается, ещё в 19 веке про этот эффект писали. причём сам Эрстед поначалу правильно — а затем стали считать неправильно. и 150 лет делали неэффективные электрические двигатели, не ответив (и не поставив) на вопрос: что вокруг чего должно вращаться (ну прям, по Копернику).

ещё есть книжки например, «Coders at work» — интервью с изобретателями языков, или, свят-свят-свят, «дизайн и эволюция чего-то там».

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

гламурный хипстерский недоязычёк для понифагов

ну или бронифагов.

язык программирования поней со встроенной дружбомагией.

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

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

Честно говоря, эрланг доказывает как раз обратное.

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

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

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

Которые гораздо проще и очевиднее делаются на react-like с однонаправленным датафлоу.

Что имеется в виду? IObservable из .NET?

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

https://facebook.github.io/react/

Есть глобальный стейт приложения, на каждом фрейме оно отрисовывается заново (или создается такое ощущение), обработчики ui-событий (мышь/клавиатура) знают только про глобальный стейт и могут его менять (как вариант это персистентная структура, можно хранить историю, бесплатно получить undo/redo).

Стоит разок попробовать и начинаешь шарахаться от подписки на события и кастомных emit как от чумы.

A1 ()
Ответ на: да, поэтому читать надо первоисточники. от anonymous

например: двигатель Шкондина и эффект размагничивания при вращении. оказывается, ещё в 19 веке про этот эффект писали. причём сам Эрстед поначалу правильно — а затем стали считать неправильно. и 150 лет делали неэффективные электрические двигатели, не ответив (и не поставив) на вопрос: что вокруг чего должно вращаться (ну прям, по Копернику).

Ты что, друг напильника? Где вы этот бред только находите.

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

В эрланге большая часть кода любого приложения это классическая императивщина.

Так это императивщина же и есть ООП)

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

Так это императивщина же и есть ООП)

Асинхронная императивщина, ню-ню.

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

Стоит разок попробовать и начинаешь шарахаться от подписки на события и кастомных emit как от чумы.

В самом реакте этого нет, может ты про flux сейчас? Вобще у них в примерах я как раз и видел много кастомных emit.

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

В самом реакте этого нет, может ты про flux сейчас?

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

Вобще у них в примерах я как раз и видел много кастомных emit.

Разве что подписка контейнеров. Там же есть трейдофф с протаскиванием пути в контейнере с инкапсуляцией структуры состояния от компонент. Во flux ничего лучше лисенеров не придумали (которых на порядки меньше и они разбросаны в контролируемых точках). Но есть куча других подходов, например om с курсорами, всякие персистентные штуки (с фактически одной подпиской на все приложение) или распространение изменения через компоненты вверх (если дерево можно отобразить на стейт и родитель знает, за какие данные отвечает непосредственный потомок).

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

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

Ах да, ведь подобное для массового производства так и не смогли сделать из-за чрезвычайной сложности и дороговизны:)

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

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

Нахера? O_o

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

Ему под это дело ещё потребуется выпустить камень

Вычислительная эффективность это другая проблема. Пусть сначала на эмуляторе профиты покажет.

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

Почитай GoF, там на каждой странице есть примеры как нужно это делать.

Люто, яростно плюсую этот пост и цитату. Что бы там ни говорил ТС про GoF, эта книга - отличный пример того, как _правильно_ показывать применимость той или иной программной идиомы для решения _практической_ задачи. Потому-то она и настолько популярна.

В свою очередь, пост ТС - хрестоматийный пример вброса без аргументов.

Товарищ anonimous callbackhell - если ты хочешь, чтобы тебя поняли - измени, пожалуйста, способ донесения своих мыслей до собеседников. Иначе ничего, кроме негатива, тупняка и клоунады в ответ получить не удасться.

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

flux это переусложненная и перехайпленная простая идея.

А в чем идея то? Как я понял из их примеров - из сторов кидать события изменения данных, а компонентами подписываться на них.

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

Как я понял из их примеров - из сторов кидать события изменения данных, а компонентами подписываться на них.

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

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

Что значит события из мира?

Каждый компонент знает только то, что ему передают, как state (или то, что он себе заиницилизировал в getInitialState). Изменение state и есть «событие из мира». Напрямую менять state нельзя, только через вызов метода setState (если всё правильно помню, т.к. писал на Clojure Om).

Фишка в том, что React берёт не себя всю возню со state UI компонент и гарантирует, что state не изменяем во время отрисовки. Хочешь сменить state компоненты? Будь добр послать ей сообщение setState. В итоге получается довольно удобно.

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

Потому что зачем тогда? Обычное смолтолковское ООП хорошо работает, многим нравится, легко ложится на любую современную архитектуру. А что ещё нужно?

Если бы железо было таким, тогда имеет смысл. Но тогда надо будет ещё и интерфейсы делать такими. В общем смена парадигмы должна быть полностью, иначе нет никакого смысла.

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

Будь добр послать ей сообщение setState. В итоге получается довольно удобно.

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

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

Но ведь это основной принцип инкапсуляции (в правильном смысле), не внешний код меняет состояние объекта

Причём тут инкапсуляция то? Тут речь про удобную реализацию observer с защитой от race condition.

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

Ну так, таким же манером и объект защитит от гонки. По вашему примеру — если идет отрисовка, объект кидает сообщения в очередь на событие конца отрисовки.

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

Ну так, таким же манером и объект защитит от гонки. По вашему примеру — если идет отрисовка, объект кидает сообщения в очередь на событие конца отрисовки.

Ога ога. А очереди сами по себе появляются? Их реализовывать надо. А зачем велосипедить то, что уже есть в виде библиотеки?

Никто же не говорит, что с React можно делать то, что до него было нельзя, нет. С React можно делать быстрее и проще то же, что и раньше, но не более.

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

Вот https://github.com/facebook/flux/tree/master/examples/flux-chat

Э-э-э. Действительно, они подписываются на события изменения стора (sic!) в didMount/didUnmount. Вообще противоположность тому что на конфах рассказывают, поток данных в другую сторону повернут.

Что значит события из мира?

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

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

Чтобы не изучать библиотеку, не забивать мозги, не напарываться на подводные камни, на всплывающие через год неожиданности? Есть хорошая пословица: если хочешь сделать что-то хорошо, сделай это сам. Свой код легче воспринимать, легче поддерживать, легче изменять. Библиотеки всегда пишутся под более общую задачу, а твой собственный код, заточенный под конкретную, всегда будет эффективней, гибче и проще.

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

Изменение state и есть «событие из мира»

Nope. state может быть поменян только самим компонентом (в 0.14 гайки закрутили). loz, я кстати понял почему пример выше такую оторопь вызвал, эти гаврики через бравый _onChange эмулируют изменение стейта внешней средой, что как бы противоречит идее реакта, это очень смешно. Хорошо что я даже не стал пробовать включить флакс в проект, профитов по сравнению с jQuery + store эта модель дать не может.

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

В общем смена парадигмы должна быть полностью, иначе нет никакого смысла.

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

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

Свой код легче воспринимать, легче поддерживать, легче изменять

Что еще раз доказывает, что ничего сложнее хеловордов ты не писал, лол.

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

То есть вызубрить чужой код и поддерживать его для тебя легче, чем написать свой? Ну тогда мои поздравления, ты являешь собой гомосапиенс класса «зубрилко»

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

Просто ты ее не понимаешь. Те же асинхронные коллбэки в JS — это чрезжопная неочевидная реализация тех же акторов. Это наиболее адекватная модель для конкурентных систем. Просто удивительно, что это не доходит до большинства дезигнеров. Впрочем, неудивительно, мейнстрим на то и мейнстрим, чтобы них*я не понимая, строчить тупой код.

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

Я имел ввиду setState с передачей нужных callback'ов внутрь child'ов для child-parent взаимодействия. Я, как обычно, немного криво выразился. Списываю на то, что давно сам на React не писал ничего.

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

А зачем велосипедить то, что уже есть в виде библиотеки?

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

Нука, давай кукарекалка, рассказывай, с чего тебе в твою башку пришла идея о зубрении кода? Тебе, дурилке, предложили использовать библиотеку, ты сказал «лучше писать свою, так лучше поддерживать». Ты весь код исходника Io выучил? весь код всех его либ?

А теперь, теоретик мамким, давай расскажи как бы будешь писать свою БД например (хотя да, тыж адепт текстовых файлов и любую логику ты разрулишь на них, лол), расскажи как ты ssl/tls сам зарулишь и будешь это потом поддерживать. И сколько ты планируешь поддерживать свои проекты, например? всю жизнь? ну тебе придется, потому что в том говнокоде, что ты пишешь разобраться сможешь только ты сам. Зато ты подтвердил свое гордое звание пиздобола-фантаста 2 степени и мамкиного теоретика.

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

Это наиболее адекватная модель для конкурентных систем

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

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

Как минимум тебе придется учить интерфейс и доки по работе. Если что-то удет непонятно, или не заведется, полезешь в исходники, или будешь бегать с бубном. зато потом станешь адептом, и будешь на форумах кукарекать — это приятно. Знание язка и его стандартных либ — это необходмй минимум. Сейчас, внезапно, наблюдется иная картина, люди не знают язык, и обмазываются либами. Это смешно, но это факт. В итоге при ложения жиреют и кривеют.

Так что, по поводу зубрежки все остается в силе, смирись.

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

Библиотеки всегда пишутся под более общую задачу, а твой собственный код, заточенный под конкретную, всегда будет эффективней, гибче и проще.

Ога. Мне вот сразу вспоминается, как приходится писать обёртки INotifyPropertyChanged для свойств в WPF. Ничего сложного, но через 5-6 свойств уже надоедает. Так что зачем делать то, что может сделать за тебя хорошая либа?

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

Ты сказал много и как обычно х-ню. Если будет что-то непонятно, я могу сходить к исходникам, это правильно. Еще я могу сходить к автору.

Знание язка и его стандартных либ

Ты весь код Io знаешь наизусть? Весь его вызубрил? И если нет, то какого хрена?

И ты не ответил, что ты будешь делать когда нужно будет БД? ssl/tls. Много ты своим умишкой родишь?

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

И кстати, поправь меня, если ошибаюсь. Хюит же ничего не говорил о свойствах среды в которой рспространяются сообщения, кроме того что оно когда-нибудь будет доставлено. Но в современном мире распределенные системы работают через сраный tcp/ip и факапам при доставке сообщений посващен отдельный раздел CS. Без учета этого модель просто в принципе не применима к прикладным задачам, на которые (как тебе кажется) экторы прекрасно кладутся.

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

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

Да

Без учета этого модель просто в принципе не применима к прикладным задачам

Почему не применима? Всего ведь учесть ни в какой модели невозможно. Машина Тьюринга тоже не применима, во-первых, потому что никакой бесконечной памяти нет, во вторых, потому что время выполнения алгорима имеет значение, в третих, потому что она может сломаться при работе, или «быть реализована с ошибками». Последнее — это курьез, и точно такой же курьез — то что ты говоришь о среде. Модель акторов абстрагирована от среды, она на другом концептуальном уровне находится. Среда относится к вопросам реализации.

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