Здравствуйте, Sinclair, Вы писали:

4>>Поскольку Smalltalk полностью динамический, то Кей решил назвать "сообщением" — вызов метода, которого у объекта может не быть.
S>Всё наоборот. Началось всё с сообщений, которые объект может обрабатывать по своему желанию.
S>И уже из этой идеи стала вытекать полная динамичность смолтока.

Который, тем не менее, пригоден для статической компиляции, чем и занимается его JIT. ))


S>Поэтому нет никакой проблемы, скажем, отправить блок кода на исполнение удалённому объекту — как это сделано в СУБД GemStone.

Это следствие другого принятого решения — компиляции кода под архитектурно-независимую VM, т.е. оно перпендикулярно ООП-парадигме.


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

А это следствие еще одного решения — хранения метаинформации вместе с кодом.


S>Плюс там по аналогии с лиспом, которым Кей открыто вдохновлялся при проектировании смолтока, код существует в виде данных.

Если взглянуть внимательнее, то видно, что авторы более вдохновлялись Фортом (за авторством Чарльза Мура).
Сам Форт — это, по-сути, "бинарная" версия Лиспа, работающая эффективнее Лиспа порой на порядок.
Ну и, меньше скобок, больше синтаксиса, чище код.
Но обратная польская запись осталась. ))
Плюс расплатой за эффективность стало явное оперирование состоянием стека (вернее, это был способ резко повысить эффективность на технике тех лет).

Смолтолк, считай, довёл цепочку Лисп-Форт-... до логической завершённости.
Заодно позволил обкатать ООП-парадигму, показать её эффективность.
(на Форте экспериментировали с "объектами" с самого начала)

В итоге ООП выиграло гонку популярности у ФП по очевидным причинам: ООП включало в себя целиком все известные на тот момент парадигмы — структурную и функциональную.
И если, скажем, ФП представляло из себя набор ограничений, то ООП представляло собой набор инструментария, в т.ч. для разработки другого инструментария, т.е. парадигма заведомо разрабатывалась для "расширения", а не ограничения. Первая человеческая IDE на Смолтолке с кучей функциональности (например, первый в мире автоматический рефакторинг) — самое яркое тому подтверждение. ))

Вдогонку, ООП-парадигма включила позже естественным образом даже модели из паралельных вычислений — модели акторов с мейлбоксами и модели конкурирующих сигналов.
Т.е. ООП-парадигма на сегодня является наиболее полной парадигмой из всех известных.

Взять даже наш давний спор об имутабельности vs const в С++.
Этот спор был изначально глуп с моей т.з., бо как можно сравнивать подмножество с полным множеством?
Через const в С++ можно выразить абсолютно все сценарии вокруг иммутабельности целиком, но это будет лишь небольшая вершинка айсберга всех сценариев, покрываемых const.
Зато наоборот — дудки. ))

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

Здравствуйте, Sinclair, Вы писали:

4>>Поскольку Smalltalk полностью динамический, то Кей решил назвать "сообщением" — вызов метода, которого у объекта может не быть.
S>Всё наоборот. Началось всё с сообщений, которые объект может обрабатывать по своему желанию.
S>И уже из этой идеи стала вытекать полная динамичность смолтока.

Который, тем не менее, пригоден для статической компиляции, чем и занимается его JIT. ))


S>Поэтому нет никакой проблемы, скажем, отправить блок кода на исполнение удалённому объекту — как это сделано в СУБД GemStone.

Это следствие другого принятого решения — компиляции кода под архитектурно-независимую VM, т.е. оно перпендикулярно ООП-парадигме.


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

А это следствие еще одного решения — хранения метаинформации вместе с кодом.


S>Плюс там по аналогии с лиспом, которым Кей открыто вдохновлялся при проектировании смолтока, код существует в виде данных.

Если взглянуть внимательнее, то видно, что авторы более вдохновлялись Фортом (за авторством Чарльза Мура).
Сам Форт — это, по-сути, "бинарная" версия Лиспа, работающая эффективнее Лиспа порой на порядок.
Ну и, меньше скобок, больше синтаксиса, чище код.
Но "неестественная" запись осталась. ))
Плюс расплатой за эффективность стало явное оперирование состоянием стека (вернее, это был способ резко повысить эффективность на технике тех лет).

Смолтолк, считай, довёл цепочку Лисп-Форт-... до логической завершённости.
Заодно позволил обкатать ООП-парадигму, показать её эффективность.
(на Форте экспериментировали с "объектами" с самого начала)

В итоге ООП выиграло гонку популярности у ФП по очевидным причинам: ООП включало в себя целиком все известные на тот момент парадигмы — структурную и функциональную.
И если, скажем, ФП представляло из себя набор ограничений, то ООП представляло собой набор инструментария, в т.ч. для разработки другого инструментария, т.е. парадигма заведомо разрабатывалась для "расширения", а не ограничения. Первая человеческая IDE на Смолтолке с кучей функциональности (например, первый в мире автоматический рефакторинг) — самое яркое тому подтверждение. ))

Вдогонку, ООП-парадигма включила позже естественным образом даже модели из паралельных вычислений — модели акторов с мейлбоксами и модели конкурирующих сигналов.
Т.е. ООП-парадигма на сегодня является наиболее полной парадигмой из всех известных.

Взять даже наш давний спор об имутабельности vs const в С++.
Этот спор был изначально глуп с моей т.з., бо как можно сравнивать подмножество с полным множеством?
Через const в С++ можно выразить абсолютно все сценарии вокруг иммутабельности целиком, но это будет лишь небольшая вершинка айсберга всех сценариев, покрываемых const.
Зато наоборот — дудки. ))

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