Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

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

LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

То ли перевод сделан через задницу, то ли статья состоит из "WAAT?!!" чуть менее, чем полностью. А скорее всего — и то, и другое.

Возражение 1: структуры данных и функции не должны быть связанными друг с другом

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

Так как функции и структуры данных имеют разную природу, не надо считать их одинаковыми и работать с ними как с одинаковыми сущностями.

Это с чего бы вдруг? Кофе и молоко имеют разную природу и никто не считает их одинаковыми, но латте и капучино вполне себе нормально существуют. Желание описать основные методы работы с данными где-то непосредственно рядом с их структурой — вполне естественное и закономерное, точно так же, как и желание скрыть часть этих методов. Если эрланг позволяет сделать что-то подобное, не прибегая для этого к ООП — значит надо было такой пример показать и объяснить, чем конкретно он лучше. Иначе это звучит как религиозный догмат "да не объедини ты функции и структуры воедино", и все типа срочно должны в него уверовать.

Возражение 2: всё есть объект

...и в качестве примера, конечно же, Smalltalk и число 3 в качестве объекта.

Конечно, ведь он до сих пор остается ООП-мейнстримом, а не эти ваши всякие java, .Net, python и прочие неудачники, отказавшиеся от реализации "числового пуризма".

Возражение 3: в объектно-ориентированных языках определения типов данных распространяются везде

В Erlang или C можно определить все типы в одном включаемом файле или словаре данных.

Ага, можно. Вот только давайте-ка вспомним, когда в последний раз нам было нужно использовать в своей программе абсолютно все типы данных, которые нам может предоставить какая-нибудь библиотека? М-м-м-м... Постойте... Кажется... Никогда?! И даже в дремучие времена сишных хедер-файлов это было скорее их недостатком, чем достоинством.

В объектно-ориентированном языке мне придётся выбирать объект, в котором я определю глобальный тип. Все остальные объекты, которые захотят использовать эту структуру данных, должны наследовать этот объект.

Да сирьёзна штоле?! То есть если я хочу в своей программе использовать java.util.HashMap — то я должен отнаследовать класс от java.util.HashMap? Просто сделать new и создать экземпляр объекта в нужном методе внезапно стало уже недостаточно, или инстанцирование уже не считается использованием?

Возражение 4: у объектов есть приватное состояние

Состояние — корень всех зол.

Кстати, аминь.

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

Выделенное — это, кажется, называется "создать проблему, а потом героически преодолеть её"? В этом, наверное, есть много доблести, но кто сказал, что это лучше — где критерии оценки, где примеры того, как эту проблему элегантно позволяет решить эрланг? Навсякий: создание копии состояния при каждом чихе — это нифига не решение.

ЗЫ Ну и вывод в статье шикарен, в стиле "ООП — г..но, поэтому оно создало индустрию, эрланг гениален, поэтому никак не может создать". Где-то рядом, наверное, тихо плачут создатели терияков и работающих на воде двигателей внутреннего сгорания, задушенные индустрией большой фармакологии и нефтедобычи, соответственно.

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Нет, автор статьи (в интернете) неправ.

Пример: сложная иммутабельная структура данных (тот же TrieMap). Что лучше — заставить пользователя вручную её модифицировать для добавления и удаления элементов или предоставить простой интерфейс, инкапсулируя реализацию?

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

П>ЗЫ Ну и вывод в статье шикарен, в стиле "ООП — г..но, поэтому оно создало индустрию, эрланг гениален, поэтому никак не может создать".

Не, классический ООП — та еще кака, но аргументы в статье действительно ни в Красную Армию.

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

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

LVV>>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

AA>Нет плохого или хорошего, есть Common Lisp.
AA>

AA>;(loop for i from 1 to 10
AA>;    do
AA>;    (write-line "Lisp вечен!"))
AA>;

Large
Integer of
Stupid
Parentheses

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Какое-то унылое нытье. Наверное, можно при желании и более интересную критику ООП найти.

Аргументы в статье, как мне кажется, совершенно не по делу.

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

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

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

Статья, кстати, плохая. Не за то критикует.

LVV>>То и удивительно, что ООП существует с середины 60-х годов.
AG>А разве не с начала/середины 80-х?
Нет, вьюнош , гораздо раньше ... : )
AG>Во времена, когда Керниган и Ритчи изобрели UNIX и Си (начало 70-х) — они сделали прорыв в структурном программировании.
AG>Это и было "дальними подступами" к ООП. По настоящему ООП появился на десять лет позже, но UNIX API был прелюдией к нему.
AG>P.S. Я полагаю, уважаемый профессор, что Вы помните всю историю развития ИТ и это — простая опечатка...
Нет, не опечатка.
1. Норвеги еще в 1967 году создали язык для моделирования Симула-67.
С которого Страуструп и позаимствовал концепцию класса.
Ибо он тоже писал программы как ого-то моделирования на Си.
2. Язык SmallTalk был создан тоже значительно раньше.
Из Вики: Первая реализация, известная как Smalltalk-71, была создана за несколько месяцев как результат спора о том, что язык программирования, основанный на идее посылки сообщений, подсказанной Симулой, должен реализовываться на «странице кода». Более поздняя версия, действительно использованная для исследовательской работы, известна сейчас как Smalltalk-72.

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

S>>>Разве в классическом это не предусмотрено?
НС>>Не просто предусмотрено, а один из обязательных признаков. В том то и проблема.
S>Запутался я немного: C# это классическая реализация ООП или нет(гибридная)?

В основном классическая, особенно в ранних версиях. Из неклассического extension methods, default interface implementation, но это мелочи. Когда/если добавят шейпы, то будет уже не совсем классической.

AG>Если технологии того времени базировались на одной (пусть огромной) машине с одним CPU -
AG>то применение параллельности, вероятно, было скорее искуственным (типа распределение таймерных квантов),
AG>чтобы нейкая задача (ну или процесс) не стояли слишком долго в очереди...
а) в гражданке распараллеливание на уровне процессов в ОС называлось мультипрограммирование.
Наши еще в 64 кажись году (раньше американцев) сделали кластер из 16 машин Минск-22. Вполне себе многопроцессорная машина в гражданке.
А конвеер в процессоре у нас еще в БЭСМ-6 был реализован.
б) у вояк вполне были многопроцессорные ЭВМ.
Книжку Липаева надо поискать про историю наших военных машин.
М-5 — машина такая была тоже в конце 60-х. Помощнее БЭСМ-6.

Все прям такие начинающие...

scf>Нет, автор статьи (в интернете) неправ.
scf>Пример: сложная иммутабельная структура данных (тот же TrieMap). Что лучше — заставить пользователя вручную её модифицировать для добавления и удаления элементов или предоставить простой интерфейс, инкапсулируя реализацию?
То и удивительно, что ООП существует с середины 60-х годов.
А в 21 веке находится перец, который говорит, что функции и данные должны быть отдельно.
А еще удивительно, что инкапсуляцию этот перец считает злом...
Брукс еще в 1995 году признал, что Парнас был прав.
А этот деятель будто бы не читал Брукса...

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

AG>Здравствуйте, уважаемый LaptevVV, Вы писали:
AG>...
LVV>>То и удивительно, что ООП существует с середины 60-х годов.

AG>А разве не с начала/середины 80-х?

https://en.wikipedia.org/wiki/Simula

Dahl and Nygaard presented their paper on Class and Subclass declarations at the IFIP Working Conference on simulation languages in Oslo, May 1967. This paper became the first formal definition of Simula 67.

AG>Во времена, когда Керниган и Ритчи изобрели UNIX и Си (начало 70-х) — они сделали прорыв в структурном программировании.
AG>Это и было "дальними подступами" к ООП. По настоящему ООП появился на десять лет позже, но UNIX API был прелюдией к нему.

Нет.

AG>P.S. Я полагаю, уважаемый профессор, что Вы помните всю историю развития ИТ и это — простая опечатка...

Нет.

AG>Хотя, конечно потоки и процессы на уровне языка появились в C++ только в 2011-м.
На уровне языка в С++ они до сих пор не появились.
А вообще о параллельных процессах в языках — это опять 60-е годы.
APL, например. Очень нетрадиционный и интересный язык.
IBM даже для него создала специальную рабочую станцию.
Были специальные версии параллельных фортранов.

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Ну, а сам-то ты как считаешь?

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Это всё особенно смешно, если учесть, что процессы в Erlang в большинстве (gen_* based) такие же объекты. Отказывая данным внутри процесса и между процессами в собственном состоянии и правах доступа, он выстраивает такие же барьеры на границах процессов. Двоемыслие на марше.

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Ну, тут смотря что понимать под ООП. Надо сперва договориться о терминах. Вот в Rust есть ООП или нет?

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

LVV>Все прям такие начинающие...

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

П>То ли перевод сделан через задницу, то ли статья состоит из "WAAT?!!" чуть менее, чем полностью. А скорее всего — и то, и другое.

Всё правильно написал, но непонятно зачем Статья совершенно безумная, на неё только Лаптев и мог повестись.

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho

Нет плохого или хорошего, есть Common Lisp.

(loop for i from 1 to 10
    do
    (write-line "Lisp вечен!"))

Здравствуйте, Пацак, Вы писали:
П>Да сирьёзна штоле?! То есть если я хочу в своей программе использовать java.util.HashMap — то я должен отнаследовать класс от java.util.HashMap? Просто сделать new и создать экземпляр объекта в нужном методе внезапно стало уже недостаточно, или инстанцирование уже не считается использованием?
Он имеет в виду java.lang.object / System.Object.
Опять же враньё даже про java — см. напр. int/float/etc. Не говоря уже о системе типов .Net, где есть много чего мимо object.

N>Это всё особенно смешно, если учесть, что процессы в Erlang в большинстве (gen_* based) такие же объекты. Отказывая данным внутри процесса и между процессами в собственном состоянии и правах доступа, он выстраивает такие же барьеры на границах процессов. Двоемыслие на марше.

Похже Джо говорил, что Erlang — это как раз ООП в том виде, в котором его представлял себе Алан Кей.

Алсо: https://www.quora.com/What-does-Alan-Kay-think-about-Joe-Armstrong-claiming-that-Erlang-might-be-the-only-object-oriented-language-and-also-his-thesis-supervisor-s-claim-that-Erlang-is-extremely-object-oriented

LVV>>Все прям такие начинающие...
scf>Да все понимают, что твой вброс — джинса для слабых мозгом, чтобы они купили ваш курс по программированию, но чего бы не обсудить
Ну, 1. Написано жеж — для начинающих...
2. А мы ничего не продаем, никаких курсов.

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

LVV>Написано было в ветхозаветные времена: http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
LVV>Перевод: http://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho
Вот тут:

-deftype abstime() = {abstime,year(),month(),day(),hour(),min(),sec()}.

Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system.

There are no associated methods.

Чем это хорошо-то? Т.е. any function in the system создать дату 31 февраля и никак это не запретить.

Здравствуйте, уважаемый LaptevVV, Вы писали:
...
LVV>То и удивительно, что ООП существует с середины 60-х годов.

А разве не с начала/середины 80-х?

Во времена, когда Керниган и Ритчи изобрели UNIX и Си (начало 70-х) — они сделали прорыв в структурном программировании.
Это и было "дальними подступами" к ООП. По настоящему ООП появился на десять лет позже, но UNIX API был прелюдией к нему.

P.S. Я полагаю, уважаемый профессор, что Вы помните всю историю развития ИТ и это — простая опечатка...

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

M>Алсо: https://www.quora.com/What-does-Alan-Kay-think-about-Joe-Armstrong-claiming-that-Erlang-might-be-the-only-object-oriented-language-and-also-his-thesis-supervisor-s-claim-that-Erlang-is-extremely-object-oriented

Оказывается, Джо Армстронг умер.. Очень жаль..

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Не, классический ООП — та еще кака, но аргументы в статье действительно ни в Красную Армию.

Чем классический ООП от неклассисеского отличаетмя? Может канонический(все есть объект), а не классический?

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

AG>>А разве не с начала/середины 80-х?

N>https://en.wikipedia.org/wiki/Simula

Получается что Симула появился раньше, чем Си и C++
и уже имел все признаки ООП.

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

·>Чем это хорошо-то? Т.е. any function in the system создать дату 31 февраля и никак это не запретить.

Класс даты должен бросить исключение до выделения памяти (или вернуть NULL) в таком случае.

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

НС>>Не, классический ООП — та еще кака, но аргументы в статье действительно ни в Красную Армию.
S>Чем классический ООП от неклассисеского отличаетмя?

Например наличием наследования реализаций.

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

AG>>>А разве не с начала/середины 80-х?

N>>https://en.wikipedia.org/wiki/Simula

AG>Получается что Симула появился раньше, чем Си и C++
AG>и уже имел все признаки ООП.

Да, но это чуть другой ООП.

Simula, Smalltalk, или эквиваленты на процессах Erlang это ООП системы "рыбы в аквариуме": объекты — независимые сущности с собственным поведением, со взаимодействием через обмен плоскими сообщениями, которые просто данные. Дешёвые объекты, как в C++, вплоть до class point { int x, y; } — там просто не имеют смысла.

А вот C++, Java, C#, Object Pascal и ещё тысячи их — разделяются объекты как склады данных с контролем доступа, и "источники жизни" в виде ниток исполнения. Объекты пассивны и оживляются только вызовами. По сравнению с ООП-1 это было действительно упрощением и в чём-то профанацией, но дало основной всплеск развития.

Новая волна языков и подходов со всякими async/await, акторами и т.п. — даёт смешение этих двух подходов на новом уровне.

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

AG>·>Чем это хорошо-то? Т.е. any function in the system создать дату 31 февраля и никак это не запретить.

AG>Класс даты должен бросить исключение до выделения памяти (или вернуть NULL) в таком случае.

В теории. А в суровой реальности многие молча создают 2 или 3 марта.

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

AG>·>Чем это хорошо-то? Т.е. any function in the system создать дату 31 февраля и никак это не запретить.
AG>Класс даты должен бросить исключение до выделения памяти (или вернуть NULL) в таком случае.
Какой класс? Класс — это из терминологии ООП. У него там только тип abstime. Где будет код, который будет делать валидацию и кидать исключения в случае "no associated methods"? Как запретить иметь 31 февраля минуя валидацию в условиях что "data structures representing times can be manipulated by any function in the system"?

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>>>Не, классический ООП — та еще кака, но аргументы в статье действительно ни в Красную Армию.
S>>Чем классический ООП от неклассисеского отличаетмя?
НС>Например наличием наследования реализаций.

Разве в классическом это не предусмотрено?

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

S>Разве в классическом это не предусмотрено?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Разве в классическом это не предусмотрено?
НС>Не просто предусмотрено, а один из обязательных признаков. В том то и проблема.

Запутался я немного: C# это классическая реализация ООП или нет(гибридная)? Да, там не все объект.

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

A>Мода совать ООП везде, где не надо прошла уже лет десять назад.

Скорее 20.

A>Сейчас мода на функциональное программирование и шаблоны.

Лет 10 назад прошла

Сейчас в моде динамика, ООП в стиле TypeScript и статический анализ с нетривиальными правилами.

Здравствуйте, Ночной Смотрящий, Вы писали:

A>>Сейчас мода на функциональное программирование и шаблоны.

НС>Лет 10 назад прошла

НС>Сейчас в моде динамика, ООП в стиле TypeScript и статический анализ с нетривиальными правилами.

Все идет по кругу

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

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

N>Simula, Smalltalk, или эквиваленты на процессах Erlang это ООП системы "рыбы в аквариуме": объекты — независимые сущности с собственным поведением, со взаимодействием через обмен плоскими сообщениями, которые просто данные. Дешёвые объекты, как в C++, вплоть до class point { int x, y; } — там просто не имеют смысла.

То есть Simula и Smalltalk — стояли в основах ООП языков...

N>А вот C++, Java, C#, Object Pascal и ещё тысячи их — разделяются объекты как склады данных с контролем доступа, и "источники жизни" в виде ниток исполнения. Объекты пассивны и оживляются только вызовами. По сравнению с ООП-1 это было действительно упрощением и в чём-то профанацией, но дало основной всплеск развития.

Ну предположим, что после вызова конструктора (после "оживления") — также могут жить своей жизнью, порождать потоки и даже процессы.
Хотя, конечно потоки и процессы на уровне языка появились в C++ только в 2011-м.

N>Новая волна языков и подходов со всякими async/await, акторами и т.п. — даёт смешение этих двух подходов на новом уровне.

Но это уже веяния последного десятилетия...

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

AG>>Хотя, конечно потоки и процессы на уровне языка появились в C++ только в 2011-м.
LVV>На уровне языка в С++ они до сих пор не появились.

Ну насчёт процессов — согласен (здесь API операционной системы обычно используют).
Насчёт потоков в С++ — я подразумеваю это:
https://thispointer.com/c-11-multithreading-part-1-three-different-ways-to-create-threads

LVV>А вообще о параллельных процессах в языках — это опять 60-е годы.
LVV>APL, например. Очень нетрадиционный и интересный язык.
LVV>IBM даже для него создала специальную рабочую станцию.
LVV>Были специальные версии параллельных фортранов.

Если технологии того времени базировались на одной (пусть огромной) машине с одним CPU —
то применение параллельности, вероятно, было скорее искуственным (типа распределение таймерных квантов),
чтобы нейкая задача (ну или процесс) не стояли слишком долго в очереди...

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

LVV>Были специальные версии параллельных фортранов.

Параллельность в Фортране появилась где-то в стандарте 95, не? Тут я теоретик, мне на Ф4, Ф77 и Ф90 поработать пришлось малость, а более поздних версий я не видел. Ходят слухи, что в Фортране векторизацию неплохо сделали.

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

A>Мода совать ООП везде, где не надо прошла уже лет десять назад.
а где не нужно совать ООП?

LVV>>Были специальные версии параллельных фортранов.
P>Параллельность в Фортране появилась где-то в стандарте 95, не? Тут я теоретик, мне на Ф4, Ф77 и Ф90 поработать пришлось малость, а более поздних версий я не видел. Ходят слухи, что в Фортране векторизацию неплохо сделали.
Это в стандарте.
А я в нашем Ташкентском институте кибернетики с самыми разными фортранами работал — пару раз попадалось типа para... чего-то там.

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

LVV>А я в нашем Ташкентском институте кибернетики с самыми разными фортранами работал — пару раз попадалось типа para... чего-то там.

Что такое рага? Я действительно только со стандартными Фортранами работал.
P.S. А зато у них переносимость на уровне исходного кода практически идеальная.

LVV>>А я в нашем Ташкентском институте кибернетики с самыми разными фортранами работал — пару раз попадалось типа para... чего-то там.
P>Что такое рага? Я действительно только со стандартными Фортранами работал.
типа parallel construction
P>P.S. А зато у них переносимость на уровне исходного кода практически идеальная.
Это да.

Забыл добавить.
За 60-70-е годы методы параллельности были настолько развиты,
что в языке Ада, созданном по заказу Пентагона, появился НОВЫЙ метод рандеву.
И было это в конце 70-х.
Сообщение о языке переведено и вышло в СССР в 1981 году.

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

P>>Что такое рага? Я действительно только со стандартными Фортранами работал.
LVV>типа parallel construction

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

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

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

N>>Simula, Smalltalk, или эквиваленты на процессах Erlang это ООП системы "рыбы в аквариуме": объекты — независимые сущности с собственным поведением, со взаимодействием через обмен плоскими сообщениями, которые просто данные. Дешёвые объекты, как в C++, вплоть до class point { int x, y; } — там просто не имеют смысла.

AG>То есть Simula и Smalltalk — стояли в основах ООП языков...

Да.

AG>Ну предположим, что после вызова конструктора (после "оживления") — также могут жить своей жизнью, порождать потоки и даже процессы.
AG>Хотя, конечно потоки и процессы на уровне языка появились в C++ только в 2011-м.

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

N>>Новая волна языков и подходов со всякими async/await, акторами и т.п. — даёт смешение этих двух подходов на новом уровне.
AG>Но это уже веяния последного десятилетия...

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

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

LVV>Забыл добавить.
LVV>За 60-70-е годы методы параллельности были настолько развиты,
LVV>что в языке Ада, созданном по заказу Пентагона, появился НОВЫЙ метод рандеву.
LVV>И было это в конце 70-х.
LVV>Сообщение о языке переведено и вышло в СССР в 1981 году.

Рандеву это как раз ужасный метод
вы где-то сейчас его в современной практике встречали? Все на него тупо забили.
Современные реализации CSP, как в Erlang, Go, предполагают очереди (в Erlang — одиночные (фатальный дефект) и безразмерные, в Go — множественные и можно управлять размером...)
И изначально он был каким-то теоретическим выбредком, возникшим из одного тёмного угла теории просто потому, что кому-то показался концептуально осмысленным.
Уже в 80-х практика ушла от него, что и зафиксировано в стандарте 95 — современный код на Ada на рандеву это нонсенс или тяжёлая легаси.

Ну и как в любом направлении — что-то устойчивое появляется только к третьей версии. Третья версия параллельности это сейчас у нас на глазах — кому мьютексы, кому обмен сообщениями, а кому async/await — и можно сочетать все три.