https://www.computerenhance.com/p/the-big-oops-anatomy-of-a-thirty
	https://www.youtube.com/watch?v=wo84LFzx5nI

Смотрел несколько дней назад, уже всего точно не помню, но вот некоторые моменты:

• Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.
  
• В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям). Могли иметь tagged unions (и pattern matching) в C++ с самого начала. А так пришлось ждать до C++17 чтобы появился хотя бы std::variant

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

σ>* В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям). Могли иметь tagged unions (и pattern matching) в C++ с самого начала. А так пришлось ждать до C++17 чтобы появился хотя бы std::variant

Но в Си этого не было, поэтому и в C++ не попали, т.к. C++ базировался на Си.
Потребовалась пара десятилитий набивания шишек с Си-шным union-ом в C++, чтобы прийти к std::variant.

И, что занимательно, в C++ до сих пор есть место для использования чисто Си-ных union-ов, без дополнительной информации о том, что лежит внутри.

По причине совместимости с Си в C++ auto для вывода типов приспособили только в С++11. Хотя Страуструп писал, что у него была эта идея еще для C with classes, но не решился, т.к. в Си у auto было свое предназначение (даже при том, что в C++ auto не имело смысла).

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

σ> Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.

а что плохого в инкапсуляции по мнению автора? И в каких областях она не применима?

σ> В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям). Могли иметь tagged unions (и pattern matching) в C++ с самого начала. А так пришлось ждать до C++17 чтобы появился хотя бы std::variant

теперь подвезли variant и чего? Вроде сильно проще жить не стало. Можно конечно писать что-то типа:

struct Circle { void show() const; };
struct Rect { void show() const; };

using Shape = std::variant<Circle, Rect>;

std::vector<Shape> shapes;
shapes.push_back(Circle{});
shapes.push_back(Rect{});
for(const auto& shape: shapes) {
  std::visit(shape, [](const auto& sh){ sh.show(); });
}

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

σ>>* В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям). Могли иметь tagged unions (и pattern matching) в C++ с самого начала. А так пришлось ждать до C++17 чтобы появился хотя бы std::variant

S>Но в Си этого не было, поэтому и в C++ не попали, т.к. C++ базировался на Си

В Си и наследования с шаблонами не было. Почему это не помешало?

σ>> Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.

SP>а что плохого в инкапсуляции по мнению автора? И в каких областях она не применима?

Говорилось про адекватность, а не применимость.
cons-пары или чистые функции тоже наверное (почти) везде применимы.

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

σ>>>* В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям). Могли иметь tagged unions (и pattern matching) в C++ с самого начала. А так пришлось ждать до C++17 чтобы появился хотя бы std::variant

S>>Но в Си этого не было, поэтому и в C++ не попали, т.к. C++ базировался на Си

σ>В Си и наследования с шаблонами не было. Почему это не помешало?

Потому что теплое с мягким.

Цель создания C++ была в том, чтобы скрестить Симулу с Си. Что выразилось в добавлении в Си классов и наследования.
При этом в Си уже был механизм union, который решал ту же самую проблему, что и tagged unions в других языках. Добавлять в язык в те времена еще что-то, что решает ту же самую проблему... Зачем?

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

Это мы сейчас уже, с позиций послезнания, можем рассуждать о нереализованной возможности.

Что касается pattern matching-а, то на первый взгляд есть серьезное противоречие между ООП-шной инкапсуляцией и возможностью разделить объект на составляющие в рамках pattern matching-а. Если мы, конечно же, хотим иметь нормальный pattern matching, а не ту порнографию, которую нам дали в C++ под видом std::visit.

В той же Scala, емнип, уделили серьезное внимание вопросу скрещивания классов и pattern matching-а, но сама Scala появилась на 20 лет позже C++.

σ>

Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.
Про инкапсуляцию бодался Брукс с Парнасом еще.
Брукс был за полную открытость, а Парнас написал статью, что надо наружу выставлять только интерфейс, а остальное — под капот.
И в юбилейном издании Мифического человека-месяца Брукс написал дополнение: Парнас был прав!

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


σ>В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям).

А это что?

class B : private A  {
    // ...
};

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

σ>Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем.

Инкапсуляцию придумали тысячи лет назад. Тогда это называлось "а вот этого вам знать не стоит".

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

S>Потребовалась пара десятилитий набивания шишек с Си-шным union-ом в C++, чтобы прийти к std::variant.

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

S>По причине совместимости с Си в C++ auto для вывода типов приспособили только в С++11.

В этом нет вообще ничего, связанного с совместимостью с C.

S>Хотя Страуструп писал, что у него была эта идея еще для C with classes, но не решился, т.к. в Си у auto было свое предназначение (даже при том, что в C++ auto не имело смысла).

Ничто не мешало ввести другое ключевое слово — сразу и в "голом" виде, и с подчеркиванием, для тех программ, которые используют его в качестве идентификатора.

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

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

S>Цель создания C++ была в том, чтобы скрестить Симулу с Си.

Цель была прежде всего в том, чтобы раздвинуть возможности C в сторону ЯВУ, не теряя при этом его низкоуровневых качеств. Чтоб на одном языке можно было писать и начальный загрузчик, и ядро, и системные надстройки, и прикладные программы. И в этом направлении в C++ как было, так и до сих пор остается неслабый простор для развития.

S>Шаблоны тоже изначально не в планах были. К ним чуть позже пришли, когда выяснилось, что обобщенное программирование на Си-шных макросах -- ну такое себе удовольствием.
S>Это мы сейчас уже, с позиций послезнания, можем рассуждать о нереализованной возможности.

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

S>Что касается pattern matching-а, то на первый взгляд есть серьезное противоречие между ООП-шной инкапсуляцией и возможностью разделить объект на составляющие в рамках pattern matching-а.

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

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

LVV>Брукс был за полную открытость, а Парнас написал статью, что надо наружу выставлять только интерфейс, а остальное — под капот.

А победили те, кто сообразил указывать это явно, вроде public/private/protected.

LVV>>Брукс был за полную открытость, а Парнас написал статью, что надо наружу выставлять только интерфейс, а остальное — под капот.
ЕМ>А победили те, кто сообразил указывать это явно, вроде public/private/protected.
Это очевидно же.
Управляемая инкапсуляция всяко лучше неуправляемой.
Я студентам рассказываю, что с инкапсуляцией мы дело уже имели — локальные переменные в функции.
А в классах имеем управляемую — это гораздо лучше!

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

LVV>Управляемая инкапсуляция всяко лучше неуправляемой.

Это Вы скажите тем, кто старается как можно больше вещей наглухо забетонировать, а не сделать разборными/управляемыми.

Здравствуйте, Евгений Музыченко, Вы писали:

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

Тут надо вспомнить известную поговорку: "Есть два типа языков: те, которые все ругают и те, которыми не пользуются."
Как бы хороших, правильных, идеологически стройных языков много, их делали и делают, в чём проблема-то использовать практичный и подходящий? Был бы шанс у С++, если бы его делали по-другому? Вообще, можно ли определить, как пойдёт развитие того или иного языка/проекта на этапе его создания?
Гнать сейчас на Страуструпа, что он где-то облажался просто глупо. Потому что то, что он сделал уже очень круто. Он не специалист по ЯП в широком смысле слова. Сколько языков создавали специалисты, учёные, университетские лаборатории. Где они? Где язык Ада? Где все эти стройные, хорошие и продуманные штуки? Рулят языки, которые создавались практичными людьми для себя: Питон, JS, С, С++.
У Страуструпа была своя работа, он перед языком ставил вполне нормальные и практичные вопросы. Даже в том виде, в котором С++ изначально вышел, он вызывал много срача между С vs С++. Не у всех хватило бы сил и мужества поддерживать и развивать то, что есть в условиях не самой дружественной атмосферы.
В этом плане история Линукса, также написанного не профессионалом, более лайтовая, Линукс приняли лучше и теплее. И то много проблем было на старте.

Здравствуйте, Евгений Музыченко, Вы писали:

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

Бла-бла-бла. Много языков программирования сделали, авторитетный вы наш?

S>>По причине совместимости с Си в C++ auto для вывода типов приспособили только в С++11.

ЕМ>В этом нет вообще ничего, связанного с совместимостью с C.

Сказал хз кто. А вот что говорит сам Страуструп (Evolving a language in and for the real world: C++ 1991-2006, стр.46):

auto q = find(vi.begin(),vi.end(),7); // ok

Here, we deduce the type of q to be the return type of the value returned by find, which in turn is the type of vi.begin(); that is, vector<int>::iterator. I first implemented that use of auto in 1982, but was forced to back it out of “C with Classes” because of a C compatibility problem. In K&R C [76] (and later in C89 and ARM C++), we can omit the type in a declaration. For example:

static x; // means static int x
auto y; // means stack allocated int y

S>>Хотя Страуструп писал, что у него была эта идея еще для C with classes, но не решился, т.к. в Си у auto было свое предназначение (даже при том, что в C++ auto не имело смысла).

ЕМ>Ничто не мешало ввести другое ключевое слово — сразу и в "голом" виде, и с подчеркиванием, для тех программ, которые используют его в качестве идентификатора.

Бла-бла-бла.

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

Бла-бла-бла.

Здравствуйте, Евгений Музыченко, Вы писали:

S>>Цель создания C++ была в том, чтобы скрестить Симулу с Си.

ЕМ>Цель была прежде всего в том, чтобы раздвинуть возможности C в сторону ЯВУ

В 1980-х Си уже был ЯВУ. Конкретно же сам Страуструп говорил: "С++ проектировался с целью обеспечить средства организации программ, присущие языку Simula, а так же необходимую для системного программирования эффективность и гибкость, свойственные языку Си"

Это прям первый параграф введения в книге "Дизайн и эволюция языка C++".

S>>Шаблоны тоже изначально не в планах были. К ним чуть позже пришли, когда выяснилось, что обобщенное программирование на Си-шных макросах -- ну такое себе удовольствием.
S>>Это мы сейчас уже, с позиций послезнания, можем рассуждать о нереализованной возможности.

ЕМ>Уже много раз было подчеркнуто, что к тому времени было известно достаточно много способов обобщенного программирования

Ada и Clu (и ML, емнип) упомининались Страуструпом как первоисточники. При этом Страуструп негативно отзывался о реализации обобщенного программирования в Ada:

Мы написали много макросов в стиле шаблонов, чтобы понять, какие языковые средства необходимы для поддержки данного стиля программирования. Размышляя над шаблонами, я не отводил главное место языку Ada, который лишь вызывал у меня раздражение своими операторами инстанциирования шаблонов.

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

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

ЕМ>Но форма была выбрана достаточно искусственно — такое впечатление, что кому-то она просто очень сильно понравилась, и ее продавили чисто на эмоциях.

Расскажете как сделать лучше?

S>>Что касается pattern matching-а, то на первый взгляд есть серьезное противоречие между ООП-шной инкапсуляцией и возможностью разделить объект на составляющие в рамках pattern matching-а.

ЕМ>Так это ж все можно легко регулировать.

Правда? Да что вы говорите!!!

Вы хоть знаете как в C++ сделать адаптацию своего типа к structured binding?

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

N>Был бы шанс у С++, если бы его делали по-другому?

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

N>Гнать сейчас на Страуструпа, что он где-то облажался просто глупо.

Почему нельзя гнать на него за то, что всю историю отчаянно сопротивлялся добавлению новых ключевых слов, упорно навешивая новые семантики на существующие, вплоть до абсурда?

N>Он не специалист по ЯП в широком смысле слова.

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

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

ЕМ>>В этом нет вообще ничего, связанного с совместимостью с C.
S>А вот что говорит сам Страуструп (Evolving a language in and for the real world: C++ 1991-2006, стр.46):

Так кто ж его заставлял использовать "auto" в исходном виде? Если уж отчаянно не хотелось вводить что-нибудь вроде "deduced" или "autotype", ничто не мешало сперва ввести "_auto", с последующей постепенной подгонкой "auto" к тому же смыслу.

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

S>В 1980-х Си уже был ЯВУ.

Он был очень примитивен по сравнению с "серьезными" ЯВУ того времени. Сложность написания и поддержки крупных/сложных проектов на C росла лавинообразно.

S>сам Страуструп говорил: "С++ проектировался с целью обеспечить средства организации программ, присущие языку Simula

Да, но не потому, что у языка Simila было такое название, а потому, что он для тех времен был достаточно продвинутым.

S>а так же необходимую для системного программирования эффективность и гибкость, свойственные языку Си"

В этом и заключалась уникальность подхода — не использовать стиль C для создания совершенно нового языка, как это делалось неоднократно, а расширить C в сторону "взрослых" ЯВУ, не потеряв при этом компактности и эффективности простого кода.

S>Ada и Clu (и ML, емнип) упомининались Страуструпом как первоисточники.

Возможных для заимствования первоисточников были десятки. Кто ж виноват, что он зациклился на Ada и его особенностях?

S>Ну уж гибче, чем в C++, еще поискать нужно.

Ну, если сравнивать только подходы, похожие на C++, то конечно.

S>Огласите свой список языков без сборщика мусора, в которых шаблоны гибче, чем в C++?

Какая вообще связь у шаблонов со сборкой мусора, кроме весьма отдаленной?

S>А то, что шаблоны не просты, так это как раз следствие их гибкости.

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

ЕМ>>форма была выбрана достаточно искусственно

S>Расскажете как сделать лучше?

Я уже много раз рассказывал. Главное — не пытаться запихать всю потребную функциональность в искусственно ограниченные синтаксис и семантику.

S>Вы хоть знаете как в C++ сделать адаптацию своего типа к structured binding?

Представляю в общих чертах, ибо пока не требовалось настолько, чтоб в этом разбираться досконально.

Кстати, подобные вещи легко делались бы на "функционально адекватных" макросах, имейся таковые в языке. И не было бы нужды впихивать это в сам язык, и каждый мог бы хоть использовать готовые конструкции из библиотек, хоть делать сам на собственный вкус и потребность. А так и язык в очередной раз усложнили/утяжелили, и способы управления связыванием зафиксировали, без возможности их изменения/дополнения.