Почему боятся ООП?

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

До структурного программирования додумались не сразу, но как догадались, оно пришло навсегда и заменило собой предшественников тотально. Как позиционная система счисления. Напротив, ООП подобно римским цифрам. На примитивном уровне I + I == II, V + II == VII выглядит просто и понятно, но дальше мрак.

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

забавно ровно то что ООП в идеале хороша в распределённых системах со всякими голосующими византийцами - это называется теперь не ООП а теория акторов Хьюита

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

вот такой салат слов

И объяснить им ничего нельзя, потому как лисп для них с прологом — какая-то ****** беспонтовая

Не надо объяснять. Надо доказать на деле. Вот появился Питон и в очень короткое время отгрыз себе куски сразу из нескольких ниш. Появился C# - та же история. Кучу ПО на них написали. А появились Раст и Го - выхлоп околонулевой, как ни пиарили. Лисп с Прологом и Хаскелем так не пиарят, конечно. Но ПО то на них почти не создаётся никакое. Нет его. Почему-то даже F# не взлетает, хотя у него довольно приятный синтаксис и уважаемая корпорация его продвигала долгое время, «батарейками» обеспечивала.

Не надо объяснять. Просто пишите ПО. Где ваши Гимпы, где Линуксы?

F# … приятный синтаксис

Ещё один рептилоид спалился. [<jjbb>] asd {| afhg |} fuu |> |> |>?

До структурного программирования додумались не сразу, но как догадались, оно пришло навсегда и заменило собой предшественников тотально.

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

ну и граблей немало, куда ж без них

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

Ни слова больше — we have you covered! Продвинутая методология ООП позволит вам разосрать ваше изменяемое состояние на тысячу маленьких кусочков, спрятанных за уникальными интерфейсами (тренирует вашу память!) и выстроенных в строгую иерархию со встроенным эффектом домино!

Если вы думаете, что хранить состояние в глобальных переменных — занятие для сильных духом, просто попробуйте ООП! Вы удивитесь, насколько это увлекательное занятие — попробовать выстроить из этих тысяч независимых и уникальных кусочков идеально согласованное и чётко работающее целое! Только представьте себе, сколько разных сочетаний несочетаемого, граничных случаев и сумеречных зон вам предстоит исследовать (собственным лбом)! Вам понравится, или деньги вперёд!

Вы абсолютизируете свой ограниченный опыт. Вот, например, вокруг меня Go процветает, а C# … даже не назову сходу хоть что-нибудь на нём написанное.

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

Вот, например, вокруг меня Go процветает, а C#

То есть на счёт ненужности ФП возражений нет? :)

Да, возможно, на счёт Go я погорячился. Вакансии есть и на TIOBE он в десятке (C# в пятёрке). Но вакансии в стиле: есть легаси код на PHP, давайте его перепишем на Go. То есть перепишем с одного DSL для узкой ниши на другой DSL для узкой ниши.

В отличие от Go, PHP, JS и других подобных C# является языком общего назначения. Он хорошо себя чувствует и в нише Go, и в разработке GUI-приложений, и в разработке игр. Наверное и на Go можно пытаться писать GUI и игры, но это будет неудобно.

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

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

С пулями всегда так. Появилось что-то новое про которое читают только «чем оно лучше, чем старое» и понеслась волна. Т.е. на грабли ещё не наступили, хоть поверхностно не проанализировали, но оно точно лучше «потому что...».

А вот людей, которые кроме ООП ничего не знают и не хотят — пруд пруди.

Есть такое.

Говорю же, вы абсолютизируете свой опыт и узко смотрите на вещи.

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

Существенная часть того, что происходит в K8S → это изобретение DSL для создания побочных эффектов (объектов кубернетеса). Только вместо нормального инструмента (иже рекомого лиспом) используют YAML, но об этом говнище я даже говорить не хочу, тем более в выходные.

что вечно, что модно, что реально полезно, а что едет на паравозе хайпа

На паровозе едут как раз хейтеры ООП, которое существует вечно относительно их недоязычков и не сдает позиций.

ООП это фрактал плохо"ХО" php - да

и как у всякой успешной религии именно несовершенство сего фрактала и тягу даёт неофитам

т/е сумма проверенных но ещё не ставших массовыми(поэтому частью аудитории(публики) воспринимаемое как откровение) + ни в какие ворота индивидуальные особенности - вот рецепт успеха среди лапотных

дело совсем не в о/о/п дело в широкой базе и ея уровне чудестном

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

С какого фланга атакуешь? С ФП? Так это ж прекрасный спич для рекламы хаскеля. Даже порядок вычислений непредсказуем, «просто» собираешь пазл из тысяч функций, заметаешь под коврик состояние и молишься, что вся эта халабуда сама как-то вычислится правильно и даже сделает что-то практичнее расчета чисел фибоначчи.

«просто» собираешь пазл из тысяч функций

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

Композиция изменяемого состояния — совсем другое дело %) Тут уже, хочешь не хочешь, придётся иметь дело с динамикой (зависимостью состояния от времени).

заметаешь под коврик состояние

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

Композиция функций без состояния — это действительно проще некуда. Проще только композиция (иммутабельных) данных

Ну, нет, наоборот всё же. IT развивается по принципу «общее изменяемое состояние (С)» → «иерархия локальных изменяемых состояний (Java)» → «иерархия неизменяемых состояний (Clojure)» → «отсутствие состояния (FP)».

вы абсолютизируете свой опыт и узко смотрите на вещи

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

в K8S …вместо нормального инструмента (иже рекомого лиспом) используют YAML

Так напишите сбой K8S на лиспе и с использованием лиспа. Макаки из недокорпораций на недостойных недоязычках смогли же. Значит и у Д’Артаньяна с правильным супер языком всё получится. Задача на вечер.

Он может быть вступлением к чему-то большему.

Извините, лень. Вы дичайше заблуждаетесь насчёт Go, по которому просто тонны информации, все интернеты забиты. А раз так, то в более тонкие материи и вовсе бессмысленно лезть.

Вы дичайше заблуждаетесь насчёт Go

Вполне допускаю. Но это небольшая деталь в обсуждении влияния на программистов ООП и ФП. Если бы Go был ярким представителем языков с ФП, то я бы понял пафос. А так-то это обычный императивный ЯП с ООП, пусть и немного непривычным.

Композиция функций без состояния — это действительно проще некуда.

Да. Жаль только, что чистые функции бесполезны для прикладных задач. И получается «гладко было на бумаге», а при столкновении с реальностью у ФП адептов практикуется удаление гланд через этосамое. Поэтому они в таком маргинальном загоне, и все усилия продвинуть истинное ФП в массы проваливаются.

Проще только композиция (иммутабельных) данных

Это возможно в рамках ООП, никакой новой парадигмы тут изобретать не надо.

композиция (иммутабельных) данных

Это возможно в рамках ООП

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

То есть это будет уже не ООП, а его развитие — некий ООП++ %)

никакой новой парадигмы тут изобретать не надо

Математики занимались композицией чистых функций, когда до появления этого вашего ООП (вместе с компьютерами) ещё столетия оставались %)

наоборот всё же

Simple is not easy, буквально %)

Т.е. если ты можешь реализовывать интерфейсы, у тебя уже нет отношения is-a?

Ни интерфейсы, ни отношение «is-a» не имеет ничего общего с ООП. К счастью, большинство ООП языков эти концепты реализуют.

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

По сути, ООП - это коряво сделанный, неявный dependency injection реализованный на уровне языка.

Именно по этому, в современных подходах к написанию программ на «ООП» языках используются только

• Реализации интерфейсов
• Композиция/делегирование через реализацию интерфейса или даже без интерфейса, через явный DI

Само наследование не/крайне редко используется и полно всяких классов без состояний - по сути просто функций объединенных в модули за неимением нормальной поддержки вторых.

«отсутствие состояния (FP)»

Не совсем так, ибо программа с ФП срабатывает не мгновенно, каждое звено работает какое-то время и меняет ячейки ОЗУ. Состояние ячеек ОЗУ постоянно меняется до завершения программы. Соответственно, предсказываю следующие звенья эволюции:

1. ЯП в котором функции (включая операторы) не принимают и не возвращают данные.
2. ЯП в котором функции ничего не делают.
3. ЯП совсем без функций.

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

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

Просто зовёшь дворового человека и говоришь ему, что надо сделать.

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

Просто зовёшь дворового человека и говоришь ему, что надо сделать.

Нет, на вершине эволюции вам приносят уже сделанное.

Просто зовёшь дворового человека и говоришь ему, что надо сделать.

Эй, человек! Подойди к барину!

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

Вместо мутирования объектов порождать новые. Примерно как в этом вашем ФП. Только нужно API проектировать заново под иммутабельные объекты. Ну и паттерны пересмотреть. Никаких проблем уложить это в ООП нет, только кодерам будет неудобно и непривычно.

Математики занимались композицией чистых функций

Рад за них, пусть и дальше занимаются. Но в программировании ЭВМ это не работает. Тут машины состояний надо трясти, а не медитировать на чистоту. Все эти приседания с иммутабельностью нужны только из практических соображений для многопоточности. А так бы никто не заморачивался.

Вместо мутирования объектов порождать новые … Никаких проблем уложить это в ООП нет

В какой-то момент всё равно понадобится механизм для работы с изменяемыми ссылками на неизменяемые объекты. Хотя, конечно, можно для этого использовать обычные изменяемые объекты, как сейчас. Просто будет два типа объектов — неизменяемые, comparable by value значения и обладающие идентичностью, comparable by identity, изменяемые ссылки на неизменяемые значения.

Похоже, движение в этом направлении уже давно идёт — value classes вроде бы в некоторых недоязычках называется или типа того? Правда, ничто технически не мешает господам разработчикам продолжать по старинке пользоваться только вторыми и игнорировать первые. Наверное, лучше, чтобы это был отдельный механизм, который было бы невозможно (или хотя бы трудно и неудобно) абузить таким образом.

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

Например, посмотрим на values & references в кложе. Для хранения последовательности значений у нас значение — immutable persistent vector, для работы с последовательностью значений (например, этих самых векторов) во времени — ссылочный тип, atom, хранящий ссылку на текущее значение и предоставляющий API для её (атомарного) изменения — чтобы заставить её указывать на новое значение. Обязанности разделены, минимум путаницы.

Тут машины состояний надо трясти, а не медитировать на чистоту.

И трясти надо, и медитировать тоже нужно %)

Тут машины состояний надо трясти,

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

Не надо везде пытаться пихать ООП

Хочется спросить тогда, а где без ООП не обойтись? Когда пихать ООП?

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

И каким образом по вашему ООП решает эту проблему?

Напрямую.

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

В этом случае ООП не поможет никак от слова совсем. Если приходится «часто» и «в короткие сроки переписывать ваше приложение» то это означает только одно - вы рукопоп который неосиливает написать ТЗ и из под ваших грабелек выходит writeonly код.

точнее не вы, а менеджер который не добился точного ТЗ от клиента. это не ваша работа

точнее не вы, а менеджер который не добился точного ТЗ от клиента. это не ваша работа

«Вы» это обобщенное. В случае когда именно вы делаете в одно лицо, то «Вы» это именно «Вы лично». Когда это разделено на два и более лица, «Вы» можно расценивать как совокупность участников в котором «Вы лично» являетесь одним из...
Ну и что бы два раза не вставать.

а менеджер который не добился точного ТЗ от клиента

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

вина менеджера может быть в том, что он допустил невнятное ТЗ к подписанию

Именно это я и имею ввиду

До 80х еще не добрались

И какое же ООП в 80-х?

разосрать ваше изменяемое состояние на тысячу маленьких кусочков, спрятанных за уникальными интерфейсами

Если не умеешь готовить ООП, то может стоит освоить другую профессию? Потому что, со сткрутурным или функциональным программированием ты не напишешь конкурентный на современном ИТ рынке продукт.

Можешь ещё попробовать изобрести машину времени и переместиться в 80-е, там ПО довольно примитивное и можно обойтись без ООП. Будешь как в том ералаше: Я у них самый умный!

Если не умеешь готовить ООП, то может стоит освоить другую профессию? Потому что, со сткрутурным или функциональным программированием ты не напишешь конкурентный на современном ИТ рынке продукт.

А мужики и не в курсе оказывается. Срочно отправьте этот пост Линусу с просьбой разослать все девелоперам ведра и не только ведра.

Я не про легаси. А про современный ИТ продукт. Если сегодня ты начнёшь писать новый Линукс (редокс и вот эти все) на сях и прочих ржавых с недоООП, то ты не сделаешь конкурентный продукт. Но при использовании ООП (хотя бы на уровне джавы, я уже не говорю об изобретении новых ЯП с лучшим ООП) у тебя появляется шанс написать конкурентный продукт и вытеснить тот же Линукс или тот же Хром.

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

Срочно отправьте этот пост Линусу с просьбой разослать все девелоперам ведра и не только ведра

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

Вытеснение Линукса системой с ООП подходом лишь вопрос времени.

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

Я говорю о снижении порога входа, а не о тех кто что-то там не понимает. И конечно же делать ООП не на «сишке». Хотя бы ООП на уровне джавы.

Сложность там определяется свойствами программируемой системы, а не ЯП. Многопоточность, когерентность памяти, надёжная работа с памятью, производительность. Джава с ГЦ в ядре нахрен не нужна, а без ГЦ тоже не нужна, потому что неэффективна. Чтобы был максимально эффективный код, надо его проверять вручную (границы массивов и проч.), и использовать априорные знания о системе, не заложенные в коде.

Я тут уже писал, что софт как концепт придумали чтобы можно было ошибаться легко и просто. Кто-то до сих пор этого не понимает.

вроде как rust в ядро пустили

это очевидно не так чисто как си однако rust дешевле в части программистов нужной надёжности кода