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

Вы реально и гвозди и шурупы забиваете молотком?

Вы сейчас это к чему?

Понял, спасибо за пояснения. Но вот банк вы зря упомянули, как раз в этой сфере легаси ну ооочень много. :)

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

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

ты вообще не понимаешь о чем говоришь, и понятия не имеешь о гибкости CL и его реализаций

Как бы выбора нет, либо синглетон, либо глобальный контекст … В общем я не вижу чем тут ООП сильно помогает.

Никакой синглетон не нужен тут. Просто данные расходятся по дереву объектов через методы.

Вернёмся к тому же примеру с GUI. Кликаете по кнопке, в форме вызывается метод, который считывает текст из поля ввода и передаёт в обработчик. Обработчик доступен по ссылке, которая хранится в форме. Обработчик преобразует текст и отправляет на передатчик, ссылка на который есть у обработчика. Передатчик отправил данные по сети и получил ответ, который вернул обработчику, тот вернул форме. Данные идут по цепочке методов без всяких глобальных переменных и синглетонов.

конкретный пример с абстрактными классами

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

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

Это больше похоже на func1(func2(func3(data))) нежели на ооп какое.

Похоже. Но у объектов есть состояние, а у функций нет. Например, у передатчика могут быть изменяющиеся IP-адреса, а у обработчика коэффициенты. И они в объекте хранятся. Их не надо откуда-то брать и передавать функциям в виде параметров каждый раз.

Тогда где надо ставим вместо функций замыкания.

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

У меня было мало практики с замыканиями, но по моему опыту они менее гибкие и удобные. Могу ошибаться.

ЯП это инструмент так же как молоток и отвертка. Вы же продвигаете использование одного инструмента для всего и для гвоздей и для шурупов.
Шурупы и гвозди это из: “Хозяйке на заметку: Шуруп забитый молотком, держится лучше гвоздя завернутого отверткой.”

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

Разница в области видимости. В объектах данные инкапсулированы, их не может менять кто попало извне (хакерства в расчёт не берём).

Аналогии это скучно и банально. Вот, если бы вы переписали оракл (или сопоставимого мамонта) на node.js, а потом рассказали о своём опыте — было бы интересно.

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

(define y
  (let ((k 4.2)
	(b -1.6))
    (λ (x) (+ (* k x) b))))
scheme@(guile-user)> (y 10)
$13 = 40.4
scheme@(guile-user)> (y 0)
$14 = -1.6

А как поменять k и b в y?

Если сделать наивно вызывая методы и ожидая результата UI тред будет постоянно уходить в waiting state. Работать с таким UI будет невозможно.

[UI Compnt] ---> [ Controller ] ---> [ MsgDispatcher ] --|--> { Net }
                                                        Wait? 

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

Теперь как результат доставлять для отображения в UI? Можно опять же подписаться на события ответов, или сделать Presentation Model который будет содержать состояние отображения, где UI должен будет себя перерисовывать в случае изменений в модели.

Тут без глобальных состояний не обойтись.

стратег?

Вернуть лямбду, которая уже будет предоставлять нужную функцию:

(define (scaler)
  (let ((scale 1))
    (define (reset-factor!)
      (set! scale 1))
    (define (set-factor! x) (set! scale x))
    (define (factor x)
      (* x scale))
    (λ (msg)
      (cond
       ((eq? msg 'reset) reset-factor!)
       ((eq? msg 'set) set-factor!)
       ((eq? msg 'factor) factor)
       (else (error "SCALER — unknown action"))))))

scheme@(guile-user)> (define s (scaler))
scheme@(guile-user)> ((s 'factor) 10)
$17 = 10
scheme@(guile-user)> ((s 'set) 3)
scheme@(guile-user)> ((s 'factor) 10)
$18 = 30

Опять ребусы.

Если сделать наивно вызывая методы и ожидая результата UI тред будет постоянно уходить в waiting state.

Да. Это так. Если бы я сразу писал со всеми деталями, то получилась бы простыня. Поэтому наивный пример.

Можно опять же подписаться на события ответов

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

вообще не понимаешь о чем говоришь

Ну давай на конкретных примерах. Вот взял ты библиотеку, которая реализует иммутабельный персистентный вектор. И что дальше? С ней даже банальные map/reduce/filter (или как там их аналоги в стандартной библиотеке борщелиспа называются, как-то упорото вроде) работать не будут, не говоря уже о чём-то более продвинутом. А значит, придётся или писать всё самому, или надеяться, что кто-то уже написал как раз то, что тебе нужно и как раз именно для той библиотеки иммутабельных векторов, которая у тебя есть. Ну или каждый раз конвертировать иммутабельные коллекции в списки и обратно, да.

Да и весь дизайн языка (если это слово, конечно, можно писать в одном предложении со словом «борщелисп») как бы намекает, что иммутабельность тебе не нужна, ей здесь не рады. И это в век массовых параллельных вычислений, ага.

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

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

понятия не имеешь о гибкости CL и его реализаций

Эта «гибкость» на деле практически ничего тебе не даёт, кроме дополнительной работы. Много дурной дополнительной работы. Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано? %)

Пришли мыши к филину, жалуются:
- Мы, мыши, самые маленькие, слабые, каждый обидеть и сожрать норовит.
Че делать?
Филин подумал, подумал - говорит:
- Вам, мыши, надо превратиться в ежей. Будете колючими - и вас не так
просто будет съесть.
Мыши убежали, радостные:
- Да, да! Превратимся в ежей! Спасемся!
Через некоторое время возвращаются к филину и робко спрашивают:
- Ты сказал, надо в ежей превращаться... НО КАК???
Филин:
- Да пошли вы на хрен! Я не тактик - я стратег!!!

Вы там бухаете что ли уже?

Это какое-то ООП. Тут класс scaler с тремя методами (factor, set-factor, reset-factor) и одним полем (scale). Ну и экземпляр этого класса s.

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

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

Это был ответ про Стратега.

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

Это какое-то ООП.

Вот чтобы такое не велосипедили на замыканиях, нужна объектная модель сразу из коробки. Пусть она будет убогая, но будет. Иначе неизбежно получится зоопарк несовместимых объектов или их эмуляция через жопу если с ЯП совсем беда. А совсем без объектов пограмировать это садо/мазо какое-то. Ну можно конечно придуриться, что замыкание не объект, но это читерство. Посмотрел бы я на адептов ФП если у них блямбды эти отобрать.

зоопарк несовместимых объектов

Зачем вам непременно объекты, чем мапки не устраивают? Ассоциативная структура данных — то, что доктор прописал.

примитивная же штука, делается на коленке

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

Я так понял из описания, что у тебя нет модели состояния или отображения, если очень прижмет ты создашь поле в контроллере для того чтоб «кэшировать» определенное значение. Ну так себе решение, все получается прибито к UI.
Плюс у тебя вместо глобального состояния (модели), есть контроллер со своим временем жизни и он хранит все нужные состояния.

И я уже начинаю терять нить обсуждения. Диалог начался с такого моего утверждения:

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

Ответное сообщение:

Вопрос. Вот есть какая-нибудь сишная библиотека, типа sqlite или sdl2. Там особо хитрых абстракций никаких вроде бы нет

sqlilte это конечное приложение, не фремворк. sdl2 это библиотека-адаптер предоставляющая платформенно независимый API.

Тут везде ООП ненужно, повторное использование кода разумеется будет, но оно выполняется в compile-time. Мое изначальное утверждение:

ООП это про хитросделанное повторное использование кода

Это про больше про фремворки, когда не ты сам пишешь тот же Common Gateway Interface (CGI) с нуля а пользуешься готовым решением (например Servlet API, WebMVC,etc), дописываешь недостающую логику на случай успеха, на случай ошибки, настраиваешь фильтры и все это резолвистя в runtime. Наверное если взять тот же Godot то будет тоже самое. Это тоже повторное использование кода, но по-другому.

Вам надо, вы и делайте. Если на вашем языке какие-то простые вещи делаются сложно, нужно собирать комитет седовласых мудрецов, чтоб они двадцать лет трудились, то … ну, сочуствую я вам, вот что. Но присоединяться к клубу мазохистов не собираюсь.

как раз в этой сфере легаси ну ооочень много

Ага, на Java.

как раз в этой сфере легаси ну ооочень много

Ага, на Java.

И на ней тоже :)

Copium is stronk here. Чем позднее родился, тем круче кажется i386.

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

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

Товарищ Хрущёв ничего не знал, в ЦК пробрались враги!

тут в строку цитата из «Государство и революция»(али как нам реформировать рабкрин али из профсоюзов - крч 19-20 года XX века) из ВИЛ'а с констатацией(декларацией?) - что первенство в «окомуниздивании» в 1/6(али даже в 2/7 если мерить чуток раньше) событие временное обусловленное текущим положением дел - так что истинное благолепие ...

история истории отдельная история

ps. забавно что религия ООП засектанила АТД

Товарищ Хрущёв ничего не знал, в ЦК пробрались враги!

А то Хрущева на пенсию друганы по дружбе чисто попросили, пока он в Пицунде отдыхал. Или он добровольно власть отдал? А первый секретарь ЦК компартии Украины Шелест, на Брежнева просто наговаривал же, что тот уговаривал председателя КГБ Семичастного устроить Хрущеву «аварию самолёта, автомобильную катастрофу, отравление или арест». Только перспективу асучивания генералитета Китовым не принял именно генералитет: «резкая критика состояния дел в МО СССР с внедрением ЭВМ, содержащаяся в преамбуле к этому докладу, а также предложения по коренной перестройке системы управления как в Министерстве обороны, так и в высших эшелонах власти СССР, содержащиеся в докладе, определили негативное отношение к докладу со стороны руководства Министерства обороны СССР и работников аппарата ЦК КПСС» (с) Ты еще скажи арестам тыловых генералов щас удивляешься, про которых еще в Союзе анекдот сочинили про два стенда выпускников в училище тыла «эти еще служат, эти уже сидят». Или может не «мафия» Гарбузова, министра финансов СССР, «лоббировала» клонирование IBM вместо развития своих архитектур?

На коболе же :)

И RPG 🗄️

Если честно, то классическое MVC я никогда не мог понять. Возможно, оно действительно построено на синглетоне (синглетонах) и это вызывало у меня непонимание.

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

В моей системе класс UI не занимается вычислением или обменом данными. Только интерфейсом пользователя. Всё остальное делегируется другим классам. Соответственно, каждый класс занимается своей узкой задачей. Если это противоречит классическому MVC, то не значит, что моя система хуже.

дописываешь недостающую логику на случай успеха, на случай ошибки, настраиваешь фильтры и все это резолвится в runtime

Возможно, это и круто. Мне трудно оценить. Но это не ООП. Это что-то над ним или даже сбоку. Возможно лишь, что в этой системе без ООП никак.

Разница в области видимости. В объектах данные инкапсулированы, их не может менять кто попало извне (хакерства в расчёт не берём).

С этим никто не спорит и нарушать принцип сокрытия данных не призывает.

Допустим, у меня есть класс и соответсвующий объект Репозиторий, который, как вы совершенно справедливо заметили, инкапсулирует операции с хранилищем. Никаких публичных методов изменяющих сам объект репозитория у него нет. Дальше у нас есть два сценария (оставим пока в покое ДИ-фреймворки): 1. проинстанциировать объект репозитория где-то близко к точке входа и передавать его по цепочки во все сервисы и 2. инстанциировать синглтон и обращаться к нему откуда угодно, где нам нужен этот Репозиторий не передавая его по цепочке вызовов. Вопрос прежний, почему по-вашему вариант 2 это плохо?

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

Имхо, синглтон это антипаттерн конкретно в Джаве, в том же Котлине для синглтонов сделали красивую обертку в виде object и вуаля, это больше не антипаттерн.

Да я согласен, что КПСС была гадюшником с ног для головы. Меня удивляет зачем вы для Хрущёва делаете исключение.

Ну давай на конкретных примерах.

sb-sequence

иммутабельность тебе не нужна, ей здесь не рады

Потому что в ней нет практического смысла, это дрочь уровня ООП или статической типизации, очередной silver bullet.(inb4 хиндли-милнер в CL тоже делается - см. Coalton)

Потому что построена вокруг абстракций

Говено она построена, глючит и тормозит. Абстракции кривые, названы на какой-то хер самим хикки выдуманными именами(что прослеживается вообще во всей экосистеме Clojure - трансдьюсеры, ну твою же мать - задача была впихнуть слово поумнее). Отовсюду лезет жабка. Отлаживать невозможно. Стандарт CL - ориентирован на практику, производительность и переносимость, а не на принцип «я тут увидел/придумал модную фишку». У Clojure, кстати, стандарта вообще нет, поэтому правильнее всего сравнивать Clojure скажем с ведущей опенсорсной реализацией - SBCL. Поэтому см. выше, sb-sequence, и другое(source transformers кастомные, итд).

Вот этим современный лисп и отличается от архаичного

Clojure - это деградация по сравнению с Common Lisp, и тем более с его современными реализациями. Это движение назад. Плюс упоротые вещи, которые пришли в голову хикки.

Эта «гибкость» на деле практически ничего тебе не даёт, кроме дополнительной работы.

Я же говорю, понятия не имеешь.

Разве не от неё ты пытаешься сбежать в уютный дотнетик, где так много всего готового и полезного понаписано?

Это как раз пример гибкости CL. Точно так же можно опуститься до уровня системных API, типа DirectX/Vulkan, и писать на нем игрушки, в т.ч. даже AAA тайтлы, заоптимизировав на нем программы до уровня сишечки а то и вообще ассемблера. Или например, на нем можно писать скрипты. CL вообще гибкий и разносторонний, и его с легкостью можно приспособить под практически любую задачу(ну кроме там совсем допотопных микроконтроллеров, возможно), чего не скажешь о Clojure, максимум которой - сраная вебня.

Имхо, синглтон это антипаттерн конкретно в Джаве, в том же Котлине для синглтонов сделали красивую обертку в виде object и вуаля, это больше не антипаттерн.

В этом двадцатиминутном видеоролике программист Черников очень доходчиво разъясняет почему использование синглтона это плохо.

извините, я не спрашивал мнения господина Черникова, я задал вопрос конкретному пользователю и в вопросе звучало «как по-вашему»

обертку в виде object и вуаля, это больше не антипаттерн

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