Здравствуйте, Cyberax, Вы писали:
C>>>Есть. Нет "наследования классов" и мастурбирования на "контроль доступа". S>>Ну, такой себе ООП. Самую мякотку и выкинули. C>Наследование классов — оказалось противопоказано и в классических ООП, так как создаёт слишком сильную связность. А детальный контроль доступа просто не нужен, достаточно разделения между публичным интерфейсом и приватным для пакета.
Чем protected то не угодил?
Здравствуйте, Sheridan, Вы писали:
НС>>Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия? S>У вас выбора нет, у вас уже есть куча мала и её хоть както надо запустить.
Это не только у нас, это чуть более чем во всех крупных проектах так.
S>Я же про ситуации когда выбор (ещё) есть.
Не увидел этого в твоем заявлении:
Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Теперь это все нам нужно собрать в работающий продукт, причем в разумные сроки. Твои действия? S>>У вас выбора нет, у вас уже есть куча мала и её хоть както надо запустить. НС>Это не только у нас, это чуть более чем во всех крупных проектах так.
Ну ниоч, в общемто. Поддерживать зоопарк — такое себе...
S>>Я же про ситуации когда выбор (ещё) есть. НС>Не увидел этого в твоем заявлении: НС>
НС>Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках.
А этого там и нет. Я говорю "это плохо конечно, но у вас нет выбора".
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Я в какой то момент вернулся и перечитал начало книжки Гради Буча (которая Object Solutions). Там очень доходчиво и чисто про ООП изложено, и вместе с тем хорошо понимаешь, насколько оно натянуто и плохо стыкуется с реальным кодом и реальными задачами, а не какой нибудь модельной автоматизацией теплицы.
АФАИР у меня к коду модельной автоматизации теплицы тоже были претензии; но это было сто лет тому, поэтому без перечтения вспомнить не выйдет. НС>Судя по тому что ФП уже много десятилетий, а ФП гуя вменяемого нет до сих пор — сильно. Нужны какие то новые подходы.
Может быть, может быть. Ну, либо признать, что ООП прекрасно подходит для гуя, и там его и оставить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали: S>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно? Что с эволюцией делать будем?
Дяденька, а вы точно программист? S>Ну и вообще там всё такое.. "А может быть, а может и не быть". В челом написано умно но ничего существенного.
Там просто нужно понимать, о чём идёт речь.
Есть более медленное изложение, к примеру, той же проблемы ограниченности иерархических таксономий — у Липперта. S>В общем, автор очень хочет очернить ООП, явно видно.
Особенно это видно по тому, что у него же есть топик Benefits of OOP.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
I>>В любом случае конфигурация финишного деплоймента на момент разработки неизвестна. И в конце спокйно может оказаться мешанина вида "софтина-плагины-еще-софтина-еще-плагины" имее взаимоисключающие требования. S>Всмысле неизвестна? Как софт должен установиться и как работать уже должно быть известно ещо до первой строки кода, на проектировании. Окружение по мере разработки да, может поменяться. Наприер, используемая БД или средства мониторинга. Но чем ближе к финишу, тем всё более точно известно и окружение.
Для небольшого класса приложений это так. А для остального софта финишная конфигурация принципиально неизвестна.
S>При этом деплой пишется сразу, параллельно разработке. И этим кодом деплоя выкатывается продукт на stage сервера.
Ну вот я взял alpina + node, понакидывал туда хрен знает чего — десятка два софтин. Каким образом команды alpine или node или команды тех софтин будут в курсе про эту мою конфигурацию?
I>>Заказчик платит не за софт в дистрибутиве, а за решение конкретной его проблемы. all-in-one это хороший вариант исключить проблемы с шаред/транзитивными зависимостями. S>Определитесь уже. То заказчик не может на свои сервера поставить для вашего продукта нужную ОС (из списка популярных и заведомо стабильных), то ему побоку на ОС и ему надо решить некую проблему. Взаимоисключающие пункты.
I>>Снова тебе программисты мешают. S>Я чтото не так сказал? Программисты умеют находить корни проблем и исправлять их? Если да, то к чему этот разговор? Срач ради срача?
Программисты нынче работают на конкретном проекте, в рамках конкретного стека. Искать и фиксить баги в ядре линукса больше не является их задачей, т.к. это стало дико дорого.
I>>Здесь ровно наоборот- ты по пять раз на сообщении утверждашь, что с прграммистами чтото не то. S>Конечно чтото не то. Вас послушать так программист умеет только код в студии набирать. Чуть чтото не так и сразу у него лапки.
Ты снова пишешь из 90. Программист это не всемогутор и не мастер на все руки. И разработчик ПО это только частный случай программиста, при этом специализаций таких разработчиков вагон и маленькая тележка.
I>>Совсем необязательно, что придется. Это всего лишь риск. Сработает ли он, и во что обойдутся последствия это отдельный разговор. И слишком часто заказчик принимает решение, что ему выгоднее всего игнорировать такие риски. S>Ты по верхам прыгаешь. Спустись на землю. Этот риск при своевременном обновлении либ воообще не возникнут.
Ты попутал причину и следствие. Обновление — это одна из стратегий управления риском, т.е. минимизация вероятности небрагоприятного результата. И у тебя это единственно возможная, единственно правильная стратегия.
Есть и другая стратегия — игнорирование. А можно сказать — "дешевле заплатить когда случится фейл". Это тоже возможные стратегии. Тебя послушать, так они все оказываются неправильными.
I>>Да, бывают такие баги, которые трудно воспроизводятся, или их фикс ломает обратную совместимость. БОлее того — приоритеты в разработке никто не отменял. А в опен-сорсе тебе никто ничего не должен. S>Это ты к чему? Да, такие баги бывают. Но как это относится к тому что автор забил на свой проект и несколько лет его вообще не сопровождает?
В том то и дело, что никак. Берешь ты либу А, думаешь, что всё хорошо, написал тесты, запаблишил. Другая команда через полгода собирает на основе твоего солюшна свой собственный, и выясняет, что у них баг, который автор либы А никак не может пофиксить.
Им что теперь, проплатить тебе переписывание с нуля, что бы ты построил солюшн на основе другой либы?
I>>Это только с детскими багами так, когда сразу ясно где он, и как его воспроизвести. А слишком часто баг в одном месте, а причина — в противоположном, и появляется не сразу, а время от времени, через пару дней и последствия S>То у тебя тот же баг в другом месте. То у тебя баг вообще неуловимый. Сколько у тебя обуви то?
Баг это обычно наблюдаемое поведение. Т.е. именно то, что описывается в багтрекере. Причина на этот момент неизвестна. В какой части проекта находится причина — сказать невозможно. Для этого надо идентифицировать, локализовать проблему.
Соответсвенно, нормой является именно описаный мной случай.
Например — UI содержит мусор. А причина в наполнении БД на другом ресурсе.
I>>А это норма в опен-сорсе — игнорить баги. Заходишь зарепортать в популярный репозиторий, а там булькают вещи еще с нулевых. S>Если брать к себе в проект либу которую когдато вася пуповкин написал для себя то так и будет. И часто у вас ошибки выбора используемых либ? Как часто вы хватаете первое попавшееся а потом "ойвей, а либа то мёртвая!"?.
Ты слово "популярный" правильно понимаешь?
I>>Так я не сужу по себе. S>Вот только не надо говорить мне что если весь мир называет белое чорным то и я обязан это делать.
Так в том то и дело — весь мир живет не по твоим правилам
I>>Снова программисты виноваты. S>Не все, а только те, которые тупы.
Обычно ты пишешь максимально обобщая "программисты некомпетентны".
I>>У тебя похоже риск и инцидент это одно и то же. S>Нет. Но тебе же важно набросить на вентилятор.
Собственно смотри пример про обновление — там ты снова демонстрируешь эту самую особенность и у тебя всего она единственная стратегия.
Пример
есть риск уязвимости
— обновить, затратив 100 чаоов * 30$ в час + налоги — это твой вариант, с твоих слов это единственно правильный
А есть и другие
— игнорировать — бывает и так, для маловероятных или некритических рисков это наилучшая стратегия
— не обновлять, а закрыть файрволом-фильтром, стоимость 1 час * 30$ + налоги
— не обновлять, а застраховать риски и выплатить пенальти, когда сработает уязвимость, стоимость страховки/пенальти прилагается
— не обновлять, т.к. через год будет другая версия на другом движке
— передать другой команде, пусть они думают, надо им или нет
— открыть для опенсорса, пусть обновят те, кому это актуально
— обновить когда будет на это бюджет
Здравствуйте, Sheridan, Вы писали:
V_>>Вот на экономию этих мегабайт Шеридан их хочет оправдать свой подход, идущий в разрез с реальностью бытия. S>Нет. Никакой экономии не будет. Потому как у вас программисты все пишут вразнобой и в проекте может быть несколько версий одной и той же либы.
Вот есть у тебя либа X, на ней сделаны две другие либы, А и Б, + X ты используешь у себя. Но А протестирована для версии X@1.0.1 а Б протестирована дя X@1.1.0, релизный цикл у каждой из них разный.
Итого, если вдруг ты решишь обновиться на последнюю X@1.2.0, ты получаешь новую, неизвестную конфигурацию, т.е. никто не проверял, насколько А и Б совместимы с этой версией.
Проекты, которые ограничивают либы единственной версией каждой либы идут в тупик — они всегда работают с конфигурациями, для которых никто и никогда не прогонял хотя бы минмальный набор тестов, что есть огромная неопределенность и чудовищный риск.
А вот те, кто разрешают несколько версий, получают определенные гарантии, что А + X протестированы, и Б + X протестированы. Но проигрывают в размере дискового пространства, которое, внимание, много дешевле времени работы что программиста, что тестировщика.
Здравствуйте, Sheridan, Вы писали:
НС>>Это не только у нас, это чуть более чем во всех крупных проектах так. S>Ну ниоч, в общемто.
Пиши по русски.
S> Поддерживать зоопарк — такое себе...
Да вообще что то поддерживать — такое себе. Лежать на печи и нифига не делать — еще проще. Вопрос только в том, кто за этот праздник жизни будет платить.
S>А этого там и нет. Я говорю "это плохо конечно, но у вас нет выбора".
Выбор есть всегда. Например, взять и переписать требуемый сервис на нужном языке. Только за все при этом надо платить.
Здравствуйте, Sheridan, Вы писали:
НС>>Бизнес не платит деньги за обязательное и постоянное обновление либ. S>Это такая же часть работы, как и нажатие на кнопки.
Бизнес не платит деньги за обязательное и постоянное обновление либ.
S> Так что платит.
Нет.
S> Но эта работа не выполняется (иначе бы срача не было).
Или выполняется ровно в том объеме, в котором это требуется, а не в том, в котором хочется Шеридану чтобы соответствовать его идеальной картине мира.
S> И то что бизнес просто не в курсе того, что часть работы не выполняется вы почемуто интерпретируете как "бизнесу это не надо".
Бизнес нормальный в курсе всех работ. И когда он не понимает их необходимости, он задает прямой вопрос — какую пользу эта работа принесет продукту что мы вынуждены на это тратить большое количество ресурсов? Сможешь на него ответить?
S>>> Бизнес хочет стабильный, развивающийся продукт. НС>>Осталось доказать что постоянное обновление всех либ — обязательное условие для стабильного, развиваюющегося продукта. S>Потому что если не обновлять то со временем продукт тупо перестанет работать на свежих ОС.
Или не перестанет. И уж точно не перестанет работать через квартал, как ты тут обозначил в качестве крайнего срока на полное обновление. И уж точно не перестанут работать разом все несколько сотен зависимостей.
S>Не "при их релизе сразу", а "сразу во всех проектах". Казнить нельзя помиловать получилось, да.
Дальше было "хотя бы раз в квартал". При типичном для крупных проектов количестве зависимостей их обновление будет хотя бы раз в квартал будет занимать значительную, если не большую часть ресурсов команды.
S>>>Зачем вы мне пишете тогда фразы типа "обновлять ненужно"? НС>>Приведи где я такое написал. Не стыдно врать то? S>Я написал "вы". Тебе бы я написал "ты".
Зачем в разговоре со мной ты привел чужое высказывание?
Здравствуйте, Sheridan, Вы писали:
НС>>Могу S>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно?
Абсолютно. Нет в реальном мире наследования за пределами биологии. Есть множество разнотипных связей, жесткая редукция которых до иерархического однонаправленного графа со строго одним типом связи ни к чему хорошему не приводит.
S>Что с эволюцией делать будем?
Ты часто автоматизируешь что то, связанное с эволюцией живых организмов? Мне вот ни разу не джоводилось.
S>OO is Xenophobic — вообще фантастический аргумент
И что с ним не так? Здравый аргумент, и это именно то что мы наблюдаем на практике. Чуть менее чем все кроссплатформенные интерфейсы — не ОО, начиная от dll и заканчивая новомодными REST и gRPC. А все попытки сделать ОО (СОМ, SOAP, CORBA) — в итоге померли или в процессе.
S>В общем, автор очень хочет очернить ООП, явно видно.
Не, скорее ты принял ООП за аксиому и не способен сползти с этих рельс.
Здравствуйте, Sheridan, Вы писали:
S>Ну, такой себе ООП. Самую мякотку и выкинули.
С чего ты взял что наследование это мякотка? Вот у меня в текущем проекте на десятки мегабайт исходников наследования реализаций по пальцам одной руки, и ни в одном из этих пальцев нет виртуальных функций. Та еще мякотка выходит.
Здравствуйте, Sheridan, Вы писали:
S>>>Да-да-да, контейнеры разворачиваются чуть ли не по щелчку пальцев. Но чтобы это произошло ктото должен это описать, настроить, подготовить инфраструктуру НС>>Есть возможность развернуть кластерное решение без "ктото должен это описать, настроить, подготовить инфраструктуру"? S>Нет.
Тогда в чем бенефит отказа от контейнеров?
S>>>С тем же успехом можно не в контейнеры а в ansible/chif, да хоть тупо в скрипты. НС>>Можно, но контейнереы проще, универсальнее и быстрее. S>Все три — спорно.
Так поспорь.
S>Если кратко — зависит от опыта того кто это делает.
Это не кратко, это пусто.
S>>> Причом следующим же пунктом после "vm нинужны!" НС>>Где ты увидел такой пункт? S>Прямо перед обсуждаемым.
Там нет этого. Ты реально не понял о чем речь или прикидываешься? ВМ не "не нужны", ВМ дорого обходятся. Контейнеры позволяют использовать меньше ВМ, или вообще их не использовать явно.
S>>>Ой, а без контейнеров как будто приложения работают по другому. НС>>Они больше зависят от окружения, как следствие больше проблем при деплойменте в конкретное окружение. S>Ну так хоть какието минимальные требования к окружению то должны быть, не?
Да, ядро линуха с поддержкой контейнеров. Это все.
S>Или вы эти требования делегируете докеру?
Нет, делегируем конкретному дистру хостовой ОС, который обязан уметь в стандартные контейнеры.
S>Заказчику всё равно, он их выполнит либо для докера либо для вас.
Заказчику не все равно, потому что он либо использует облако публичное, и тогда там контейнеры искаропки, либо приватное, и тогда ему куда проще использовать стандартное решение нежели настраивать и обучать своих админов уникальному решению имени Шеридана.
НС>>Нельзя. Контейнер понимается намного быстрее, чем отрабатывают твои скрипты. Я уж не говорю о том, что собрать контейнер намного проще и требует меньше знаний. S>Тоже спорно
Поспорь.
S>и тоже зависит от опыта исполнителя.
Какой такой опыт сделает пяток строчек в dockerfile сложнее написания ansible скриптов под все поддерживаемые разновидности ОС?
Здравствуйте, Sheridan, Вы писали:
S>>>Я тебя спросил считал ли ты стоимость сопровождения. НС>>Я писал про контейнеры, ты спросил про кубер. Почему я должен включать стоимость сопровождения кубера в оценку бенефитов от контейнеров? Так при чем тут кубер? S>А что, куб внезапно перестал быть модным и все обратно в докер-композ вернулись?
Опять уходишь от вопроса. Мы обсуждали контейнер, при чем тут оркестратор? Могут быть контейнеры без оркестратора, может быть оркестратор без контейнеров, это ортогональные вещи.
S>Ну допустим что так, сделай s/куб/докеркомпоз/ — смысл вопроса останется тем-же.
Зачем мне отвечать на вопрос о стоимости поддержки кубера при обсуждении контейнеров?
S>Все три — спорно. Если кратко — зависит от опыта того кто это делает.
Нет, однозначно нет.
S>>>Напомню только что ровно так же можно и без контейнеров при помощи того-же ansible. НС>>Нельзя. Контейнер понимается намного быстрее, чем отрабатывают твои скрипты. Я уж не говорю о том, что собрать контейнер намного проще и требует меньше знаний. S>Тоже спорно и тоже зависит от опыта исполнителя.
Ansible не идемпотентен. Откатить Ansible не вернет к предыдущему результату.
Накатывание Ansible зависит от другого Ansible и нет никаких гарантий что это не сломается.
Дальше, Ansible это операция инициируемая оператором. Scale up и scale down могут быть динамическими и случаться каждый день в зависимости от дневной нагрузки.
Неужели ты настолько дремуч, что не понимаешь ограничения Ansible? Может ты и в Ансибле своем некомпетентен? Я уже убеждаюсь, что и в нем ты — самозванец-профан
Здравствуйте, Sheridan, Вы писали:
S>Расскажу только, что у него astra linux smolensk.
Ну вот ты и у своего пересыхающего озерца, закрытой экологической ниши. Главное, чтобы второй такой отставший от развития не пришел и не начался смертный бой за последний ресурс.
НС>Возврат ошибок порождает кучу макаронного бойлерплейта в любом языке (включая го, хоть и в меньшей степени), это факт, а не боязнь.
Такой же "факт" как и "теряется стектрейс" или "пытаются обрабатывать ошибки на месте (с багами)". Собственно ты даже не скрываешь что говоришь о каких-то других языках и проецируешь проблемы этих языков на го.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Абсолютно. Нет в реальном мире наследования за пределами биологии.
Я в последнее время придерживаюсь точки зрения, что наследование должно было Интерфейс — [0..N] Абстрактных классов — Имплементация. Если родительский класс не абстрактный, то поведение наследника должно чем-то отличаться от поведения родителя, иначе не нужно было бы существование наследника. А полиморфизм, при котором поведение наследника отличается от поведения родителя, я считаю антипаттерном.
Здравствуйте, Константин Б., Вы писали:
КБ>Такой же "факт" как и "теряется стектрейс" или "пытаются обрабатывать ошибки на месте (с багами)". Собственно ты даже не скрываешь что говоришь о каких-то других языках и проецируешь проблемы этих языков на го.
Приведи кошерный пример кодов возврата на го с парой-тройкой уровней вложенности, обсудим.
