Нічого складного, якщо не лізти в дійсно складні области. Але так зі всім.
Головне, для чого потрібне ООП, це розділення надскладного на таке складне, щоб людина смогла усвідомити, а далі зручно розвивати код. І з цею задачею воно справляється.

В Microsoft C — є. За рахунок SEH як розширення, яке на рівні компілятора підтримано відповідними словами (`__try` і так далі).
І повторюсь, що я б хотів таке бачити всюду, починаючи з Linux, воно в рази зручніше, ніж морочитись з обробниками сигналів і сподіваючись, що longjmp нічого не зламає.

Саме тому в ядрі Linux немає жодного натяку на ООП. ;)

І довго цей міф буде розповсюджуватись?
Обʼєкти — є. Наслідування інтерфейсів реалізаціями — є. Віртуальні функції — є. Вже достатньо.
Нема наслідування реалізації і обмежень видимости при інкапсуляції. Ну так і без них нормальне ООП.
Ви спробуйте якось заглянути в сорці...

— Маэстро, какие ваши творческие планы?
— Ну, я положил на музыку...
— В самом деле? Жаль, очень жаль...

как «переход на линух» сделает пользователя «более независимім»?

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

Я могу сам исправить. Я могу купить подпиливание. Я могу попросить друга. Все варианты.

А миф про то, что я буду всё настраивать, устарел лет на 20. В современной системе на линуксе настройки требует дай бог чтобы 1%, и получается неплохо. Винда же в большинстве случаев просто не даёт сделать, как надо, а лечить её требуется в разы больше квалификация (и опять же боязнь нарушить что-то юридическое).

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

Прочитайте Спольского. У нього найточніший опис, а не міфи про «купку ентузіастів»:

>> Smart companies try to commoditize their products’ complements.

і все далі як розвиток цеї ідеї.

Щодо UI, він дуже різний. Але особисто мене KDEшний влаштовує значно краще, ніж віндове жахіття. І це тільки порівняння самого DE, а ще є питання, які лежать під ним.

То есть таки совместимости не положено? Я вот помню, что был такой IE6.

до тех пор, пока не умр’т последний юзер, которій помнит зачем єто надо.

Мне бояться, что Наделла придёт убивать?

То-то в этом фирменном стиле давно умерли MS-DOS приложения, хотя у них продолжало быть более чем одного последнего юзера... Или вот я как-то купил на Петровке диск с кучей старых версий винды, так вот косынка и эксплорер от 2.0 на 7-ке крэшились при попытке запуска. Это даже родные приложения, а что говорить о чужих...

Вот кто реально тащит обратную совместимость — это IBM. Ты можеш на SystemZ последней версии с AI сопроцессорами запустить софт 1964-го года от DOS/360, да так, что он вообще не заметит, что обстановка неродная. Причём для несистемного софта вообще ничего особого не нужно, а для системного достаточно BC виртуалки (дешёвый тип). Или на iSeries можно запустить приложение в IL коде от первых версий AS/400, тоже будут работать. Вот это — реальная обратная совместимость.
А у MS — хилый закос...

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

Про усіх не треба, але на загал — так проблема ООП в тому, що це дуже складна парадигма з порогом входження, яка вимагає професійних знань практики і наснаги.

В чому саме цей порог?

Щодо процедурного програмування — згоден, сама ідея з’явилася раніше. Мова C лише зробила її більш практичною та зручною для масового використання.

Таки не так. З мовою поширилось програмування в цілому. А в тих межах, в яких воно було раніше, до епохи, умовно, персональних компʼютерів класса від 386 и 1MB оперативки, те ж саме досягалось іншими мовами. Мови загального призначення і не лялькової без процедур не існувало, навіть в крихітному бейсіку з ПЗУ був gosub.

Сі тут має цікаву історію тому, що спочатку «на коні» Unix вʼїхав в світ серйозної розробки, а потім з IBM PC став відомим ширнармассам, в довгій боротьбі таки перемогши Pascal, фактично, за рахунок немочі найбільшої фірми, що його просувала. Якби не це, вся історія склалась би інакше.

GOTO ніхто й сьогодні не забороняє, але його застосування — радше ознака поганого стилю, ніж інженерної необхідності.

Є вимоги, коли goto неминучий. Але задля тої ж верифікації його обмежують. Навіть просте правило «goto тільки вперед по коду» усуває >90% проблем від його використання, і саме таке правило присутнє в стандартах типу MISRA. (90% решти усуває правило не стрибати в тіло циклу.) Але ці правила виробили пізніше того, про що писав Дейкстра, і, головне, той факт, що у переважній більшости випадків можна його замінити розгалуженнями, циклами і раннім return — рятує вже читача. А коли він всеж таки залишається — значить, реально був потрібний.

де головний акцент — на наслідуванні як інструменті повторного використання коду.

Ну ось тут проблема. У Go, Rust, деяких інших таке явно не дозволене чи має суттєві обмеження. Але казати, що з ними не можна ООП — це перебільшення.

Для мене ООП у першу чергу це подумкове встановлення сутностей (не обовʼязково з домену) і границь між ними, оформлення відповідальности (що дає інкапсуляцію) і взаємодії (інтерфейси, контракти і фінально LSP), а буде там наслідування чи ні — це вже друге (або третє, якщо вторим вирішити, чи мають обʼєкти бути активними).

Щодо Go — повністю погоджуюсь: відсутність наслідування справді призводить до дублювання логіки.

Ось :)

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

Є таке (згадаємо той же Паскаль).

Достатньо згадати, що компанія Sun Microsystems витратила близько 500 мільйонів доларів на просування Java у перші роки її існування.

І вони зробили її ;)

Загалом, стаття не про процедури чи класи, скільки про те, що, навчившись мислити по-різному й розуміти різні варіанти розв’язання задач, розробник отримує змогу вибирати найбільш оптимальний підхід у конкретній ситуації, незалежно від мови програмування.

Угу. Ну, тут треба дещо більше конкретики, це статей пʼять:)

В английском перед объектом предлог The, перед классом a.

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

К не объектным языкам относятся языки индейцев.

Языки индейцев очень разные. Но то, что вы говорите, это скорее всего инкорпорирующие языки, в которых в одном предложении могут смешиваться части разных слов.
При этом там всё равно стандартная тройка subject, verb, object в каком-то выбранном порядке из множества возможных, только их обозначить бывает сложновато.
И не надо идти за океан, французский можно с хорошим основанием признать таким же инкорпорирующим.

Ещё вы могли прочитать про строй языка (в английском alignment). И тоже незачем гоняться за индейцами, ранний общеиндоевропейский был языком активного строя (active-stative alignment), наследие этого до сих пор можно разглядеть в некоторых фичах языков. Но в любом строе есть формы для агента, пациента, презента и прочих компонентов высказывания, только группируются они по-разному и с разными ограничениями.

так, goto зазвичай легко розкручуються та замінюються в коді використанням інших конструкцій

Не завжди. І не завжди його треба виключати.

що не скажеш те саме відносно longjmp який іноді використовують — чим у такому випадку пропонуєте його обходити конструктивно в сі?

Ось саме тут в юніксах я сумую по SEH. Воно дійсно геніальна ідея, і нормально було б перекласти на нього всю обробку помилок, і мовні засоби обробки винятків теж робити через нього.

Саме тому до сих пір ООП-шники шукають свій святий грааль та срібну кулю.

Хто шукає? Всі хто хотів реально — давно знайшли.

Перші йшли шляхом «спрощення», тобто бачу стіл — створюю клас, бачу килимок — створюю клас. Стіл можна ставити на килимок? Ось метод та стан.

Виглядає нормально для простої гри. Що не так?

Другі намагалися передбачити хоча б трохи майбутні задачі та зміни, та займалися улюбленим оверінженірінгом.

Тоді справа в оверінжинірингу, а не в ООП. Overengineering можна зробити на чому завгодно і без ООП, і взагалі без компʼютерів.

Спільне між двома підходами було одне. ООП. ;)

Без якого не впорались би створити навіть таке, все б розвалилось під складністю задачі ще на далекій відстані.

І краще було б і не згадувати;\
Майже єдиний варіант Prolog, що вижив, зветься make. Інші опинились не потрібні. Де їх пробували вводити (наприклад, оцінки комітів в Gerrit), реакція 90+% користувачів була «викиньте каку і дайте щось процедурне».

З точки зору теорії, я згоден, воно цікаво — дає деяке логічне замкнення. Але йому краще б там і залишатись.

вони ж закладеня на значно більш базовому рівні і є загальними

Настільки загальними, що про них забувають, і якщо реалізація раніше такого не давала — приход такого винятка як дитячі граблі. Я про це.

В інтерфейсах та протоколах ти просто реалізуєш всі умови, і все.

Ніт. Ось наприклад є базовий SMTP, в ньому набір команд. А ось ESMTP, в ньому декілька нових. А ось є ще розширення, які описує початкове узгодження з ESMTP, типу прямої передачі у 8 бітах замість вимоги перекодування в QP або base64, або відправки по частинах.
Критична умова роботи ESMTP — що весь базовий SMTP, якщо з ним приходять, підтримується і саме так, як сказано згідно його стандарту. І це теж є LSP. Тільки замість класів у тебе сервер, з яким обмінюєшься порціями байтів, а замість того, хто використовує той клас — клієнт, що відкрив зʼєднання по TCP.

Нее, интуиция — она в собственной кардашьян, а не в чужой.

А коли за тебе вирішують гормони, тобі слова не дають:)
У мене було, що саме за очі «зачіпився». Може, і за інше, але підсвідомість якось не звикла давати дежурні звіти:)