А так ли много потеряно?
Как-то не убеждают меня приведенные аргументы, что мы идем неверным путем. Сейчас я попробую каждый из них прокомментировать. Я не настаиваю на своей точке зрения — напротив, очень хотелось, чтобы, если я чего-то не вижу, мне это объяснили. Поскольку я совершенно не разбираюсь, в частности, в SmallTalk и мое мнение о нем основано на той самой статье, на которую ссылается _vovin.

Итак, концепция ООП чудовищно изуродована и сужена? То есть многое, что легко и красиво можно реализовать при изначальной трактовке ООП, становится сложным и запутанным, а подчас и невозможным?
Сразу оговорюсь,

_>Но это является пагубным упрощением, которое практически сводит на нет всю идею объектного подхода. Где главным выигрышем является возможность непосредственного манипулирования динамическим миром объектов посредством гибкой операции посылки сообщения, минуя привычную чрезмерную серию трансформаций текст->код->запуск->взаимодействие->результаты->текст->...
Не понимаю...
Во-первых, откуда хвост "результаты->текст->..."? Что это за процесс описывается, создание программы, что ли?
Во-вторых, как переход от концепции вызова метода к концепции посылки сообщения позволит обойтись без текста, или кода, или взаимодействия? Ну ладно еще без запуска — при определенной организации создаваемого кода его может быть просто не нужно как-то особо запускать...
А насчет описанного в предлагаемой статье примера процесса разработки можно сказать: такой подход отличается от обычного лишь тем, что окна отладчика все время висят на экране. Все равно в какие-то моменты времени программист ими пользуется, а в другие — пишет код и реализует методы, и вот тогда ему отладчик совершенно не нужен. Иногда, конечно, нужен (ради того самого контекста выполнения) — но ведь для редактирования кода не обязательно выходить из режима отладки, можно продолжать любоваться контекстом.

_>Кое-что на эту тему можно прочитать здесь.
Стало жутко интересно, прочитал. Не убедили

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

такие языки называются prototype-based; в них создание новых типов объектов осуществляется посредством клонирования имеющихся и внесения изменений непосредственно в структуру нового объекта

То есть я в ответ на некое сообщение могу взять какой-то прототип, сделать с него копию и выкусить из копии пару полей или реакций на события? А какая мне от этого польза, ведь объекты, сконструированные на базе такого прототипа, не будут целостными? Ну, в плане добавления полей и реакций все вроде бы понятно. Непонятно только, зачем это делать при эксплуатации разработанной программы? Ведь возможные генерируемые таким образом прототипы все равно должны быть учтены при проектировании, а тогда их, вероятно, лучше описать заранее, чтобы не осложнять понимание программы? Иначе говоря, я опять же не вижу реальных преимуществ по сравнению, скажем, с Delphi и тем более с C# (C++ в расчет не беру только потому, что в языке отсутствует возможность конструирования объектов, класс которых на этапе компиляции неизвестен).

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

Автор-то понимает, о чем сказал, а мне как быть? Что это означает и какие возможности открывает?

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

Наконец, объясните мне, почему концепция вызова метода не может быть очень легко расширена до концепции посылки сообщения? В примитиве это вполне возможно даже в C, вспомним WinAPI SendMessage Если же сопроводить сообщение метаданными, описывающими передаваемую информацию и т.п., то разве концепции вызова метода будет недостаточно для воспроизведения операции посылки сообщения? Я не знаю, может быть, и нет.... Тогда, пожалуйста, объясните, в чем я ошибаюсь.

---

Теперь про скорость.

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

Заметим, что посылка сообщения реализуется в динамических языках реализуется исключительно эффективно. По скорости она незначительно медленнее статического вызова. И, естественно, намного эффективнее виртуального вызова. (1)

Неплохо! Но в то же время:

Чем же таким особым обладает операция посылки сообщения (message passing), по сравнению с обычным вызовом метода (method invocation), который применяется в статически-типизированных языках?
Для начала, стоит разобрать из каких этапов состоят эти две операции.
И то, и другое имеет два основных этапа: поиск метода (method lookup) и собственно вызов метода (method invocation).

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

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

Slicer