О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

Если в коде нет ООП, то вы пишите одноразовый код, который затем нужно выкинуть. Например, в Go так и происходит. Из наиболее известных случаев это переписывание клиента/ноды для ethereum.

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

Вот водка — популярна тема. А самоучителей как пить водку нема. Неувязочка

Ты бы еще онанизм вспомнил. Если бы в программировании нужно было только дергать или лить в горло, то программистов бы сейчас было половина мира. Но почему-то у нас хаскелисты после застолья не рождаются — потому что программирование само по себе непросто, независимо от инструмента. У нас вон люди, которые умеют электронные таблички делать в экселе — и те уже называются «программисты», потому что, блин, сложно. А если башпортянку сможешь хотя бы прочитать — ты уже «хакер». А ты говоришь «книжки по ООП». Это вообще в их глазах «архитектор всех программ и компьютеров».

самоучителей как пить водку нема. Неувязочка.

есть (устные)–> «наливай да пей»

и главное, даже если найдётся гений чудик, умеющий расписать эту концепцию на страниц 300..500 читать его никто не станет – практика сильней теории

Но почему-то у нас хаскелисты после застолья не рождаются

Не знаю кто такой Хаскель, но тренеров сбороной страны по футболу после застолья - чуть меньше, чем пьющее население страны.

Наша любимая компания открыла доступ к комплекту для разработки игр

Налетай!

https://habr.com/ru/news/t/569418/ Microsoft открыла доступ к комплекту для разработки игр

https://github.com/microsoft/gdk Microsoft Public GDK

Наша любимая компания открыла доступ к комплекту для разработки игр

Я надеюсь там все как надо, модульный, но с элементами ООП?

Не согласен. ООП - это раковая опухоль, которая раздувает такие проекты как Qt, Unreal Engine, Godot и многие другие до безобразный размеров (bloatware), с которыми мне приходилось сталкиваться. По возможности, стараюсь бежать от них как от огня.

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

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

Я надеюсь там все как надо, модульный, но с элементами ООП?

Этот тред не понятно о чем …
Без объектов и кода

И не туды и не сюды

Если речь о ООП С++ class …, то это лишь частный случай средненькой архитектуры …

Если речь о ООП С++ class …, то это лишь частный случай средненькой архитектуры …

Ныне вариаций ООП много.
Неплохо бы обсудить …

https://habr.com/ru/news/t/569418/ Microsoft открыла доступ к комплекту для разработки игр https://github.com/microsoft/gdk Microsoft Public GDK

Все как обычно …
Инсталлировать можно на Windows 10.
Посмотрим, что игроделы скажут …

надеюсь там все как надо, модульный, но с элементами ООП?

Установить и не могу /не использую Window 10 /.
Вот пример исходника

/// <summary>
/// Contains information about the results of a string verification.
/// </summary>
class verify_string_result
{
public:
    /// <summary>
    /// The result code for the string verification.
    /// </summary>
    inline verify_string_result_code result_code() const;

    /// <summary>
    /// first_offending_substring() contains the first offending substring if the
    /// result code is verify_string_result_code::offensive.
    /// </summary>
    inline const string_t& first_offending_substring() const;

    /// <summary>
    /// Internal function
    /// </summary>
    inline verify_string_result();

    /// <summary>
    /// Internal function
    /// </summary>
    inline verify_string_result(
        XblVerifyStringResultCode resultCode,
        const char* firstOffendingSubstring
    );

private:
    verify_string_result_code m_resultCode;
    string_t m_first_offending_substring;
};

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

OS/360 ? До миллиардов строк Google ей, конечно, далеко, но, несомненно, система – bloatware своего времени. По реализованным возможностям, а не лишнему коду.

Не только ООП, но даже структурного программирования в ней толком не было, хотя идеи в 1960-е уже были известны, и пользователям предлагались языковые процессоры Algol и PL/I в дополнение к традиционным RPG, COBOL и FORTRAN.

Хорошо, какие в 2021 году есть причины не использовать ООП в проектах масштаба Qt, Unreal Engine и т.д.? Есть ли современные подобные проекты, где намеренно отказались от ООП и преуспели?

Короче, автор - очередной метапрог. Как обычно критиками выступают не опытные специалисты, а недоучки, которые не разобрались в существующем, но уже знают, как сделать всем лучше (нет).

ООП или ОП? Второе - никаких, первое - редко когда нужно, да и от масштабов здесь ничего не зависит.

ООП или ОП? Второе - никаких, первое - редко когда нужно, да и от масштабов здесь ничего не зависит.

Пиши отличия ООП от ОП, раз ты их разделяешь.

Короче, автор - очередной метапрог.

Мы ничего не знаем о ТС и он мало что в этом треде сказал.
Поэтому трудно что-либо сказать о нем …
Что касаемо ООП, то его часто используют там где он и не нужен.
Может быть ТС это хотел сказать?

В целом struct уже является кирпичиком для создания объектов …

ОП = ООП - наследование(и последующая работа через базовый тип). Не помню, где встречал такое, поэтому источник не укажу. Но думаю, достаточно ясно.

~500 постов, самое время выяснить что же хотел сказать ТС.

Не использую class, template, STL, …
Потому, что использование их в run-time весьма проблематично.
Вместо этого используются метаданные.
Они содержат все то, что можно было бы как-то получить при использовании class, template, STL, …
Но еще раз акцентирую на то, что использование их весьма проблематично для run-time.
Можно было бы, но тогда потребуется использование компилятора, …
У меня свой API, который позволяет в run-time работать с объектами, о которых компилятор ни чего не знает.

Вот поэтому, то для разработки OLE class, template, STL, … не использую.
Это к тому сказал, что не являюсь противником ООП.
Он у меня есть, но он пригоден как для compil-time, так и run-time.

~500 постов, самое время выяснить что же хотел сказать ТС.

Эээээээ, причем здесь ТС?

ТС лишь повод к 500 постам

Есть ли современные подобные проекты, где намеренно отказались от ООП и преуспели?

Посмотрите ради интереса исходники Firebird-4.0.0.2496-0.tar.xz в директории Firebird-4.0.0.2496-0\src\common\classes.
ИМХО пример хорошего использования class.
Многие просто

не умеют и не понимают

Продолжим. Тема 3. Инкапсуляция. Тема будет состоять из двух вопросов.

1. В сишных библиотеках часто оперируют указателем на мега-структуру в куче, который часто называют хэндлом. Подразумевается, что работать с этим хэндлом надо через специальное API, в том числе создавать и удалять мега-структуру. Но наверняка есть чудаки, которые правят эту структуру не через API, а напрямую. Знает ли кто-нибудь эпичные истории, когда какой-нибудь профессиональный программист занимался подобным чудачеством и это приводило к краху проекта?

2. В Питоне есть квази-инкапсуляция полей через подчёркивание (по крайней мере так было во второй версии). При этом доступ к полям остаётся. Знает ли кто-нибудь эпичные истории, когда какой-нибудь профессиональный программист занимался правкой этих полей напрямую и это приводило к краху проекта?

этих полей напрямую и это приводило к краху проекта

Что понимать под крахом проекта? Это приводит к тому, что при обновлении библиотеки или соседнего модуля внезапно перестаёт работать ранее оттестированная программа. Это крах проекта?

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

На Питоне было вообще классно:

Python2: print «The answer is», 2*2

Python3: print(«The answer is», 2*2)

Ну да, поломали abi. Там множество способов, включая опции компилятора. Я только не понимаю, к чему у товарища выше столько пафоса.

Я только не понимаю, к чему у товарища выше столько пафоса.

Могу предположить, что он хотел сказать, что инкапсуляция не нужна.

Вопрос в другом.

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

Это теоретическая ситуация, когда мы действуем некорректно. Мой вопрос был в том, известны ли случаи, чтобы какой-то серьёзный программист действовал некорректно, то есть не в соответствии с документацией на библиотеку? Вот мы оградили доступ к внутренностям класса в C++, а имело ли это исторические предпосылки?

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

Ну тут тоже не должно быть проблем в случае с хендлом на структуру, которую пользователь должен использовать только через API. Или тут есть какое-то различие с this класса в C++?

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

Могу предположить, что он хотел сказать, что инкапсуляция не нужна.

Инкапсуляция нужна. Хочется понять, достаточно ли инкапсуляции на уровне модулей и документации. То есть на уровне модулей прячем вспомогательные функции и константы. На уровне документации говорим, что вот эта главная структура доступна только через API. А поля структур-параметров остаются полностью открытыми. Достаточно ли этого? Или обязательно все поля заинкапсулировать?

Все ли реализации Smalltalk’ов лишают программиста прямого доступа к инкапсулированным полям? Или некоторые надеются на дисциплинированность программиста?

Я не знаю ответ на этот вопрос, но википедия пишет, что в Smalltalk-е так же, как и в Python-е. То есть надеются на дисциплинированность программиста. А что из этого следует?

Самая ирония в том что в Си идеальная инкапсуляция на уровне файла: используешь ключевое слово static и передаёшь указатель на объект через void*. И всё!

А «ООП-шном» С++, весь приватный срам класса нараспашку в файле заголовка!

А в смоллтоках private – это комментарий, поясняющий программисту, как правильно использовать внутренности объекта.

Самая ирония в том что в Си идеальная инкапсуляция на уровне файла: используешь ключевое слово static и передаёшь указатель на объект через void*.

Да, идея понятна. Это хорошо, но идеально было бы не void*, а некий защищённый явный тип, поля которого полностью открыты внутри модуля и полностью закрыты снаружи. Иначе могут же какую-нибудь левую структуру подсунуть. И тут через typedef не выкрутиться - надо на уровне синтаксиса языка менять.

Сейчас мы опять к какому-нибудь ОКамлу придём или даже Расту.

Да, но в Си++ если даже меняется внутренняя часть класса, все клиентские программы надо перекомпилировать с обновлённым файлом заголовка. Это такой гемор, особенно когда обновляешь библиотеки, а программы слинкованы со старой версией.

По мне так лучше как в Си… Ну или хотя бы интерфейсы библиотек делать в ситле Си. Там тебе библиотека выдала указатель на свой объект, а ты уж сам следи чтобы он у тебя не перепутался. По мне так это куда лучше сохраняет совместимость интерфейса с новыми версиями библиотеки!

Вот водка — популярна тема. А самоучителей как пить водку нема. Неувязочка.

ISBN 5-902617-18-9

А и верно. Онанизм популярнее ООП, а вала обучающей литературы нет. Вот что значит настоящая интуитивность.

А ты говоришь «книжки по ООП».

Так это не я утверждаю, что ООП самоочевидно, интуитивно понятно и т.п.

Онанизм популярнее ООП, а вала обучающей литературы нет

Есть обучающий материал с наглядной демонстрацией в более удобном формате.

Онанизм популярнее ООП, а вала обучающей литературы нет

Есть обучающий материал с наглядной демонстрацией в более удобном формате.

И что, в университетах уже заставляют использовать?

Что значит «заставляют использовать»? А что в университетах вообще «заставляют использовать»? Там учат. Не нравится — можете не учиться.

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

«Наливай да пей» это инструкция для алкоголиков, такое мне не интересно.

Жопа есть, а слова нет?

Так это не я утверждаю, что ООП самоочевидно, интуитивно понятно и т.п

Да, ты говоришь, что программирование — это сложно и понятно, и этому нужно учиться. Я могу еще космические ракеты вспомнить — там вообще интуитивной ясности выше крыши.

Мой любимый вопрос к тем, кто думает, что программирование интуитивно понятно: «Как ты пишешь программы?».

После нескольких интуитивно понятных, но неправильных, попыток на него ответить, меня готовы бить ногами, но здоровья на это не хватит. Программист — зверек хилый.

а я специально стал листать в надежде его увидеть:) но я по-моему так и не осилил старые треды, где было много всего=)

по сабжу:

меня это заявление даже радует, т.к. я не осили ООП (прикрываясь тем, что я админ)=)

а я специально стал листать в надежде его увидеть:)

Он пишет на Си :)

Программист — зверек хилый

Всякие попадаются.

Всякие попадаются.

Те, кто в спортзале проводит больше, чем за компом в свободное время, до такого «теста на интуицию» просто не дойдут. Тестостерон не способствует.

у нас тут ведьмак бегает. я периодически с его тестостероном на форуме сталкиваюсь. все у него с ним в порядке=)

p.s.

а ты крепко подумал с 2001 года и перешел из ro в rw на лоре?:)