Комментарии 306
Никогда не читайте перед обедом книг по специальности
Плавно переходит в "Никогда не читайте книг по ООП". Видимо по другим парадигмам читать можно.
Что касается паттернов, то считаю, что ознакомится с ними не вредно, тем более, что в ООП на 99,9% (и то только исходя из идеи никогда не говори никогда) все эти паттерны самоочевидны, но их повсеместное, практически насильственное применение - лютый сектантизм.
И да,
Да ты просто хейтишь ООП!
А в остальном (кроме идеи вообще сравнивать различные парадигмы в терминах хуже/лучше) полностью согласен
Плавно переходит в "Никогда не читайте книг по ООП".
Дык а других-то нынче и нет :)
кроме идеи вообще сравнивать различные парадигмы в терминах хуже/лучше
Я никогда не сравнивал парадигмы в терминах хуже/лучше. Если так показалось — это лишь оттого, что я недостаточно хорошо владею выразительностью русского языка.
Плавно переходит в "Никогда не читайте книг по ООП"
У меня похожее ощущение было, только еще шире. Особенно когда пример с одной книгой (религиозной) привели. Из разряда - не читайте книги, никому не верьте, учитесь на своем опыте. Но думается мне, что автор статьи все же не настолько категоричен.
До того — оставайтесь максимально непредвзяты
Вот с этим утверждением автора я согласен. И тут же - не согласен со следующим утверждением
не позволяйте дутым авторитетам из интернетов заменять вам мыслительный процесс своими сектантскими лозунгами.
Не согласен потому, что авторитеты бывают совсем не дутыми. И для новичков сильный спец с 20-м опытом это авторитет. А ещё книга - это такой способ передачи жизненного опыта между людьми, наряду с обычным общением. Это не замена мыслительного процесса, это часть процесса познания.
И если смотреть шире на проблемы излишнего доверия к авторитетам, то можно придти к выводу, что многие просто не умеют правильно читать книги. Ведь серьезные книги надо читать медленно, вдумчиво, размышляя над утверждениями автора, задавая вопросы и ища ответы на них в тексте.
можно прийти к выводу, что многие просто не умеют правильно читать книги
Именно. Но тем, кто уже умеет читать книги — текст выше и не предназначался, они пожмут плечами, и либо согласятся, либо — нет, обе реакции ожидаемы и лично для меня — практически идентичны.
авторитеты бывают совсем не дутыми
Несомненно. Но дутых в разы больше, новичкам их крайне сложно отличить от настоящих, а цепляют они сильнее. Лучше не прочитать 10 хороших книг, чем прочитать одну плохую и слепо уверовать в изложенные догмы.
Я вот, например, прежде, чем написать этот текст, — заглянул в гитхаб Боба Мартина. Очень рекомендую, если хочется поржать.
Мне казалось всегда что ООП это логическое продолжение функционального программирования. ООП на то и объектно ориентирован (а не паттерно прошу заметить) что во главе всего стоит объект. Дальше уже существуют паттерны которые являются подсказками по работе с объектами. Не зря же они делятся (предположу что почти в любой книге) на порождающие (создаём объект), структурные (задаем некие механизмы взаимодействия между объектами, но не привязываемся к конкретному, например внедрение зависимостей) и поведенческие (можем выделить объекты в какую-то рабочую логическую единицу и получить результат, например итератор, массивы в функциональных языках тоже есть?) Вот все жду когда придут люди и скажут что можно все писать на ассемблере, оно и так работает, вы не знали что-ли? Изобрели интерфейс для ассемблера, теперь для полиморфизма не нужны функции и объекты (joke)
Дык для полиморфизма и ООП не нужен.
Кроме того, этот текст про то, что паттерны в ООП — никуда не годятся, а не о том, что само ООП никуда не годится.
Мне кажется чтобы такое говорить, надо предложить свое, или по полочкам разгромить устоявщиеся устои. Если вы лично не видели хорошей реализации, думаете ваша выборка знаний достаточна чтобы все это экстраполировать на всю индустрию? Мне например Java не нравится как язык своим отношением к программистам, может поэтому код Мартина и выглядит так себе. Но ООП это не про язык ведь.
Мне кажется, у меня вполне достаточная выборка, чтобы что-то говорить и даже писать. Но даже если нет, — я в другом городе и что вы мне сделаете?
ООП есть? А если найду? ))
Шутка смешная, оценил. Но приведу пример из музыки, где один из участников вутэнг клана сказал что прежде чем нарушать правила в музыке, нужно их знать
прежде чем нарушать правила
в музыке, нужно их знать
Это бесспорно, и я не случайно взял на себя смелось вычеркнуть из цитаты музыку: это применимо к любым правилам. Но неприменимо ко мне. Я знаю всё.
А я думал случайно) Ну после описания визитера, как что-то про полиморфизм я конечно понял что вы все знаете. Был один мужик давно, сказал что знает что ничего не знает, но куда уж ему, тоже авторитетом всех задавил, а все только и повторяют.
Ну, первый повторивший сначала был на коне и в фаворе, его именем даже планету вон назвали, а потом роза ветров изменилась, чувака анафеме предали, а планету девальвировали в никчёмный астероидишко.
Истина иногда проста, но не очевидна
Надо быть последовательным, это ведь основа философии. Когда выходили эти книги, (я говорю про паттерны). Вы не думали что это был этап когда программирование становилось доступнее? Для этого и максимальная абстракция примеров, чтобы понял каждый, автомобиль достаточно хороший пример такого объекта.
И если вы читаете книги, почти в каждом издании и почти на любую тему в конце каждой главы есть примеры для самостоятельной практики, и авторы подталкивают и отмечают что это важно. Делали их?
Вы не думали что это был этап когда программирование становилось доступнее?
Думал, и даже тысячу раз озвучивал свой собственный взгляд на спираль развития ПО, которую я называю «баланс интеллекта и инструментария»:
Сначала программировать могли только бородатые свитероносцы, и только так, что само написание кода выглядело как разговор с потусторонними силами. Сделать ошибку было очень просто, но — зная её цену — ошибок почти не делали.
Выразительные средства развивались, и в начале 90-х появилось сразу несколько языков, которые были рассчитаны на интеллект программистов из 70-х/80-х, но предоставляли гораздо более удобные средства (самый яркий пример — Матц со своим руби, в котором даже модификатор
privateдобавляет лишь конвенцию для читающих код, если надо — вызывай). Сделать ошибку стало сложнее, потому что писали код люди, закаленные на рудниках машинных кодов и в шахтах перфокарт.На простые языки слетелись неофиты, которым удобные средства понравились, но осторожностью и отношением к работе мастодонтов они уже не обладали. Сделать ошибку снова стало проще.
Чтобы бить программистов по рукам придумали типы, тесты, линтеры, форматтеры, чёрта в ступе. Сделать ошибку снова стало сложнее.
Программисты стали понемногу обучаться, развивать когнитивную сложность языков ради ничего, плодить сущности. Сделать ошибку стало проще.
Программистам принесли абстракции и руководства. Сделать ошибку стало сложнее.
Програмисты стали использовать все абстракции из всех руководств, складывая их как овощи в винегрет. Сделать ошибку стало проще.
В Гугл позвали Пайка, и он сделал язык для дебилов (по его же собственному утверждению). Сделать ошибку стало сложнее.
Мы сейчас находимся тут.
При этом, когда в 1986 году вышла первая версия эрланга, на котором я сейчас преимущественно и пишу (в последнее время — больше на эликсире, но это не меняет дела никак), — его авторы устами Джо Армстронга заявили: «разработчики делают и будут продолжать делать ошибки, поэтому нам необходимо: ограничить примитивы языка до необходимого минимума и научиться реагировать на ошибки так, чтобы система оставалась полностью функционирующей». Всё.
А мне кажется что доступность программирования сделал не язык, а бум технологий, который позволил некогда огромную машину не выносить в отдельную комнату, а поставить эту машину на ваш стол или положить ее в карман. А язык уже и эволюционировал следом. Плюс технологии сейчас повсюду, и деньги можно заработать. Вот все и кричат: ООП, полиморфизм, интерфейс, функциональное программирование. Может отсюда собеседование в компанию это полу лотерея, все кричат одно и тоже, а что это значит никто не знает, главное совпасть с "тимлидом" в интерпритации.
Ну, наличие у вас дома на столе компьютера само по себе программистом вас не сделает, чтобы писать в кодах, или даже на ассемблере, — двухнедельных курсов недостаточно.
Доступность персоналок открыла гигантский рынок, чтобы попасть на который нужен был качественный скачок в скорости разработки — а значит, и в инструментарии.
главное совпасть с «тимлидом» в интерпретации
У правильных законов не бывает нескольких разных интерпретаций :) Я об этом и писал, в сущности.
Да, я это уловил по тексту, потому-что для меня вопрос с собеседованием это отдельная боль. Тут возможно проблема на самом деле в том, что ООП и создано для абстракции. Это как-бы абстракция которая позволяет повысить абстракцию с машиной. Вот я говорю про объект, как себе этот объект представляет новичек? Опытный? Продолжающий?. Но что он в себе скрывает на самом деле? Язык становится ближе, можно наверное сказать осизаемее. Не языком формул, а языком - домов, автомобилей, самолетов, подключений к базам данных, организации своего кода и чего угодно что вы видите или можете придумать и перенести на объект. Вот я пишу этот пример, и сам же вижу на сколько это мощный инструмент, я могу взять что-то из мира вокруг себя и перенести это в программу, или могу обслуживать программу этими же методами, но разве это не кайф?)
Это кайф, конечно же. Про это много, долго и вдумчиво говорил Джо Армстронг, автор эрланга (и даже диссер написал, который я иногда перечитываю). Я уже приводил в одном из текстов на той неделе мою любимую цитату:
We don’t have shared memory. I have my memory, you have yours, we have two brains, one each, they are not joined together. To change your memory I send you a message, I talk or wave my arms. You listen, you see, your memory changes, but without asking you a question or observing your response I do not know that you have received my messages. — Joe Armstrong, Concurrency Is Easy
Даже синтаксис эрланга (правда, это авторы попятили из пролога) — целиком позаимствовал пунктуацию из английского языка (запятые, точки с запятой, точки).
Мы не думаем объектами, со свойствами и методами. Мы не думаем: «налью-ка я объект чай (цвет: черный, сорт: «из пятерочки») в объект кружка (цвет: красная, объем: 300мл, ручка: прямая, форма: бокал), используя метод налить у инстанса человека, синглтона „я“». Мы думаем так:
хочется чая → это message от вселенной
«Жена! Налей чаю!» → это message жене
[спустя минуту: таймаут] пойти в кухню → это функция
достать чай, чашку, вскипятить воду, налить → это конечный автомат
готово! → это message себе
пьем
Тут нет объектов. Зато тут есть процессы (я, жена, чайник), сообщения и конечные автоматы (на тех же message).
И мой опыт (30+ лет, 12+ языков) — показывает, что это самая простая, быстрая и в то же время пуленепробиваемая абстракция для мира.
Мы не думаем: «налью-ка я объект чай (цвет: черный, сорт: «из пятерочки») в объект кружка (цвет: красная, объем: 300мл, ручка: прямая, форма: бокал), используя метод налить у инстанса человека, синглтона „я“»
Мы именно так и думаем! Просто за ламинарностью мышления это практически не заметно.
Мне известно всего одно значение слова «ламинарность» и оно тут не очень подходит, так что возражу пальцем в небо: «А есть ли какие-то подтверждения того, что мы думаем именно так?»
А если и есть, то не лучше ли сразу моделировать заламинированное мышление, ну чтобы нам же и проще было бы?
Мне известно всего одно значение слова «ламинарность» и оно тут не очень подходит
Я использовал это значение.
А есть ли какие-то подтверждения того, что мы думаем именно так?
К сожалению или к счастью современная психология находится пока в основном в стадии исследований. Окончательных научных выводов пока что нет. Поэтому, если угодно, считайте это моим имхо.
не лучше ли сразу моделировать заламинированное мышление, ну чтобы нам же и проще было бы?
Я заметил, что у разных людей мышление работает по разному.. Поэтому одного решения и нет. По крайней мере сейчас.
Дак мы программу пишем по сути не для себя, а для машины, то что эта программа доступнее человеку, это очевидный шаг вперёд, как по мне. Некий компромисс
Вы говорили что какой-то человек говорил что надо примитив свести до минимума, но самый минимальный примитив который съест машина это 0 и 1. Что человеку не удобно. Человек который про это говорил не уточнил где начинается эта золотая середина?
Вроде нет. Я могу сказать вместо него: джейсон — это вполне устоявшийся, закаленный в боях и проверенный медными трубами необходимый и достаточный примитив для данных (числа, строки, списки, мапы).
Ммм, называть json примитивом... Если честно не знаю что добавить, только наверное что ожидал какоенибудь рассуждения про строки, но json... так далеко я не смог заглянуть))
Возможно, я неверно понял вопрос. Я отвечал на «каких примитивных типов должно быть достаточно» — и джейсон вроде самая простая отсылка (по поддерживаемым типам): люди хотя бы тут пришли к пониманию, что в 99% задач хватает вот этих.
Я не сам джейсон назвал примитивом; я сказал, что его типы — это то, чего обычно достаточно.
Примитив, это когда 0 и 1 превращаются в строку. (ASCII?). Ну, если для 99% задач, а 1% это консистентность данных, то тут мои полномочия все))
Я потерял нить, но отвечать не перестану!
Для обеспечения консистентности данных не требуются ни сложные типы, ни объекты. Нужен хороший интерфейс инкапсуляции — и лучший, из мне известных — это полная иммутабельность и акторная модель, в которой чужой код в принципе не имеет доступа к чужим данным напрямую. Никогда. Только через интерфейсы.
А как я думаю - консистентность обеспечивают реляционные базы данных
Собственно, это достаточно сложные механизмы, потомучто процесс это сложный, есть хорошая книга которая подробно все описывает и даже их эволюцию
Базы может не быть.
База может быть спроектирована с ошибками.
База не может обеспечивать консистентность в условиях высокой распределенной конкурентности (CAP theorem).
И еще стопиццот «не».
Да, сладко будет пользователям без индексов. Вам с вашим опытом виднее конечно, но мне кажется продукт без реляционной базы данных вообще не должно быть в общем доступе. Надо наверное ещё опыт подтянуть.
Не любой продукт — торчит лицом в пользователя. Брокеры сообщений, фреймворки, да даже компиляторы языков — это всё продукты. И база им не нужна.
Двум из трёх микросервисов — база не нужна.
А хороший код и консистентность — им всем всё еще нужны.
2 из 3 микросервисов будут парсить json (консинстентнось данных которого только программисту известна) пока третий отдаст ответ, будет уверен в полноте данных (это на себя берет база данных) и будет отдыхать.
Да не предлагал я парсить джейсон!
Я сказал, что типы данных, определенные в джейсоне, — это необходимый и достаточный набор типов данных. Джейсон тут вообще ни при чем.
Микросервис, который получает, преобразует и кэширует данные из посторонего источника, — не можут быть уверен в полноте данных и ему не нужна база.
Мы не думаем объектами, со свойствами и методами.
Говорите за себя. А я, вот, например, этими абстракциями думать обучен, а потому - думаю. Правда, когда мне надо что-то написать на SQL, я думаю другими абстракциями.
Я не про программирование, я про реальную жизнь. Или вас обучили думать абстракциями в два года?
Способность к абстрактному мышлению - умение строить абстракции (ну, или пользоваться понятиями - в данном случае это весьма близко) - это одна из базовых способностей человеческого разума, которая, собственно, дает ему способность к познанию.
Но это уже - по ведомству гносеологии, то есть философии.
We don’t have shared memory. I have my memory, you have yours, we have two brains, one each, they are not joined together.
А потом мы с вами садимя за мессенджер, расшариваем друг другу экран, и работаем с одним эраном вдвоем. Это я - к тому, что аналогии имеют ограниченное применение.
Перечитайте цитату, пожалуйста.
Вы можете расшарить хоть весь мир вокруг, но что я думаю об этом куске кода на расщаренном экране — вам неизвестно, пока я эксплицитно не отправлю вам сообщение.
Аналогии, безусловно, имеют ограниченное применение, но конкретно тут всё чисто: читать напрямую мою память вы не сможете, хоть паяльник мне в ухо воткните.
чтобы писать в кодах, или даже на ассемблере, — двухнедельных курсов недостаточно.
Я не помню, сколько времени я затратил изначально, когда я начал писать в кодах (это было на программируемом калькуляторе-переростке под названием ЕМНИМ Электроника ВМ15, собственно, ни на чем, кроме кодов, на нем писать было невозможно) - но, по ощущениям, не две недели. Скорее всего - просто разбирался по ходу дела. Но вот курсов я точно не проходил, и вообще, было это в пределах одного семестра.
У правильных законов не бывает нескольких разных интерпретаций :)
А как насчёт квантовой механики? Там неправильные законы, и они дают неправильный мёд?
Технически, у квантовых законов есть общая интерпретация, и пока она не была найдена, физики не успокаивались.
Технически, у квантовых законов есть общая интерпретация,
По крайней мере, Википедия с вами не согласна:
ММИ[Многомировая интерпртация] является одной из многих многомировых гипотез в физике и философии. На сегодняшний день она является одной из ведущих интерпретаций, наряду с копенгагенской интерпретацией и интерпретацией согласованных хронологий.
Ну, а если ближе к жизни, то, к примеру, толкование законов государства настолько далеко от однозначности, что есть специальная профессия для их толкования, кстати - неплохо оплачиваемая.
Думал, и даже тысячу раз озвучивал свой собственный взгляд на спираль развития ПО
Ну да, ход развития часто изображают в виде спирали. Но, обратите внимание - каждый виток повзоляет включить в общественно-полезную деятельность по программированию всё более широкий круг участников процесса. Так что, это не просто ход развития - это именно прогресс.
Erlang это и есть ООП по его первоначальному замыслу от Аллана Кея
Только после диверсии Страустрапа этот замысел стали называть акторная модель
По моему цель чтения книги извлечь максимально возможный опыт и полностью его запомнить, таким образом чтобы ты смог этот опыт применить.
Например, знание квантовой механики большинству не нужно. Но хобба в компании зашёл разговор об аниме, а ты раз и поддержал разговор.
С моей точки зрения суть паттернов в том чтобы говорить на одном языке, а не объяснять по кругу одно и тоже.
Вот, если бы я не знал что такое паттерн прокси, я бы не смог сходу понять о чем говорится в недавней статье о проблеме N+1 и Hibernate Proxy.
А так я знаю паттерн, знаю его подводные камни.
А поводу возведения в религию, я могу ответить так: если ты нападаешь, то человек рефлекторно защищается, даже, если он не придерживается такого мнения. Этот прием часто используют в дебатах, чтобы максимально унизить оппонента по итогу.
Но это мое мнение и я могу быть не прав.
суть паттернов в том чтобы говорить на одном языке
Они очень плохо справляются с этим.
Я даже не понимаю о какой проблеме речь. Я просто не задумываюсь о них, потому что это не большие проблемы.
Давай позовём говоруна.
Вот говорун сформулировал шаблоны проблем:
Проблемы создания/получения чего-либо:
Абстрактная фабрика: "Нужны совместимые комплекты?"
Строитель: "Сложная сборка по шагам?"
Фабричный метод: "Кто решает, что именно делать/выбрать?"
Прототип: "Дорого создавать? Копируй!"
Одиночка: "Нужен строго один?" (Экземпляр чего-либо: сервис, ресурс, состояние)
Проблемы структуры/взаимосвязи:
Адаптер: "Как соединить несовместимое/чужое?"
Мост: "Отделить суть от деталей реализации?"
Компоновщик: "Структура (дерево) как единое целое?"
Декоратор: "Навесить доп. возможности/обертки?"
Фасад: "Упростить доступ к сложному?"
Приспособленец: "Дубли? Экономь ресурсы!"
Заместитель: "Нужен контроль доступа / отложенное действие?"
Проблемы поведения/взаимодействия/процессов:
Цепочка обязанностей: "Кто обработает? Передай дальше!"
Команда: "Действие как отдельная сущность?" (Для очереди, отмены...)
Интерпретатор: "Задать и выполнить свои правила?" (Мини-язык)
Итератор: "Как перебрать всё по порядку?"
Посредник: "Слишком много связей? Нужен центр!"
Хранитель: "Нужен снимок состояния (для отката)?"
Наблюдатель: "Как сообщить всем об изменениях?"
Состояние: "Разное поведение = разное состояние?"
Стратегия: "Как подменить способ решения?"
Шаблонный метод: "Общий план, детали - разные?"
Посетитель: "Новое действие для старых данных?"
https://LLMshare.syntxai.net/02f62feb-8cbb-3947-53b8915f
Болтун всё-таки молодец:
https://LLMshare.syntxai.net/ed688a6f-341b-c7af-83c2d8d3
Болтун ни разу не предложил ООП в качестве решения, потому что они сложнее. Можно ещё посмотреть как ООП шаблоны усложняют компоновку и провоцируют переусложнение.
если бы я не знал что такое паттерн прокси, я бы не смог сходу понять о чем говорится в недавней статье о проблеме N+1 и Hibernate Proxy
Не знаю, о какой статье идет речь, но я представления не имею, что такое «паттерн прокси» — и готов ставить сто к одному, что я пойму, о чем там речь.
А что Гослинг?
Java это такая же ООП ересь как и c++
Борьба функциональных программистов (по моим ощущениям это те кто считают что программа и так может выдать нужный результат, зачем все эти заморочки в виде паттернов?) против адептов ООП (надеюсь здесь есть такие) в самом разгаре. Но почему надо говорить что с ООП что-то не так? Любая книга с архитектурными паттернами содержит плюс минус одни и те же решения, о чем это может говорить? Я думаю что это некие бест практис так сказать, и применить их или нет, в каком виде и количестве выбор только программиста. Вот и складывается ощущения что ООП даёт очень мощный инструмент для программиста, а программист его боится.
складывается ощущения что ООП даёт очень мощный инструмент для программиста
Не «складывается ощущение», а «навязано религией». Об этом и текст.
Sidenote: Я никогда не считал и не называл себя функциональным программистом (только — многофункциональным, но это про другое), ООП меня кормило верой и правдой более 15 лет, бояться в ООП нечего, оно тупое, как полено.
Не знаю про одно ли ООП мы говорим, в тексте почему-то имеется ввиду что книги по Computer Science содержат паттерны. Но книги про фундаментальные технологии в информатике больше про графы, устройство памяти и подобное, но не как не про паттерны
Какая книга из вышедших в последние 10 лет про устройство памяти вам запомнилась больше всего?
Гид по Computer Science не очень подробная, но хорошо отражает тематику книг по фундаментальным подходам в информатике. Дает начальные знания этой глубокой, большой и сложной науки. Как по мне самое то для первого погружения и минимального представления.
навязано религией
Догмой. Которая пошла от GUI, ORM, web с активным использованием состояния. Лет 30 назад просто по другому не умели. А сейчас забыли отменить догму.
бояться в ООП нечего, оно тупое, как полено
Только подавляющее большинство (виденного мной, по крайней мере) ООП-кода оверинжинирнуто, и при всём этом его тяжело поддерживать (потому что оно оверинжинирнуто «не туда», и с направлением развития или эволюции требований не угадали, а рефакторить его больно). Возможно, именно поэтому ООП вас
кормило верой и правдой более 15 лет
точно так же, как меня C++ кормил верой и правдой много лет, и может кормить ещё, если я начну снова ненавидеть себя достаточно сильно, чтобы в него окунуться. Отвратительный, переусложнённый язык (хотя база тоже тупая как полено), на котором практически невозможно писать надёжный код и который совсем невозможно знать, за счёт чего и кормит. Жоп секурити, все дела.
Ну да. Именно так.
подавляющее большинство (виденного мной, по крайней мере) ООП-кода оверинжинирнуто, и при всём этом его тяжело поддерживать (потому что оно оверинжинирнуто «не туда»
Да. ООП провоцирует оверинжиниринг. Причин тут много, всё не расскажу. Видимо, место проклятое.
Вот кусочек из ревью когда ООП вариант был переусложненный. Правда, без примера, а то напарник обидится если прочитает.
Когда мы начинаем строго следовать принципам ООП (особенно принципу единственной ответственности), получается:
Разделили обработку (сохранение) от печати (генерация)
Получили отдельные классы для каждой функции
Усложнилась инъекция зависимостей
Пришлось вводить фабрики для управления созданием объектов
И в результате простая задача превратилась в сложную систему классов.
ООП действительно часто провоцирует на избыточную сложность, особенно когда принципы применяются слишком буквально:
Проблема с SRP (принцип единственной ответственности): Стремясь дать каждому классу одну ответственность, мы создаем множество крошечных классов, связи между которыми сами становятся проблемой.
Абстракции ради абстракций: Создание интерфейсов и базовых классов, которые на практике имеют только одну реализацию.
Шаблоны проектирования не по назначению: Применение фабрик, строителей и других паттернов там, где простого метода было бы достаточно.
DI-контейнеры усложняют систему: Уровни абстракции для инъекции зависимостей иногда превращаются в самостоятельную проблему. Здесь пришлось использовать фабрики
Порочный круг усложнения в ООП
Проблема компоновки данных и поведения:
ООП жестко связывает состояние и поведение внутри объектов
Когда нужно разделить ответственность, появляются новые классы
Чем больше классов, тем сложнее связи между ними
Борьба со сложностью порождает ещё большую сложность:
Видя усложнение, мы добавляем абстракции (интерфейсы, базовые классы)
Затем нужны механизмы для создания конкретных реализаций → фабрики
Фабрики становятся сложными → появляются фабрики фабрик
Возникают трудности с тестированием → мокинг, DI-контейнеры и т.д.
Шаблоны проектирования как лекарство, становящееся ядом:
Шаблоны помогают решать типовые проблемы архитектуры
Но шаблоны сами по себе несут концептуальную сложность
Неопытные разработчики применяют их "на всякий случай"
В результате простая задача обрастает десятками классов
Принцип единственность ответственности к ООП не имеет ни какого отношения. Как и переусложнение которое навязано не «Паттернами проектирования», а «Чистым кодом». Возьмем для пример Буча: “приципе ООД и проектирования» -если не ошибаюсь, там нет ни слова ни про инверсию зависимостей и ни про единственность ответственности. ООП это про полиморфизм и наследование.
Конечно! Пишите без инверсии! Бхахаха!
Результат будет ещё хуже
Но ведь полиморфизм придумали задолго до ООП, а наследование — всегда только мешает.
а наследование — всегда только мешает.
Подозреваю, что тут, как в случае Альфа и кошек, вы просто не умеете его готовить. Вот мне, почему-то, не мешает.
Но про это надо написать статью, а я всё никак не соберусь.
Так что, придётся мне эту интересную тему отложить.
вы просто не умеете его готовить
А может быть, умею, но не только его, но еще и несколько других парадигм, на профессиональном уровне, а не поиграться на выходных, — и это мой взвешенный выбор?
Если вы уточните "наследование мне — всегда только мешает.", возражений у меня не будет. Но вы тут пишете так, как будто за всех - а потому у меня возникает возражение.
Наследование мне — и подавляющему большинству людей, с которыми мне довелось быть знакомым, и которые в совершенстве владели минимум тремя парадигмами — всегда только мешает.
Ребятам, придумавшим котлин, го и раст (с ними я не знаком), — тоже, вроде.
Ну, настоящие программисты тоже не использовали наследование - потому что в Фортране его не было. И что? Важно ли это для отрасли производства ПО?
Однако жалобы насчет наследования, таки да, очень распространены и среди другой - реально массовой и важной для отрасли - категории профессионалов - операторов фреймворков. Так что наследование, наверное , соглашусь, на роль массово применяемой концепции подходит плохо: слишком сложно им пользоваться рядовому работнику клавиатуры и экрана.
Да что там сложного-то? В разработке вообще нет ничего действительно сложного (кроме именования переменных и инвалидации кэша).
Крайне субъективное мнение, обсуждать его рационально невозможно. Но оно таки встречается и нередко (см. последний комментарий к статье).
PS Посмотрел я и прочие ваши ответы. Они примерно столь же крайне субъективны и не имеют объективного содеражания, пригодного для рациональной дискуссии. Обсуждать там нечего - можно только демонстрировать свое личное согласие/неслогласие, с аргументами от художника ("я художник, я так вижу").
PPS А про наследование или ООП вообще стоит или писать статью, или оставить его в покое: иначе будет ниачом. Пока что выбираю второе.
А насколько взвешенное мнение вы ожидаете услышать, когда в ответ на «ну вот смотрите, я расписал проблемы, а еще три новых языка от него отказались», — заявляете, что «это на самом деле слишком сложно, чтобы дурачки поняли»?
Вроде, Эйнштейну приписывают фразу: «Если вы не можете объяснить пятилетнему ребенку свою мысль, значит, вы сами ее не очень то понимаете». Я с ним согласен. Переусложнение ради того, чтобы только вы смогли разобраться в коде, — это же фу, вы же не станете с этим спорить, наверное? Ну вот так и тут: можно навертеть триста паттернов и пятьсот способов запутать несчастного читателя кода поверх, но если есть возможность сделать проще, короче, понятнее и быстрее — наверное, переусложнение было лишним.
Не существует задач, которые наследованием решаются короче и понятнее, в сравнении с, для примера, акторной моделью. Вот и всё.
Давайте я тут главную мысль подчеркну: вся эта теория - и ваша любимая, и "паттерны", которые вы не любите, тоже - имеют меньшую важность, чем практика. И проиллюстрирую:
а еще три новых языка от него отказались
А ещё один (TypeScript называется), тоже новый, но имеющий то преимущество, что он для масс, для простых операторов фрейворков, формошлепов и крудостроителей - не отказался. А у него, небось, круг использующих пошире будет, не?.
Не существует задач, которые наследованием решаются короче и понятнее, в сравнении с, для примера, акторной моделью. Вот и всё.
Ничего не знаю и знать не хочу про "акторную модель". Я вообще не люблю теорию. Я в отношении к теории согласен с настоящими программистами: "Настоящим программистам для выполнения работы не
нужны абстрактные концепции". Однако я нередко нахожу и использую разные приемы программирования, а потом иногда выясняю, что они имеют у теоретиков красивые названия (те же "паттерны", к примеру). Так что я, возможно, даже и использую эту вашу "акторную модель", но не суть.
Так вот, сказать считаю нужным другое: все эти замечательные в теории средства имеют свою цену освоения, которую в массовой практике платить избегают. А потому, например, при всех достоинствах декларативного программирования на SQL, широкое распространение получили средства ORM, которые избавляют рядовых крудошлепов от необходимости не только знать ещё и SQL (это ещё полбеды), но и думать ещё и в декларативной парадигме (а это действительно сложно) - несмотря на то, что эти средства нередко траслируют запросы в далеко не оптимальный SQL.
Так что, средства, позволяющие хорошо обученным людям решать задачи проще и понятнее (для них), но сложные в освоении, имеют меньший шанс быть использованыв массовой практике, чем что-то просток вроде правил типа "Четыре - хорошо, две - плохо". Даже если потом окажется, что "две - лучше", как это произошло к примеру с практикой комментирования кода.
Короче, ваши эстетические предпочтения понятны и во многом обоснованы, но для отрасли массового программирования они непригодны.
Но ситуация, в которой сущность меняется изнутри — исчезающе редка. Кроме барона Мюнхгаузена, тащившего себя за волосы из болота, — так навскидку и не припомнить иной пример.
А как же стейт-машины? Агрегаторы данных из других сервисов где нужно несколько шагов? Всякие сервисы подключения к потоку данных и базам данных? И это я навскидку вспомнил.
А как же стейт-машины?
В смысле — как? Даже если речь о детерминированных конечных автоматах — само оно из состояния «старт» не выйдет, нужен пинок. В недетерминированных появляются ивенты из внешнего мира.
FSM — вообще шаблонный пример того, что на классах и объектах правильно не реализуется вообще, а в условном ФП или, лучше, акторной модели — на коленке в три строчки.
Агрегаторы данных из других сервисов где нужно несколько шагов?
Что с ними? Это та же стейт-машина.
Всякие сервисы подключения к потоку данных и базам данных?
Вообще не понял, при чем тут это. Сервис подключения к потоку данных не может быть инстансом класса по очень многим причинам.
Сервис подключения к потоку данных не может быть инстансом класса по очень многим причинам.
А если я хочу два подключения? Возможно одинаковых, а может и с разными параметрами. И я уже и не знаю сколько лет использую для этого класс со стейтом подключения, но чаще либу, в которой есть методы, в том числе для понимания текущего состояния подключения. Почему вы решили что инстанс класса не может?
на коленке в три строчки.
Так в ООП не сложнее - в поле класса текущий стейт хранится, который может быть енумом. И поехали. Почему это должно быть сложно?
Я конечно тоже не любитель абстрактных фабрик, но никто же не заставляет их использовать, если это не корпоративная джава и оплата за количество строк.
в ООП не сложнее
Просто бешеное количество возможностей прострелить себе ногу
А если я хочу два подключения?
Давайте сделаем маленький шажок назад. С чем вы (лично вы) сравниваете? В каких еще парадигмах вы (вы лично) пробовали реализовывать подключение к потоку данных? Я сравниваю с акторной моделью, ФП на хаскеле и ФП на идрисе с завтипами. Хуже всего справляется (по моему мнению) — ФП на хаскеле, потом ООП, чистые победители — акторная модель и ФП с завтипами (с совершенно разными, буквально ортогональными, решениями).
в поле класса текущий стейт хранится
Ну ок, соединение порвалось. Надо как-то отреагировать, наверное. Как? Нагородить спагетти с ифами, которые будут имитировать стейт-машину? А как это тестировать? А что, если одна библиотека для работы с потоком данных — бросает в таком случае эксепшн, а вторая — просто возвращает ошибку? А как мы убедимся, что не потерялось сообщение между крашем и переподсоединением? Или вот: сообщение вы прочитали и обработали, а ack не прошел — что делать? И так далее.
Это превращается в холивар за парадигмы 🙂 Я, пожалуй, сойду на этой остановке. Просто знайте что есть другие способы и они тоже работают и работают хорошо. Главное в крайности не входить - абстрактные фабрики и паттерны ради паттернов мне тоже не нравятся, но есть и нормальные, здоровые подходы и с ними живется прекрасно.
Нет, это не превращалось ни в какой холивар. Я всего-навсего спросил, как человек с более, чем 15-летним опытом работы в ООП-перадигме, на основе чего вы делаете вывод, что «все прекрасно работает».
с ними живется прекрасно
Пока одно непрочитанное из потока сообщение (или прочитанное дважды) — не может обанкротить весь бизнес — охотно верю.
Помоему для этого созданы AMQP-брокеры
Для чего именно? Как вам брокер поможет в ситуации «сообщение прочитано, обработано, и тут инстанс класса почему-то (пусть из-за ошибки разработчика) упал до того, как успел акнуть»?
И какой именно AMQP брокер, кроме раббита (по случайному стечению остоятельств, написанный как раз на эрланге), вы имеете в виду?
Я как-то писал самодельный брокер сообщений.
Полно возможностей прострелить себе ногу
Вообще-то - подтверждение от обработчика не решает проблему, как вы правильно отметили обработчик может упасть после посылки подтверждения. Задача гарантированной доставки сообщений не имеет решения -задача византийских генералов.
И что должны делать в такой же ситуации функциональные языки? Продолжить магически корректно работать на силе НЕ СЕКТАНТСТВА своих фанбоев?
Не видел здоровых, видел больных...
Вы можете отслеживать подключение с помощью наблюдателя
О, уже появилась абсолютно лишняя сущность. Ну ладно, в современных машинах железа много, не проблема.
Ну отследили. Дальше-то что?
Zero Cost Abstractions, Inlining и прочие оптимизации уже давно существуют. И с этими техниками многие паттерны и другие виды абстраций из мира ООП если не бесплатные, то около того. Зато все очень человекопонятно и приятно при работе.
Я не знаю, как программист на функциональных языках вообще имеет право говорить про эффективность и производительность кода, когда функциональные языки это апофеоз неэффективности в угоду "красоты" по математике и Кнуту, совершенно никому не нужных для решения реальных задач.
реальных задач
Реальные задачи не ограничиваются джейсоноукладкой. Чтобы вы могли клепать свой круд, не приходя в сознание, требуются библиотеки, фреймворки, компиляторы, наконец.
И если «программист на функциональных языках» — про меня, то это выстрел в молоко. Я одинаково свободно пишу почти на всех более-менее распространенных языках (кроме го, потому что мне даже внешний вид кода на го — омерзителен).
"Инкапсуляция? — Да нет, инкапсуляция достигается совсем другими способами, если вы не хотите завтра получить прямо в дышло вашей инкапсуляции — рефлексию и аспекты."
Недавно рефлексировал на PHP, и причём тут инкапсуляция?)
Увы, в моем системном программировании круда я не обнаружил. А сейчас еще и драйвера переезжают на Rust.
Так что, похоже, последние причины где-то зачем-то использовать функциональные языки пропали. Пришел Rust и весь этот цирк с "гыгыгы математически корректные программы и безопасный параллелизм" можно заканчивать.
А еще знаете чего я не замечаю в системном программировании? Функциональных языков программирования. Ой.
Не обнаружено ОС, драйверов, спутников в космосе, роверов на Марсе под использованием ФП.
Видимо это не достаточно реальные проекты для совершенно точно не культа ФП адептов. И что-то не помогает реальная корректность программ, "эффективный параллелизм". И почему-то идиоты разрабатывающие Linux, Windows, космические программы, прошивки для самолетов продолжают буксовать с C, а для будущего выбрали Rust. Хм, просчитались что-ли все?
У вас часом языков не больше чем реальных круных проектов написанных на них?
К сожалению для вас, попытка взятия на понт через жсончик и круд чего-то не удалась. Жаль.
А обычно видимо работает? Ну когда оппонент джун фронтендер, там ему и про отвратительность паттернов можно залить, и про то какие все принципы вроде SOLID плохие.
К сожалению для вас […]
Да мне вообще насрать, почему к сожалению-то? Это же хабр, а не серьезный технический ресурс какой.
Ну если это все что ты сумел выдать после вброса про круд и жсончик...
Вон, в ядре Линукс воюют против Rust потому что кодовая база... перестала грепаться.
Я понимаю, не все программисты той эпохи сумели адаптироваться к современным реалиям. Кому-то нужен grep вместо IDE и LSP. А кому-то нужно рассказывать сказки про крутость и элитарность ФП чтоб казаться нитакусиком на закате своих дней, чтоб было хоть чем-то пофлексить перед молодым поколением.
А напомните, раст — это то самое поделие, на котором авторы не смогли написать проект, ради которого раст и был вообще придуман?
Язык без экспонируемого стандартными средствами AST, это оно, да?
И это, где я рассказывал про крутость и элитарность ФП-то?
Можете продолжать передергивать сколько хотите. Реальные вопросы и претензии игнорировать горазд любой. Жалкое зрелище, сопоставимое с областью применимости ФП в реальном мире. Ну что ж, я тоже так могу:
Что там с Erlang'ом в Discord? Ребята побаловались по началу, как дело запахло реальными нагрузками - сразу все бросили и переписали на Rust? Ой. Неловко то как.
Ой, там-сям Scala выкидывается в пользу Kotlin? Ой.
Да что ж такое то! Надо громче кричать про плохой ООП, жуткие паттерны и вредные принципы! Не дорабатываете, так секта ваша и скончаться может скоро.
Да чего вы к ФП-то привязались? Где я лично пропагандировал ФП, можно узнать?
Что там с Erlang'ом в Discord? Ребята побаловались по началу, как дело запахло реальными нагрузками - сразу все бросили и переписали на Rust?
Чё? Они никогда ничего не писали на эрланге, дискорд был с самого начала и остается написан на эликсире (который да, компилируется в тот же BEAM, что и эрланг). На эрланге написан WhatsApp, о планах что-то куда-то переписать мне лично неизвестно.
Scala выкидывается в пользу Kotlin?
Akka, Hadoop и Spark — три самых используемых во внебанковской индустрии продукта — всё еще на скале. Подозреваю, что у вас опять найдется пример какой-то исчезающе-малой ниши вне крудов, где котлин побеждает.
А самое главное, неясно, где именно я передергиваю. Я что-то пропустил и серво все-таки смогли дописать?
Я что-то пропустил и серво все-таки смогли дописать?
На гитхабе забанили? https://github.com/servo/servo
А самое главное, неясно, где именно я передергиваю.
Ну на вопрос что ФП должны делать в ситуации когда клиент брокера там как-то помер я ответа не получил.
В ответ на провокационный вброс про круд и жсон я задал вопрос где ФП в области системного программирования и в эмбедде, и закономерно ответа не получил. А все потому что на самом деле это ФП как раз таки штука для потокового перекладывания жсона, а не для решения реальных задач, воно как.
Вопросы реальной производительности функциональных языков я даже затрагивать не стал.
Подозреваю, что у вас опять найдется пример какой-то исчезающе-малой ниши вне крудов, где котлин побеждает.
Оставлю это занятие вам, т.к. составить список из крупных ФП проектов не сильно сложно, ведь он состоит всего из около 10 пунктов. При этом самих "метовых" функционально ориентированных языков там сколько? 15?
Servo is a prototype web browser engine — https://github.com/servo/servo
Ой, я не знал, что серво задумывался как прототип браузерного движка, я думал, они прям целый работающий движок хотели написать.
Ну на вопрос что ФП должны делать в ситуации когда клиент брокера там как-то помер я ответа не получил.
Вы разговаривать не умеете, странно, что вы вообще хоть когда-то какие-то ответы получаете. Но мой вопрос по-прежнему в силе: почему вы меня об этом спрашиваете? Кто вам сказал, что я — адепт ФП? Чего вы именно к ФП-то прицепились?
составить список из крупных ФП проектов не сильно сложно
Зато список крупных проектов на расте составить очень легко:
один непринятый прототип браузерного движка
пока всё
Бывает.
А это должен быть синхронный наблюдатель, который блокирует распространение набюдаемых событий до тех пор, пока все наблюдатели не прокрутятся (что паршиво с точки зрения не только производительности, но и корректности, если наблюдателям позволено самим порождать события) или асинхронный наблюдатель, который получит свои события когда-нибудь потом и в этой связи будет только лишь eventually consistent с наблюдаемой жизнью, что очень усложнает корректную реализацию таких наблюдателей?
Весь мой жизненный опыт показывает, что всё должно быть по умолчанию асинхронно, пока нет четких и внятных требований обратного, да и то.
Вся наша жизнь — асинхронна. Поезд не будет ждать, пока вы допьёте кофе, а кулак, летящий вам (мне) в репу — не приостановить синхронным выставлением идеального блока.
Все без исключения реакции в окружающем нас мире — асинхронные, даже тогда, когда кажется, что они синхронные (ситуация «я не смогу купить себе булочку, пока жена не даст мне денег» — тоже асинхронная, потому что наступит таймаут, меня накормит сердобольный прохожий, или я помру от истощения).
Поэтому надо просто научиться жить с этой eventual consistency. Самое удивительное, что это не так сложно. Когда я писал свою реализацию FSM, я тоже сначала сделал переходы синхронными. А потом подумал: какого черта вообще? И теперь там всё асинхронно. Нужно дождаться выполнения? — Озаботься обратной связью. В 99% случаев ничего дожидаться не нужно.
Поезд как раз синхронен. Он уезжает по расписанию. Был бы асинхронным, уезжал бы, когда ему вздумается, и присылал бы нотификацию, что подумывает отъехать.
С eventual consistency жить можно, но сложно. Кажется, этому не очень-то учат.
Сам постоянно не устаю говорить, что институтская модель сети, когда можно взять откуда-то адрес, куда-то сделать connect, и дальше всё, получаешь надежный в норме канал, с которым можно делать что-то полезное, в корне не верна.
В реальных программах приходится учитывать, что адрес может в любой момент измениться, сетевой интерфейс может в любой момент добавиться или отключиться, и это надо явно отслеживать, потому, что автоматической реакции на эти события для реальной жизни часто не хватает и т.д. и т.п. В общем, сложная такая жизнь с асихнронным изменением конфигурации, которая в норме вещей, и это надо понимать и учитывать.
Абсолютно согласен. Наверное, меня именно это больше всего расстраивает во всех этих шаблонах, паттернах, хороших практиках.
Они все подразумевают идеальный мир вокруг. Идеального программиста, не допускающего ошибок в коде и идеальную среду выполнения. Код, написанный сообразно хорошим практикам, — не должен падать в корку и уничтожать всё живое вокруг как ядерным взрывом, если что-то пошло́ не так. Вот о чем надо было писать (я напишу, спасибо огромное за кристаллизацию этой мысли).
Поезд как раз синхронен. Он уезжает по расписанию.
Это не синхронность per se. В синхронном мире он должен был бы отправить вам сообщение: «собираюсь отъехать», и ждать вас, или таймаута. Синхронность подразумевает двух участников процесса.
Вам прям расшифровывать надо
https://LLMshare.syntxai.net/87bfd262-5b1d-6d28-7eacbc0f
https://LLMshare.syntxai.net/e33b95be-4727-692e-9bce26c8
https://LLMshare.syntxai.net/83d6dfb1-db39-a22e-293034c5
.
Вот примерная расстановка для задачи сетевого сервиса обработки заказов (запросов?), учитывая баланс безопасности, производительности, сложности разработки и возможностей конкурентной обработки:
🥇 1-е место (разделили):
Rust:
Плюсы: Лучшее сочетание безопасности (память, потоки, ресурсы, частично размеры через const generics) и производительности. Отличная современная асинхронность. Предотвращает огромный класс ошибок на этапе компиляции.
Минусы: Более высокий порог входа, чем у ООП или Акторов.
Акторная модель (Erlang/Elixir):
Плюсы: "Король" конкурентности, отказоустойчивости и распределенности из коробки. Относительно простая модель для рассуждения о конкурентных процессах.
Минусы: Меньше статических гарантий типов (особенно Erlang), что может вести к ошибкам в рантайме. Меньшая сырая производительность CPU по сравнению с
Ну, у меня есть ответы - причем, в той самой парадигме ООП.
Ну ок, соединение порвалось. Надо как-то отреагировать, наверное. Как? Нагородить спагетти с ифами, которые будут имитировать стейт-машину? А как это тестировать?
Зачем спагетти? Создаем и используем таблицу перехода между состояниями. Даже на Fortran IV, в котором много чего не было, это сделать было можно: там был Assigned GOTO. Тестировать это - как и любую реализацию машины состояний.
А что, если одна библиотека для работы с потоком данных — бросает в таком случае эксепшн, а вторая — просто возвращает ошибку?
Использовать шаблон Стратегия. Или - Шаблонный метод.
А как мы убедимся, что не потерялось сообщение между крашем и переподсоединением? Или вот: сообщение вы прочитали и обработали, а ack не прошел — что делать? И так далее.
В общем случае никто ничего сделать не может (см.
Задача двух генералов. ). В конкретных - есть разные приемы, сначала их выдумывают умные люди, потом они становятся частью программистского фольклора, и, наконец, они попадают в Computer Science.
И так далее.
Да, и так далее. Никакая Computer Science, никакие шаблоны, никакой чистый код в общем случае не заменят интеллект(INT) и мудрость(WIS). Но принятию адекватного решения в конкретном случае они таки могут поспособствовать. Особенно - тем, у кого собственного ума и опыта не хватает. Чем оно и ценно.
Посему ваш нигилизм не разделяю.
Создаем и используем таблицу перехода между состояниями.
Недетерминированный конечный автомат невозможно построить на ООП без потери математического доказательства его консистентности.
Использовать шаблон Стратегия. Или — Шаблонный метод.
2×2=4. Или 3. Или 5.
принятию адекватного решения в конкретном случае они таки могут поспособствовать
Могут. А могут — наоборот.
Недетерминированный конечный автомат
При чём здесь вообще недетерминированность КА, особенно с учётом того, что для любого недетерминированного можно составить аналогичный детерминированный?
невозможно построить на ООП без потери математического доказательства его консистентности.
Как известно, любая система, обладающая полнотой по Тьюрингу не имеет логических преимуществ перед другой, так как может вычислить любой алгоритм.
Вы путаете «вычисление» и «запрет на вычисление». А еще вы путаете идеальный мир и реальный.
Вот простой пример: вы доказали на идрисе некое утверждение (лемму). Потом вам коллега напомнил, что идрис до сих пор нельзя втащить в прод, и, судя по знакам первой и второй производных энтузиазма его разработчиков, — при нашей жизни этого не случится. И вы переписали код на джаве (плюсах, шарпе, го, эрланге). Потеряли ли вы при этом формальное доказательство корректности? — Разумеется. Гарантии, что ваш код не отыквится (все функции тотальны, например) — растворились.
Не, существует ненулевая вероятность, что вы все сделали правильно, и доказывали лемму не зря (я так сам делаю), но формального доказательства больше нет. Точно так же рефлексия, аспекты и кривые руки программиста — девальвируют любую имплементацию FSM на джаве.
Ей-богу, я в результате напишу текст, объясняющий на пальцах, что не так с конечными автоматами в ООП (и почему инкапсуляция в ООП в общем случае не работает).
Вы путаете «вычисление» и «запрет на вычисление». А еще вы путаете идеальный мир и реальный.
Безосновательное утверждение.
Ей-богу, я в результате напишу текст, объясняющий на пальцах, что не так с конечными автоматами в ООП (и почему инкапсуляция в ООП в общем случае не работает).
С нетерпением жду
Безосновательное утверждение.
Я — король безосновательных утверждений, но здесь оно обосновано :)
любая система, обладающая полнотой по Тьюрингу не имеет логических преимуществ перед другой, так как может вычислить любой алгоритм
① из «каждая селедка — рыба» никак не следует, что «каждая рыба — селедка». Вычислить — да, а запретить вычислять — нет. Многие абстракции, включая, но не ограничиваясь конечными автоматами, — требуют запретов, ограничений и прочих кастраций степеней свободы, про что Тьюринг ничего не говорил.
② полнота по Тьюрингу не гарантирует отсутствие ошибок разработчика, которые существуют в реальном мире, в отличие от идеального.
из «каждая селедка — рыба» никак не следует, что «каждая рыба — селедка». Вычислить — да, а запретить вычислять — нет
Если запрет вычисления можно формализовать в виде алгоритма, то любая полная по тьюрингу система может его реализовать. Так что селёдка годится только для морочения ей головы, не более.
полнота по Тьюрингу не гарантирует отсутствие ошибок разработчика, которые существуют в реальном мире, в отличие от идеального.
Как и отказ от ООП не гарантирует отсутствие ошибок
Как известно, любая система, обладающая полнотой по Тьюрингу не имеет логических преимуществ перед другой, так как может вычислить любой алгоритм.
«Логические преимущества» у вас не определены достаточно однозначно.
О разных системах можно рассуждать с разной. Например, C++, и язык ассемблера тьюринг-полны, но где процесс сборки кода в бинарник выявляет больше ошибок до запуска?
Как известно, любая система, обладающая полнотой по Тьюрингу
Вы таки знаете, что реальные компьютеры не обладают полнотой по Тьюрингу?
А вообще это напоминает старую шутку «с какой скоростью должен бежать кот, чтобы не слышать дребезжания привязанной к хвосту банки?». Вы же помните ответ?
Вы таки знаете, что реальные компьютеры не обладают полнотой по Тьюрингу?
Мы вроде о языках и парадигмах рассуждаем. К чему эти ограничения реального мира?
К тому, что конечную пользу приносит практика в рамках реального мира. И если теория этот реальный мир не учитывает, то грош цена такой теории.
К тому, что конечную пользу приносит практика в рамках реального мир
Какие языки, какие парадигмы, когда конечность памяти у реальных компьютеров, которая формально лишает их полноты по Тьюрингу конечно делает неприменимыми любые логические выводы в этой области.
Всё пропало, клиент уезжает, гипс снимают (с)
с какой скоростью должен бежать кот, чтобы не слышать дребезжания привязанной к хвосту банки?
Сразу вспомнился экзамен по измерению высоты пизанской башни из «Физики шутят» (нормальную ссылку найти не смог — вот весь текст, и вот точная копипаста).
Могу предложить минимум 10 ответов на выбор :)
невозможно построить на ООП без потери математического доказательства его консистентности.
Вам шашечки или ехать? То есть - доказать, или сделать, чтобы работало?
Продуктов труда программистов, про которые можно что-то там доказать, воообще мало. И доказывать про них сложно. Потому, как бы доказательств не желали, часто без них обходятся - иначе не получается.
Было например в свое время, ещё до Common Criteria руководство по оценке безопасности систем под общепринятым названием Orange Book. Там был упомянут некий идеал - система класса A - безопасность которого была верифицирована. И не было упомянуто (по крайней мере, в книжках тех времен) ни одного случая достижения этого идеала. И это - безопасность, где доказательства желательны сильно.
2×2=4. Или 3. Или 5.
Возражение просто не для сюда: я предлагаю варианты выбора, а не точное решение. А выбор решения, в общем случае, зависит от прочих, не упомянутых здесь обстоятельств.
PS Кстати, об обстоятельствах. Если вы помните древнюю игрушку "Космчиеские рейнджеры", то там в одном текстовом квесте правильный ответ был 2×2=11: у птицы-экзаменатора на лапах было по три пальца.
Могут. А могут — наоборот.
Могут. Потому что думать таки надо. Но знание о шаблонах дает информацию к рамышлению (к примеру, голосом Копеляна: "Информация к размышлению. Visitor.").
Мне ехать, но я предпочитаю ездить на такси, а не на бомбиле с запахом перегара, если представляется такая возможность.
Вы изящным движением мыши выбросили из моей реплики объект действия, я не случайно ведь упомянул конечный автомат: именно для него доказательство консистентности построить можно. Так зачем мне попутка, если я могу ехать на такси?
Если мы прямо сейчас не можем построить межгалактический космолет, это не значит, что нужно отказываться от автомобиля в пользу телеги.
правильный ответ был 2×2=11: у птицы-экзаменатора на лапах было по три пальца
Игрушку не помню, но чтобы 2×2 превращалось в 11, по аналогии с недоказанной предпосылкой к возникновению десятичной системы счисления, пальцев должно быть по 1½ (или лапа одна).
Но знание о шаблонах дает информацию к размышлению […]
Знание реальных задач, с которыми сталкивается разработчик — даёт. А знание шаблоном — лишь зашоривает и сужает горизонт. Как говорил Давид Гильберт: «Каждый человек имеет некоторый определенный горизонт. Когда он сужается и становится бесконечно малым, он превращается в точку. Тогда человек говорит: „Это моя точка зрения“.».
Знание реальных задач, с которыми сталкивается разработчик — даёт. А знание шаблоном — лишь зашоривает и сужает горизонт.
Учить массовых программистов только на реальных задачах - это для общества непозволительная роскошь. Примерно - как учить людей только на их собственных ошибках (кстати, говорят, что исключительно на собственных ошибках учатся лишь дураки).
Ну, а шаблон - это выжимка из решений реальных задач, причем, в достаточно абстрактной форме. Примерно такая же, как в любимой фразе одного человека, которого принято считать умным (хотя сам он неоднократно писал, что в его семье умным был его брат), потому что эрудит, т.е. - специалист по зананию всякого разного: "знание немногих принципов заменяет знание многих фактов". И я думаю, что к мнени специалистприслушаться стоит - хотя, по моему мнению - заменяет далеко не полнностью. Но пользу приносит, однако.
шаблон — это выжимка из решений реальных задач, причем, в достаточно абстрактной форме
Это так. Вопрос только в области применимости этих шаблонов, их непротиворечивости, полноте, и — желательно — неизбыточности.
Иначе мы получаем специалиста с молотком в руке в мире, населенном гвоздями.
Идеальная аксиоматика в виде шаблонов — несомненное добро. Я подвергаю сомнению не этот неоспоримый факт. Я спорю с непротиворечивостью и полнотой этой аксиоматики, особенно, учитывая, что придумали её люди, которые не видели мира за пределами своей избы (вон посмотрите, как Мартин в своем гитхабе открыл для себя кложу :).
P. S. автор цитаты — Капица? Я почему-то никогда её не слышал.
Вопрос только в области применимости этих шаблонов, их непротиворечивости, полноте
Если вы знаете про существование теоремы Гёделя, то вы дожны понимать, что вы слишком многого хотите. Урежьте осетра.
P. S. автор цитаты — Капица? Я почему-то никогда её не слышал.
Кто автор - не знаю. Но повторять её любит Онотоле.
Но ситуация, в которой сущность меняется изнутри — исчезающе редка.
Поддержу, но с другой стороны: а как же геймдев?
Проблема тут, по-моему, довольно фундаментальная.
Программировать сложно. Мы пишем сложный код, который сами до конца не понимаем. Даже лучшие из нас. Глаз замыливается и видит в коде то, что рассчитывает увидеть, а не то, что там на самом деле написано.
Наш сложный код взаимодействует со сложными внешними объектами - с операционной системой, базой данных, устройством, если мы пишем драйвер. С другими программами, если мы мы пишем часть системы, состоящей из многих программ. С библиотеками, которыми мы пользуемся и с объектами, которые они порождают.
Корпоративный стиль поощряет умение быстро решать видимые проблемы. У пользователя на работает штучка, разработчик покопался два дня и выяснил случайно, что если вот в этом вот обращении к внешней сущности с 50-ю параметрами (упакованными в 5 структур) поменять значение не очень понятного ему параметра на другое, проблема уходит.
Будет ли разработчик после этого глубоко копать, чтобы разобраться, что именно он сделал? Параметр непонятный, сущность, к которой он относится, сложна и незнакома. Проблема пользователя вроде как решена (хотя и непонятно почему). Начальство похвалит за быстрое решение проблемы, а за то, что непонятно, почему это решение работает, никто ругать не будет. И никто не выделит времени две недели а может и больше, чтобы разбираться, почему работает этот удачный ремонт.
Может ну нафиг, и в продакшен?
В нашей индустрии ценится умение быстро решать проблемы, не погружаясь глубоко в суть вещей. Это называется умением быстро разобраться в незнакомой области. Хотя никто не разбирался, просто угадал.
Однако умение угадывать тоже не случайно. Оно основано на опыте, на ассциативной памяти. В конечном итоге, весь код писали какие-то люди, профессиональная культура, в который мы росли, в какой-то мере универсальна. Что один человек сделал, другому как-то откликнется. Можно достичь успеха, развивая не фундаментальное понимание вещей, а ассоциативную память. И индустрия поощряет этот путь.
В результате, у разработчиков формируется мистически-магическое отношение к предмету своего труда. Видя описание проблемы, мы с достаточной степенью вероятности можем угадать, что если вот вам вон пошаманить, это поможет. Действия "по наитию" не требуют глубокого понимания, но требуют большой практический опыт решения небольших задач - именно на таком опыте формируются ассоциации.
Если человек больше полагаетса на ассоциации, такому человеку трудно будет читать фундаментальный труд. Потому, что он содержит теоретическую абстракцию, от которой просто так к конкретным ассоциациям не перейдешь. Сборник готовых рецептов зайдет такому читателю гораздо проще.
Не потому ли эти сборники так популярны?
Хороший заход про сложность работы программиста, даже собственный неструктурированный код, или код структуру которого ты писал но забыл достаточно сложно собрать в кучу в своей голове. Думаю от возможности расскрутить знания в книге с "собачка делает гав, кошка делает мяу" до "я хочу иметь возможность отправлять сообщения не только в существующие мессенджеры но и которые появятся потом" зависит сможет ли узрить суть программист того что он читает и как эффективно он будет это применять.
Приведу пример сложности.
Есть такой протокол, IPP. Это протокол, на котором разговаривают сетевые принтеры (и не только сетевые). Он основан на HTTP, внутри там такой бинарный JSON на стероидах. В том смысле, что там структурированные объекты с именованными полями (в IPP они называются атрибутами), и все действия делаются в стиле послали запрос - получили ответ.
Наверное, в этом месте можно вспомнить про REST. Но IPP придуман за несколько лет до REST-а.
Кодирование там бинарное, в стиле TLV (Tag-Length-Value). В подробности углубляться не буду, TLV - это стандартный паттерн при проектировании сетевых протоколов, а Вы ведь, кажется, знаток паттернов.
На Tag там отведен один байт. Некоторые Tag-и обозначают тип данных (например, Integer, Boolean или String - там их много). А некоторые формируют структуру. Например, вложенные объекты (в IPP это называется collection; терминологиа придумана до изобретения JSON-а) управляются парой специальных Tag-ов,
И поскольку на Tag предусмотрен только один байт, то существует механизм, позволяющий хитроумным образом расширить пространство Tag-ов до 32 бит. Называется Extension Tag.
И вот я в своей реализации не учёл случайно, что с помощью Extension Tag может быть закодирован Tag, имеющий управляющее значение. И тогда он просочится туда, куда не должен, и там ему удивятся (нормальные управляюще Tag-и туда не просочатся, с ними разбираются уровнем выше).
Что любопытно, человек, придумавший примерно в одни руку примерно весь IPP, автор CUPS и примерно всех связанных с печатью RFC и стандартов и долгое время отвечавший за стек печати Apple, тоже нарвался на ошибочку в реализации extension Tag в CUPS-е. Не в точности такую же, но в близком месте.
Думаю, ни у меня ни у него нет проблем ни со структурой кода ни с тем, чтобы понять свой собственный код. Так что я тут в хорошей компании :)
Просто бывают люди, которые путаются в собственном языке программирования, а бывают люди, которые работают правда со сложными вещами. Предел когнитивных способностей есть у каждого человека, и в принципе, мы все работаем на уровне, кода его достигаем.
Если я правильно вас понял, у вас было что-то типо out-of-bounds. И не только у вас) Да, такое бывает, и за счет таких вещей существуют хакеры. Раз уж коснулись безопасности, один из её постулатов в том что невозможно создать не взламываемую систему (без ошибок) но стремиться ведь к этому надо, разве нет?
Нет, это было что-то типа UTF-8. Был бы в языке хороший паттерн-матчинг — этой конкретной проблемы удалось бы избежать, не вставая с дивана.
Хуже.
Этот extended tag, он кодируется в первых 4-х байтах value. Т.е. возиться с ним надо не в том слое, который разбирает структуру сообщения, а в том, в который мы попадаем, когда вся структура уже разобрана, и вот оно, чистое данное, бери, проверяй корректность и всё.
А, понял, да.
В принципе, это layering violation в дизайне протокола.
Оно тому была причина. Автор протокола хотел, чтобы старые парсеры, которые ничего не знают про extended Tag, просто пропускали его, как непонятные им бинарные данные.
В протоколах, которые давно существуют и используются, увы. такое накапливается постепенно: всякие некрасивости, созданные для того, чтобы добавить новые фичи, не ломая совместимости со старыми реализациями.
Сам автор тоже напоролся в своей реализации: он искал эти 4 байта сразу после Tag-а, если Tag - extended, а не в данных, уже после длины.
Но самое смешное, что этот самый extended Tag, создающий всем проблемы, в реальности никем никогда не используется :)
Автор протокола хотел, чтобы старые парсеры, которые ничего не знают про extended Tag, просто пропускали его, как непонятные им бинарные данные.
И огромное спасибо автору за это. Я готов простить протоколу все, что угодно, — но не поломку обратной совместимости.
Ну вот, умением делать такие вещи зрелый инженер отличается от ученика.
Я поддерживаю примерно 10 живых библиотек в OSS как мейнтейнер, и они все до единой совместимы обратно вплоть до версии 0.1.0.
Некоторая функциональность объявляется deprecated, не развивается, при смене мажорной версии покидает документацию, но никогда не удаляется из кода.
Самое удивительное, что однажды взяв себе такой стиль за правило — я ему следую без видимых проблем, хотя некоторые библиотеки уже довольно сильно разрослись.
Нет, у меня не было out-of-bounds. У меня Tag (который, как мы помним, может обозначать в IPP как тип последующих за ним данных, так и формировать структуру сообщения) доехал до того места, где, собственно, расшифровываются данные, но поскольку значение этого Tag-а, будучи закодировано как extended, никакому вменяемому типу данных не соответствовало, то оно тут же нарвалось на поставленный мной на такой как раз случай assert (вернее, на panic, это не Си, но это не важно).
Извините мою дотошность, но то что часть сообщения вышла за свои пределы и помещала нормально прочитать сообщение и есть выход за границы) в rfc8010 описывается использование расширения типов протокола, не совсем понял где разработчик протокола ошибся)
Вот где насвистел я: https://github.com/OpenPrinting/goipp/issues/6
Вот где насвистел автор RFC8010: https://github.com/OpenPrinting/cups/issues/913
Фикс в итоге примерно одинаковый: ну нафиг предоставлять какие-то удобства вокруг этого extended Tag. Проще оставить кому надо возможность руками сделать бинарный блоб с расширенным тэгом внутри. Всё равно ими никто не пользуется...
При чём тут out-of-bounds, совершенно непонятно. Out-of-bounds, это когда мы мимо границ буфера в памяти умудряемся промахнуться.
В нашей индустрии ценится умение быстро решать проблемы, не погружаясь глубоко в суть вещей. Это называется умением быстро разобраться в незнакомой области
Я уже 4 года работаю на проектах из дремучего легаси. Там полно умения быстро разобраться в незнакомой области
Критерии низкой стоимости сопровождения на мой взгляд:
Статическая типизация и концентрированная бизнес логика: бесформенные словари в бизнес логике разрезанные по 10 файлам это кранты
Минимум скрытого состояния и как следствие минимум ООП
Понятный и знакомый поток управления. Событийно ориентированное тоже неплохо, если документировано, но документы никогда не пишут.
Простое проектирование. Тут ООП снова в пролете.
Все так, но лично я пока так и не нашел для себя никаких видимых преимуществ статической типизации.
И это при том, что прототипы сложных подсистем я сначала реализую на идрисе. Но не ради статической типизации, а ради доказуемости гипотез.
Статическая типизация позволяет работу по вылавливанию простых ошибок-описок в достаточной степени сделать заботой компилятора и освободить от неё свою собственную голову.
Правда, доведенная до абсолюта, она сама по себе может стать причиной ошибок и ненужной когнитивной нагрузки на разработчика, когда существующие между частями системы сложные контракты пытаются выразить в терминах сложной и вычурной системы типов.
Особенно смешно выглядит сочетание стиле C++, в котором мило сочетаются с одной стороны невероятно сложная система типов в той части, которая касается классов и темплейтов, а с другой стороны, существует около дюжины встроенных целочисленных типов с абсолютно свободным и бесконтрольным автоматическим преобразованием между ними, которое невозможно запретить.
Я знаю все аргументы в пользу статических типов. Просто я лично делаю ошибки не на уровне «передал инстанс пользователя в метод updatePayment».
А в тех местах, где я их делаю — типы не очень-то помогают.
Ну ОК. Значит, люди разные.
Мне лично статическая типизация в компиляторе освобождает какой-то кусок моего головного мозга, и делает его более доступным для других применений.
Ну статическая типизация — это же не только для отлова ошибок.
Есть ещё и type-driven development — когда вы набрасываете программу на подъязыке типов, который родственный всяким Прологам. При этом функциональные требования часто выражаются на этом подъязыке напрямую.
Есть тестирование свойств, где типы, фактически, задают стратегию Монте-Карло.
Но даже если мы возвращаемся к отлову ошибок — подъязык типов должен описывать программу много грубее, чем сам код программы. Иначе теряется смысл, как в С++ факториале на шаблонах — вместо быстрого выполнения машинного кода мы запускаем медленный и кривой интерпретатор шаблонного кода внутри компилятора. Поэтому, кмк, Идрис не очень хорошо подходит для значительной части задач.
И, кстати, неужели pattern-matching вам не заходит? Для бизнес-логики он очень упрощает жизнь. Причём самый дубовый, без GADT, без расширяемых вариантов.
Угу, все так.
Идрис прекрасно подходит для прототипирования критических частей системы. Никто не предлагает писать на нем полную имплементацию, на клее разоришься.
А почему вы решили, что мне паттерн-матчинг не заходит? Наоборот, в динамических эрланге/эликсире он мне с лихвой заменяет систему типов. Я его обожаю.
А в тех местах, где я их делаю — типы не очень-то помогают.
Согласен. Преимущества статической типизации заканчиваются очень быстро.
Система где многошаговый визард и переход между шагами через состояние в словаре, где значения ключей имеют свою бизнес логику: если значение "привет" то привет, если "n/a" то не задано и на это надо реагировать вот так, и ещё 20 вариантов размазано по 5000 строкам в совершенно неожиданных местах. Пока не прочитаешь почти весь код не будешь уверен как именно работает программа. Это был самый ужасный код из того что я видел.
Второй хтонический ужас когда вместо простой crud системы использовали обрезки от системы гибкого документооборота и форма ввода заявок это не файл шаблона, а запись в БД хрен пойми где, но слава богу его не надо было чинить
Система где многошаговый визард и переход между шагами через состояние в словаре
В принципе, это - регулярный конечный автомат. А регулярные конечные автоматы хорошо и понятно описываются на языке правил, типа древнего lex-а.
Но это еще один design pattern, которым новое поколение не очень-то и владеет: написать специализированную тулзу, которая генерирует код. DSL, Domain-specific language.
У меня в моей реализации недетерминированных FSM используется PlantUML/Mermaid строка в качестве DSL.
Потом на стадии компиляции проверяется корректность, а в коде — можно писать только резолверы для каждого ивента.
:)
Достаточно было сделать entity с состоянием, которое меняется по шагам. И прикрутить инвариант чтобы был всегда валидным. И сразу писать в БД все состояния чтобы не возиться с ещё одним форматом для черновика.
Это весьма точное наблюдение.
Мне лично потребовалось более 10 лет, чтобы в цепочку «не работает» → «виноват вон тот модуль» →«виновата вон тот вызов» → «починим вызов» (даже без шаманства с параметрами) — неукоснительно вклинить понимание, почему именно вызов не работал, повторить нерабочее состояние с воспроизводимостью, сделать A/B тестирование и описать суть проблемы и её решения.
Фундаментальные труды, правда, тут тоже не очень-то помогают, как правило. Опыт штука все-таки более полезная, особенно если тратить его не на быструю ассоциативную починку симптомов, а на понимание и устранение причин.
Мне Дейкстра еще в моей юности привил мысль, что мы, программисты, беремся своим слабым мозгом решать проблемы, которые значительно сильнее нас.
Собственно, это, наверное, верно для любого инженерного дела. Архитекторы готических соборов не знали сопромата, он не был тогда еще изобретен. И само по себе строительство могло занимать больше времени, чем мог прожить архитектор, так что он и на собственном опыте не мог учиться.
Однако же, стоят до сих пор.
Но осознавая, что мозг наш слаб а проблемы наши сложны, не укладываются в простые модели и до конца не могут быть нами понятыми, разумно было бы с радостью цепляться за любую ситуацию, которая может быть разобрана и понята если не до основания, а хотя бы до какого-то приближения к нему, а не отмахиваться от них по принципу "что-то нашаманили, как-то работает, ну и ладно".
Как ни странно это прозвучит, мне очень многое для осознания механики процесса, за который мне платят деньги, дала книга Голдинга «Шпиль». К вопросу о готических соборах :)
Мне кажется что это все можно обобщить в одну единственную проблему очень характерную для IT - проблему телеги и лошади. Большинстве разработчиков не могут их различить и ставят решение впереди проблемы. Правильный подход - это решение вытекающее из проблемы а не наоборот. Отсюда вылезают проблемы:
фанатики языков программирования, которым важно решить не проблему и сделать это на их любимейшем ЯП даже если он для этого не очень подходит
фанатики парадигм, считающие что ежики должны плакать и колоться но реализовать любую задачу на их любимой единственно верной парадигме
фанатики фреймворков
фанатики архитектур, чистых кодов и прочего
разработчики которые учат паттерны чтобы натягивать на них любые проблемы
и прочее прочее прочее
Попробуйте у случайного разработчика спросить про тот же ООП - что это такое? Большинство процитируют известный тупой постулат про инкапсуляцию, наследование и полиморфизм, еще абстракцию некоторые приплетут. На вопрос о том что в других парадигмах есть и инкапсуляция и наследование и полиморфизм или о том кто вообще так решил - превзойдет зависание.
Или еще лучше, спросите про SOLID, но более конкретно. К примеру что же такое S и как это реализовать на практике. Опять зависание. Потом объясняешь человеку что по большей части SOLID - это абстрактная популярная ахинея без какой то нормальной конкретики которую можно вывести и человек обычно говорит - "блин, все это время думал что просто я тупой".
С опытом понимаешь что парадигмы, яп, паттерны и прочее это все вторично.
Главное - это умение видеть проблему, подбирать и применять подходящие решения в подходящей ситуации.
Угу. Даже и добавить-то нечего.
Главное - это умение видеть проблему, подбирать и применять подходящие решения в подходящей ситуации.
Короче, если делать хорошо, хорошо и получится :)
Если честно, после того как я увидел 5 летний легаси код, по спине у меня пробежал холодок, но быстро это сменилось недоумением - вот этот код люди продают за огромные деньги? Когда была поставлена задача это все переписать, первое о чем я думал каждый день, это как не превратить проект через 5 лет в туже кашу? Именно тогда я и стал адептом паттернов, я прекрасно помню как сам нервничал каждый раз открывая примеры кода с паттернами потомучто я не понимал для чего все эти усложнения, но после взгляда в бездну (легаси кучу кода) есть ощущение что эта бездна всегда рядом, и мне как специалисту нужно знать как избежать превращение моего кода в такое же легаси
Я сомневаюсь, что паттерны тут лучший помощник.
Кто, чем и как может воспользоваться. Например я открываю статью о игре которую можно запустить где угодно, и вид ее архитектуры представлен ввиде гексогональной, что у меня находит определенный отклик и понимание что возможно такой подход к архитектуре и позволяет запускать эту прекрасную игру на любом устройстве.
Когда была поставлена задача это все переписать
Вообще-то, это - невероятный успех, добиться постановки задачи "все переписать нафиг".
По-моему, основная опасность, которая там подстерегает, называется "синдром второй системы": во вторую реализацию хочется заложить все те упущения, которые по разным причинам не смогли сделать в первой.
А потом я проснулся ©
Потом объясняешь человеку что по большей части SOLID - это абстрактная популярная ахинея без какой то нормальной конкретики которую можно вывести и человек обычно говорит - "блин, все это время думал что просто я тупой".
Смысл SOLID виден на уровне абстракции целого приложения, где разбиение на модули, решение о том, что должно легко добавляться, расширяться и т.д.
На уровне реализовать и внедрить новый функционал, виден как правило, неподдерживаемый легаси.
Смысл SOLID виден на уровне абстракции целого приложения, где разбиение на модули, решение о том, что должно легко добавляться, расширяться и т.д.
Смысл SOLID не понимает толком никто, потому что по духу он больше похож на религиозный свод красивых правил чем на какие то хотя бы околонаучные принципы. Единственное исключение - принцип подстановки Лисков. Остальное это красивые но бестолковые фразы толком не определяющие ничего. Нужно чтобы два разных разработчика в приложении к одному и тому же кода выдавали хотя бы схожие определения того же принципа единственной ответственности, но на деле каждый будет толковать его как ему вздумается, потому что сам принцип кроме красивой фразы не дает никаких объективных критери чтобы с его помощью что-то там вывести.
Я лично «чистый код» на дух не переношу. Но сей час на проекте где хочется его взять, объявить священной коровой и за малейшие отступления долго бить клавиатурой по голове… потому что без стона смотреть на то что народ написал и пытаться это рефакторить - невозможно. При этом все капе у больших: интерфейсы, инъекции зависимостей … пытаться дискутировать и объяснять сил нет, а тут взял «священное писание» и на все вопросы отвечаешь «потому что ….»
а тут взял «священное писание» и на все вопросы отвечаешь «потому что ….»
Проблема в том что оно ни на какие вопросы и не отвечает. ISP - специализированные интерфейсы лучше чем толстые. Окей, а где ответ на вопрос сколько должно быть методов в интерфейсе, как это вывести? Очевидно что никак, по ситуации в зависисмости от контекста. И по сути это совет в духе: сколько по времени нужно держать раскаленный меч в масле для закалки - не слишком долго и не слишком мало по времени. Что будет если левому человеку такое посоветовать и позволить выполнить закалку оружия? Тоже и с разработчиком. Специалист либо и без SOLID понимает что нужно или не нужно в зависимости от контекста или и с SOLID ничего не поймет.
В такой ситуации спасет опытный техлид, хороший code review, настроенный линтер и система правил а не бесполезный SOLID.
В такой ситуации спасет опытный техлид, хороший code review, настроенный линтер и система правил а не бесполезный SOLID.
Золотые слова.
Окей, а где ответ на вопрос сколько должно быть методов в интерфейсе, как это вывести?
Это как вопрос художника - сколько надо добавить зелёного чтобы написать хорошую картину?
Ту только опыт и чувство прекрасного.
Последнее время всё больше склоняюсь к тому что всё-таки программирование это искусство
Так случилось, что я в студенчестве научился класть печи. У меня был педагог, Степаныч, которому я чем-то глянулся, и он разрешил мне подавать кирпичи и мешать раствор под его присмотром. Потом мне была дозволена кладка вдали от дымоходов. А спустя примерно полгода — я сложил свою первую печь под его неусыпным надзором и удостоился самой ценной — из слышанных мной за всю жизнь — похвалы: «Вот, сука, не совсем ты все-таки полено». До сих пор глупо улыбаюсь, вспоминая.
Так вот: класть печь — это чистое искусство. Там нет инструкции, следуя которой ты сложишь артефакт, который не будет чадить, и не будет выпускать всё тепло за час. Вообще. Я знаю людей, которые клали печи по тридцать лет, и потом всё равно звали Степаныча, за впятеро бо́льшие деньги (а спустя некоторое время — и меня, за половину того, что просил Степаныч, хе-хе).
Просто представьте: работаешь неделю-две без перекуров, потом ждешь несколько дней, а потом поджигаешь газету под дымоходом — и изба наполняется смрадным чадом. Печь придется разбирать и звать кризисного менеджера (Степаныча).
В разработке все-таки больше возможностей понять, что ты идешь по какой-то неправильной тропинке. Отладчик, тесты, изоляция…
Так что прилежный мастеровой может писать вполне себе неплохой код, особенно, если в него иногда заглядывает профессионал.
Так вот: класть печь — это чистое искусство. Там нет инструкции, следуя которой ты сложишь артефакт, который не будет чадить, и не будет выпускать всё тепло за час. Вообще.
Вот токомаки там всякие со стеллараторами, в отличие от печи поддаются компьютерному моделированию. Печи - это другое, тут без Степаныча никак.
Токамаки. Я никогда не цепляюсь к орфографии, но тут смолчать не могу: я по первому образованию выпускник кафедры физики плазмы и защищал диплом в физтехе им. Иоффе.
И тогда уже наука вовсю теплилась, а моделирование — пока нет.
Ну да ну да. Физик - печник не в курсе про моделирование в термояде? Так на хабре как раз недавно была статья про то, как придумать стелларатор без Степаныча.
И да, про чудо печников это просто деревенские байки от непонимания физики процесса.
Физик-печник не в курсе про моделирование в термояде?
В курсе. Просто в моём комментарии речь идет про конец 80-х.
да, про чудо печников это просто деревенские байки от непонимания физики процесса
Вполне вероятно.
В курсе. Просто в моём комментарии речь идет про конец 80-х.
Пойду расскажу коллеге за соседним столом, что он в конце 80-х в курчатнике не ЯР считал на VAX, а в сапёра играл или там косынку раскладывал.
Я не знал, что в 80-е в Москве был VAX (на каком железе, любопытно было бы узнать). В Ленинграде были ЕС-ки (на ДОС ЕС) и ДВК-2 (на RT11SJ).
В курчатнике родной, настоящий VAX (не реплика) был. Кроме того, в конце 80-х уже и сэвовские клоны серии СМ подоспели.
Я не знал, что в 80-е в Москве был VAX
В Физическом институте АН СССР их тогда было даже два: 750 и 780. Ну, а лично я тогда хакерствовал на ЕС-1045 под IBM VM/SP (слегка адптированной).
Так на хабре как раз недавно была статья про то, как придумать стелларатор без Степаныча
Если не сложно, ссылку на статью можете дать (или как-то иначе навести на нее)?
https://habr.com/ru/companies/first/articles/895132/
И ещё много по поиску
Пробежал по статье, не понял, при чем тут она к Степанычу? Печи не нужны, даешь термояд? Или до XV века печи нельзя было строить?
Печи - это другое, тут без Степаныча никак.
Естественно, т.к. эти кирпичные печи никому не нужны в промышленных количествах. А поскольку эти кустари с мотором стараются секретами не делиться, кладка — это искусство.
Те же печи, которые делаются массовыми тиражами, разумеется, нормально отлажены и штампуются без проблем и «искусства».
Те же печи, которые делаются массовыми тиражами, разумеется, нормально отлажены и штампуются без проблем и «искусства».
Они всё равно будут сильно уступать по КПД хорошо сложенным кустарным, почему-то.
Они всё равно будут сильно уступать по КПД хорошо сложенным кустарным, почему-то.
Общее решение против частного. У вас по работе ведь тоже часто приходится делать велосипед для своей конкретной задачи, который много проще и производительнее «стандартного» решения.
Тут печь рассчитывается, хоть и кустарно, под конкретный дом. Но выше головы, задаваемой мелкобуржуазной экономикой, не прыгнешь — рынок слишком мал, чтобы делать индустриальными методами специализированные печи. Поэтому там бегают кустари с мотором, без общей базы, без стандартных учебников, на средневековом уровне ремесла.
Единственное исключение - принцип подстановки Лисков. Остальное это красивые но бестолковые фразы толком не определяющие ничего.
Я некоторое время назад задумался над вопросом, а как должен быть сформулирован принцип подстановки Лисков не в ООП, а в общем виде, безотносительно того, на каком ЯП его реализовывать и даже безотносительно того в какой парадигме он должен быть реализован. И насколько я для себя понял, в самом общем виде принцип подстановки Лисков такой: всякая функция соответсвует своей сигнатуре, т.е. если f определена на X, то для любого x из X верно, что f(x) определена.
С точки зрения математики утверждение настолько очевидное, что даже обсуждать нечего!
Математическое определение есть в вики, и оно там несколько другое)
Я знаю. И мне кажется определение из Вики эквивалентно тому, что я написал. Но я не очень разбираюсь в теории типов. Поэтому мне проще формулировать на языке теории множеств (т.е. заменить термин тип на множетсво, а свойство на функцию). Наверное между этими формулировками есть какие то неочевидные для меня различия, которые скажутся на очень хитрых теоретико-типовых конструкциях. Наверняка. Другой вопрос насколько всё это имеет значение в прикладном плане.
Не знаю, функция как часть объекта это метод, чем он идеологически отличается от функции кроме ограничениями на клиентский код? Если точно также имеет сигнатуру? Может точность математического определения это достаточно важно, собственно для этого и используется математика?
…и оно не имеет смысла (то есть, никогда не выполняется для любого производного типа), если в языке есть операторы вроде typeid, dynamic_cast и тому подобных, позволяющие сформулировать предикат вроде φ x = typeid x ≡ typeid T.
Принцип подстановки Лисков хорошо описан в любой статье, объясняющей, что такое полиморфизм.
ООП туда втащено за уши, чтобы Барбара могла войти в историю, а Мартин — продать очередную книгу.
Получается Лисков, она как визитер но для богатых?
Получается, что эти два паттерна описывают разными словами примерно одно и то же, а значит — избыточны. А где избыточность — там уже крайне тяжело рассчитывать на непротиворечивость.
... того же принципа единственной ответственности ...
Который имеет вполне точное определение - причина для изменений.
Имеем приложение;
Собираем статистику, что чаще всего требуется изменять;
В соответствии с п.2 делаем рефакторинг по принципу единственной ответственности.
Откуда взялось слово статистика? В SRP ни слова не сказано про статистику. Вот вы для себя протрактовали SRP так, что надо собирать статистику. А другие программисты и архитекторы трактуют этот принцип так что мол единственность ответственности определяется тем, какое подразделение разрабатывает какой функционал. А третьи говорят, что речь идёт про модельные слои. Договоритесь друг с другом, пожалуйста.
Ключевой момент принципа - это причина для изменений. Самый надежный вариант это узнать - статистика.
Хотя даже на этапе начала разработки, белее менее известно, что будет меняться.
Ключевой момент принципа — это причина для изменений.
Citation needed.
Вполне могу представить себе ситуацию, что в разработанной системе за год статистически чаще всего менялся пользовательский интерфейс, а бизнес логика, система логирования и механизм взаимодействия с БД не поменялись ни разу.
И если я правильно понимаю ваш подход, в таком случае надо объединить бизнес логику, механизм обращения к БД и систему логирования в один класс.
Нормально делай, нормально будет.
Как понять, что код написан умными людьми?
Где логический переход "код написан умными людьми" => "хороший код"?
Вам бы стоило читать больше книг, чтобы узнать, что CS это не только Идрис. Кстати, ООП это программная инженерия, а не наука. И ругая книги, которые можно условно собирательно назвать "приёмы программирования", вы, по сути, ругаете любые книги по приёмам прикладного использования. Просто представьте, что кто-то пишет статью "почему не нужно читать книги о приёмах в металлообработке" - ну бред же?
У вас перепутались понятия "как нужно" и "как можно". Любая адекватная книга по ООП содержит примеры того, что решает тот или иной паттерн.
Любая адекватная книга по ООП содержит примеры того, что решает тот или иной паттерн.
Но ни одна не содержит внятных доказательств того, что задачи, которые решает этот паттерн, — вообще существуют, а если да — то не могут быть решены проще, точнее и изящнее.
Как книга на тысячу страниц, в подробностях объясняющая технологию заколачивания шурупов утюгом.
Я не знаю, что вы за книги читаете. В нормальных книгах есть пример "вот получается плохо", а "вот так код чище/проще/надёжнее". Что касается страниц: 395 у "Банды четырёх", 668 у "Enterprise design patterns". И учитывая, что большая часть это листинги, то получается совсем немного. Я не отрицаю, что плохие книги тоже есть. Например, Егор Бугаенко пишет как раз в таком стиле, о котором вы рассказываете, и да, его советы относительно ООП местами сомнительны. Но так не надо читать такие книги =)
В нормальных книгах есть пример «вот получается плохо», а «вот так код чище/проще/надёжнее».
Вы правда не понимаете, почему это и близко не является никаким доказательством?
Вот смотрите: утюгом неудобно заколачивать шурупы, возьмём молоток, и — оппа — шуруп заколочен. А я просто знаю о существовании отвертки и шуруповерта, поэтому все ваши примеры для меня звучат именно так.
Вы знаете, а кто-то не знает, поэтому и пишутся книги. Кстати, вы родились с этим знанием или всё же где-то прочитали? И почему вообще методы и приёмы эффективной работы должны доказываться? Вам никто не мешает писать сразу в машинных кодах без всяких шаблонов проектирования, никто не скажет, что это неправильно. Просто едва ли найдётся тот, кто станет это оплачивать.
утюгом неудобно заколачивать шурупы, возьмём молоток, и — оппа — шуруп заколочен.
Анекдот №10042198
«Хозяйке на заметку.
Шуруп, забитый молотком, держится крепче, чем гвоздь, закрученый отвёрткой.»
:-)
Хочу заметить, что Computer Science - это не только сборник наилучших практик типа всякого "Чистого чего-нибудь", но и к примеру, алгоритмы. Автор статьи почему-то на эту сторону Computer Science внимание не обратил - а она есть.
В целом же Computer Science - это, на мой взгляд, достаточно типичная прикладная наука, систематизирующая способы добиться желаемого в определенной области деятельности: от применения довольно сложной математики до сборника рецептов от людей, у которых получилось.
Что касается наилучших практик, то IMHO они служат некой заменой собственного опыта для тех, кто ещё не успел набить достаточного количества собственных шишек. А то, вообще-то, тренироваться полтора десятка лет, да ешё и не на кошках - оно для общества дороговато будет. Так что, пусть джуны лучше осваивают поначалу SOLID, чем практикуются в спагетти-стиле - меньше потерь будет. А потом жизнь их все равно поправит.
Алгоритмы — это прикладная математика, иногда — матфизика.
пусть джуны лучше осваивают поначалу SOLID, чем практикуются в спагетти-стиле
Как давно вы перестали пить коньяк по утрам?
Это ложная дихотомия, в общем. И SOLID слишком часто порождает в результате именно спагетти.
Это ложная дихотомия, в общем. И SOLID слишком часто порождает в результате именно спагетти
То, что в начале ученик делает избыточную шаблонную работу, не страшно, потому что он делает ее правильно (пусть даже и не понимая, что именно там правильно). Потом, когда он это поймет, то и от шаблонов можно будет отойти. Но не раньше!
Или например выбирать между ActiveRecord и TableModule
ученик делает избыточную шаблонную работу, не страшно, потому что он делает ее правильно
А вот это «правильно» — оно из чего именно следует? Из «миллионы мух не могут ошибаться»?
Правильно, означает, что результат соответствует т/з.
Что-то я запутался.
В ТЗ указано требование, какие именно шаблоны использовать? Тогда мой вопрос переносится на уровень выше: а откуда те, кто писал ТЗ знает, что использовать эти шаблоны — правильно?
Ну мы же про учебники говорим, не про постановку задач? А учебники показывают шаблонные пути решения оных. И обычно это самые оптимальные (или около того) решения. Поэтому если ученик/начинающий программист работает по шаблонам, то это хорошо для него (его код даже коллеги быстрее поймут). А вы ведете речь про высший пилотаж, когда для каждой отдельной задачи существует самый оптимальный вариант ее решения (ну пусть даже несколько таких вариантов). Во-первых, это не каждому под силу. А во-вторых, некоторым коллегам будет трудновато понимать ваш код. В любом случае, это не про учебник "для чайников", это про то, как стать Степанычем в своем деле.
Я не считаю, что речь про высший пилотаж. Наоборот, мне кажется, что смотреть в код проекта, на то, как такие задачи решались прямо тут, коллегами, у которых можно спросить: «А почему именно так?» — и при удачном стечении обстоятельств услышать в ответ аргументацию, а не отсылку к авторитету — полезнее и лучше.
Изобрести велосипед, на кодревью получить разнос собственного кода с пояснениями, переделать — все это принесет гораздо больше пользы. Мне так кажется.
Изобрести велосипед, на кодревью получить разнос собственного кода с пояснениями, переделать — все это принесет гораздо больше пользы
С этим не поспоришь.
Изобрести велосипед, на кодревью получить разнос собственного кода с пояснениями, переделать — все это принесет гораздо больше пользы.
Только вопрос, как всегда, в субъекте: кому принесет. Программирующему - скорее да, чем нет. Бизнесу, на который он работает - может быть по-разному. Например, потому, что объяснять - это элеметарно дольше, а у нас тут, может быть, фичу надо выкатить успеть до конкурентов.
Вдолгую — и бизнесу тоже.
Научить стажёра хорошему — быстрее и проще, чем отучить синьёра от плохого.
Тут, конечно, сразу возникает вопрос, а что есть хорошее, а что - плохое "Что такое хорошо, и что такое плохо"(помните соответствующий стих, наверное: "Хорошо быть кисою, хорошо - собакою...")?
И на эту тему есть страя статья (но вы ее не могли не читать) - про настоящих программистов.
Так вот, насчет стажера: он ведь обучится и уйдет, и деньги на его обучение будут для бизнеса потеряны. А с учетом того, что компетенции этого бизнеса, его конкурентные преимущества вряд ли лежат в области обучения программированию, бизнесу заниматься обучением стажеров нежелательно - не окупится, если, конечно, это не галера или другая "школа кадров". В нынешних условиях - да приходится, но это - нужда, которую не следует выдавать за добродетель.
Ну дайте уж ссылку на статью, пожалуйста. Я мог ее и не читать (по двум разным причинам).
деньги на его обучение будут для бизнеса потеряны
Всё сложнее. Бизнес уличшит менторские навыки тех, кто его учил. Качество кодревью в среднем. Да много чего.
Мне доводилось на примерах переубеждать два миллионных бизнеса в том, что обучать джунов — выгодно.
Ну дайте уж ссылку на статью, пожалуйста.
Статья (точнее, перевод) - http://lib.ru/ANEKDOTY/non_pas.txt
Мне доводилось на примерах переубеждать два миллионных бизнеса в том, что обучать джунов — выгодно.
И как, получилось? Если да, то у вас, похоже, хорошие способности к убеждению.
А вот это «правильно» — оно из чего именно следует?
"Критерий истины - общественная практика." (и, судя по некоторым признакам вас этому должны были даже учить). То есть, если вернуться к нашим баранам, у руководителей команд, которые применяли "наилучшие практики" (естественно, с умом - но это не формализуемо, к сожалению), почему-то результаты получались лучше. Потому эти практики и закрепились.
Ну да, с точки зрения формальной логики, это - не доказательство. Но по жизни - вполне.
Но с этим критерием, как и с диалектическим подходом в целом, всё не просто - в любом конкретном случае он может не подойти. Так что, всегда, если есть возможность, надо бы смотреть конкретные обстоятельства. Только вот, у того же джуна возможности часто нет. Потому так и живем.
Это ложная дихотомия, в общем.
Именно дихотомии там нет: можно придумать и ещё пути освоения программирования. Но спагетти-код (а также - имена переменных из одной буквы и прочие примеры дикого программирования) я сликом часто видел в жизни, чтобы не упомянуть, как более чем реальный исход, к которому приводит нигилизм (особенно, подростковый) по отношению к "наилучшим практикам".
В какой момент «паттерны ООП» и «наилучшие практики» — внезапно стали взаимозаменяемыми в аргументации синонимами?
Я никогда, вроде, не утверждал, что нужно специальным образом избегать читать хороший код и делать выводы.
Они - не взаимозаменяемы. Но, по моему опыту, корреляция там таки наблюдается.
То бишь, паттерны ООП возникли не на пустом месте.
Лично я стал читать соответсвующую литературу достаточно поздно, потому что не считал менеджмент своим занятием, а потому, читая, неоднократно обнаруживал, что хорошо знакомый мне прием программирования, до которого я дошел без помощи книг - своим умом или, там, чтением чужого кода(сослуживцев, исходников библиотек и пр.) - оказывается, описан в книгах и имеет красивое название.
А сколько там было таких, до которых вы никогда не доходили на основе опыта? А то пока эффективность — как ставить всегда на выпадение орла с аргументацией: «очень часто, когда я ставил на орла, — он и выпадал, и я выигрывал!».
Полностью согласен с вами. Насчет опыта программирования и следованию паттернам. Мне один уже уволившийся из фирмы программер сказал что он не использует встроенные процедуры в БД, указав на книги в которых везде написано что это неправильный подход. Но он написал важную для фирмы программу вообще без бд, используя в ее качестве xml файлы. Это был его "паттерн". В результате это привело к тому что пользователи вынуждены создавать и редактировать такие файлы и некоторые из них по сотне страниц. Вы пробовали когда-нибудь заменять куски xml в файле такого обьемa? Ему просто надо было создавать нормальное приложение с БД и редактором, но ведь можно использовать пользователей и не напрягаться в этом плане. В результате мне пришлось все эти xml перетаскивать в БД, а пользователи уже насоздавали новых с перемешанными атрибутами дерева объектов. В результате пришлось разработать метод импорта в БД в самой БД через сложные встроенные процедуры и переписывать всю программу с нуля с редактором дерева обьектов и новой парадигмой разделения на рабочие и тестовые конфигурации приборов одновременно для сетевого и локального варианта. Перенос из хмл в БД это была очень нетривиальная задача, так как следовало сохранить дерево и связи в таблицах бд.
Но он написал важную для фирмы программу вообще без бд, используя в ее качестве xml файлы. Это был его "паттерн".
Файлы XML, если с точки зрения теории БД (это я пересказываю книжку 80-х годов), имеют иерархическую модель. Возможности этой модели ограничены (по сравнению с реляционной или сетевой/графовой), но она возникла исторически первой, и, что было важно - поддерживалась аппартно тогдашними устройства хранения (жесткими дисками с архитектурой count-key-data), поэтому какое-то время ее выбор был обоснованным, даже с учетом ограничений. Но использовать ее сейчас - это IMHO, сомнительное решение. Так что, если автору хватило возможностей XML-файлов - ему повезло. Или - таки не хватило?
PS В сетевую БД иерархическая система переносится легко и просто, а вот про реляционную - возможно, придется подумать, особенно, если не наплевать на производительность.
про реляционную — возможно, придется подумать
Не надо там думать. Если была схема XSD (а ее не могло не быть, иначе файлы клиентов не валидировать никак) — в ней просто описаны ссылочные поля, как и счетные, и все проверки, гарды и валидаторы.
На коленке за день можно набросать схему преобразования XSLT, которая хоть в SQL, хоть в DSL переведет и саму схему XSD, и файлы пользователей.
Когда я не знаю, какое из архитектурных решений выбрать, я не ленюсь и делаю 2-3 прототипа, после чего смотрю на них свежим взглядом и выбираю самый ясный, гибкий и эффективный.
Ещё ни разу классические паттерны не побеждали в этом соревновании.
Разумеется, но это не значит, что они никогда не победят. Дело в том, что там, где они побеждают — у вас и так архитектурных сомнений бы не было.
Паттерны — что-то типа арифметики (причем их количество можно без потери общности сократить штук до 5-7). Без умения складывать и вычитать — никуда, но лемму Пуанкаре на плюсиках и минусиках не докажешь.
С одной стороны автор заявляет, минимум Н языков минимум М парадигм и т.д. с префиксом минимум что бы что? Чтобы иметь свое мнение. С другой стороны весь бизнес в котором мне довелось поработать следует не хитрым максимам - лучше безобразно, но единообразно, а одним словом пресловутое консистенси. Т.е. никакие упомянутые минимумы в продуктовой разработке не достижимы - язык один на всю жизнь компании, фреймворк один лет на 20 вперёд, архитектура одна по принципу первое, что заработало с налетом тех самых красивых идей про правильные архитектуры. За годы идеи не меняются, но их интерпретация меняется, что неизбежно отражается в коде. И так цель бизнеса консистенси потому что менеджеры верят, что так дешевле. Результат никогда не является консистентным, но любые попытки навести порядок кардинальным способом (собственно и реализовать консистентность) так же зарубаются с иронической формулировкой - не констстентно с нашим бардаком.
Мой поинт в том что идея каждой задаче свой подходящий инструмент - это утопия, даже я (поборник анархии и схожего подхода) в это не верю. Вам нужно принять ограничения в рамках которых надо решить задачу, если бизнес сказал какой нахер элексир ты чё ваще курил? То надо решить задачу в рамках того бардака что есть, а не рассказывать про розовых единорогов и как в мире правильно подобранных абстракций все просто.
Какой толк от вашего вентилятора если вы не рассказываете как находясь в хаосе бардака и куче политических /не технических ограничений решать проблемы. То что код бардак и все работает не так как задумывалось становится очевидным всем и быстро без статей наподобие этой.
Другими словами польза от статьи увеличилась бы примерно чуть менее чем в бесконечность если бы вы рассказали как таки реализовать ваши акторы или че вы там рекомендуете в том бардаке в котором вынуждены работать (а это обычно ООП на шарпах, Яве или плюсах + хтонический компот в гуе который на словах мимикриует под мвц или производные) те кто эрланга и акторов отродясь не видели. Заменить все на эрланг - спасибо следующий, этот совет ничем не лучше критикуемых книг.
Суть статьи в одном абзаце. Ты туда не ходи снег башка бобобо. А куда ходи? Там где хорошо! А это ваще где? Ну ты походи лет 40 как Моисей по пустыне сам поймёшь где хорошо. Спасибо, следующий.
Авторов, предлагающих готовые решения, — пруд пруди. Если вам нужна серебряная пуля — её нет. Если вы хотите получить на выходе ощутимую реальную пользу — рыбу я не дал, но удочку дал, ищущий — да обрящет.
В Java-мире триста лет назад реализовали акторную модель (почти без костылей, причем). Называется Akka. Гуглится при желании за 10 секунд.
На шарпе её (о, чудо!) повторили, потому что умные люди с широким кругозором иногда попадаются даже среди го-разработчиков, а в мире дотнета — их полно́. https://getakka.net/
Более того, в любой старый и неуклюжий проект всегда можно принести брокер сообщений и отчудить все новое и отчуждаемое в микросервис (я не предлагаю распиливать монолиты, это утопия и путь в никуда, но новая функциональность в обособленном сервисе на любом языке с интеропом через брокер сообщений — работает).
Если вы не нашли ничего «на подумать» в тексте выше — это не моя проблема. Как я уже сказал, я не Блиновская и не Боб Мартин, готовых рецептов «как стать счастливым» — не даю.
Я видел несчётное количество раз как хорошие инструменты и абстракции используются не по назначению и вредят. Ваш посыл иди ищи акторы реализованные на рабочем стэке пользуй их и будет тебе счастье, как раз намекает на серебренную пулю. Никаких удочек я не увидел в статье.
Я понимаю, что мое мнение никому не важно, но если вдруг вам интересно, то меня бы заинтересовала статья рассказывающая про модель акторов (без примеров на элексире) на высоком уровне и как то обосновывающая преимущества по сравнению с альтернативами. Далее я бы хотел понять из статьи какие у нее условия применения/ограничения и как распознать хорошую реализацию этих акторов на каком угодно стэке, какие ключевые моменты реализации критичны для обеспечения заявленных преимуществ, потом для закрепления идеи пример где акторы реализованны НЕ верно и почему и как надо исправить, и пример где акторы использованны не верно и почему, и в самом конце как справочник хорошие реализации на разных стэках.
Такая статья была бы удочкой, да.
Ваш посыл иди ищи акторы реализованные на рабочем стэке пользуй их и будет тебе счастье […]
Никогда не было у меня такого посыла. Ничего и близко похожего я не говорил. Я ответил на «если бы вы рассказали как таки реализовать ваши акторы» — ссылкой.
Я не хочу и не могу писать книги, про акторную модель можно почитать в миллионе разных мест (ссылку на пару я и предоставил как раз).
В самом начале книги банды четырех написано зачем нужны паттерны, так что если таки читать книги с начала то и вопросов будет меньше.
Описанные там паттерны - это паттерны ООП. Авторы никого не заставляют писать на ООП.
Соответственно критиковать их с позиций неООП довольно странно. Логично что некоторые из них в другой парадигме реализуются тривиально, а у некоторых даже задача которую они решают не возникает. В ФП, к примеру, тоже самое можно сказать про линзы или там монаду IO - не читайте книги о них перед обедом, ведь ООП и другие парадигмы отлично живут без них.
Программисты на ООП сталкиваясь с похожими задачами изобретают похожие конструкции. Всем удобнее когда этим конструкциям даны названия и описана их типичная реализация.
Поэтому считать их молотком и видеть во всем гвозди не надо, но знать их стоит чтобы понимать других программистов и не изобретать лишний раз велосипед.
Иногда лучше изобрести велосипед, чем продолжать ездить на танке.
если у тебя есть танк, ты по прежнему можешь изобретать велосипед. Зато когда понадобится танк - он уже под рукой.
Зато если танк не понадобится никогда, то вместо него можно в комнате поставить кровать и письменный стол.
он понадобится как только пойдешь работать с другими танкистами. Если с ними работать (а также изучать их опыт или передавать им свой) не планируется - да, можно вместо танка что-нибудь другое поставить.
Если это обобщение, то доказательство его неверности требует единственного опровержения, и оно у меня есть.
Если это «личный опыт» — то могу сообщить, что это зависит от культуры общения в коллективе: кто-то и без смайликов свои мысли выразить не способен, а кому-то хватает традиционного русского языка.
Это наблюдение.
Но про опровержение было бы интересно послушать - вы успешно работали\контрибутили в проекты где применяются эти паттерны при этом не зная их?
от культуры общения в коллективе: кто-то и без смайликов свои мысли выразить не способен, а кому-то хватает традиционного русского языка.
непонятно при чем тут культура общения.
Мне сложно без лукавства признать, что я о них прям не знаю; не узнаешь тут, когда из каждого репродуктора про них как в «1984» круглосуточно рассказывают. Но я успешно работал в коллективах до их массового распространения, и я успешно работал в коллективах после их распространения, никогда не прибегая к этой иероглифике для обозначения простых и понятных действий.
Культура общения тут при том, что можно тремя словами обычного литературного языка выразить любой паттерн, а можно прибегать к заклинаниям.
ладно, как выразите тремя словами паттерн Посетитель (Visitor)?
Но я успешно работал в коллективах до их массового распространения, и я успешно работал в коллективах после их распространения
А кто-то успешно без математики в программировании работает. Непонятно что это должно доказывать.
Это ничего не должно доказывать. Это ответ на ваш вопрос, который вы задали в предыдущем комментарии.
Да мне и одного хватило бы, но раз просили три, то вот: «полиморфизм для бедных».
и что, где-то так и выражаются? "А вот этот интерфейс AST-узла реализует полиморфизм (для бедных)"? Потому что одно дело - не использовать паттерны ООП, другое - использовать но при этом не называть их по имени.
Это ничего не должно доказывать. Это ответ на ваш вопрос, который вы задали в предыдущем комментарии.
Хорошо, я правильно понял что на вопрос "вы успешно работали в проектах где применяются эти паттерны?" ответ "я успешно работал в коллективах до их массового распространения, и я успешно работал в коллективах после их распространения, никогда не прибегая к этой иероглифике", т.е. "нет".
как выразите тремя словами паттерн Посетитель (Visitor)?
Да мне и одного хватило бы, но раз просили три, то вот: «полиморфизм для бедных».
Например: Singleton
Давайте для примера посмотрим на один из самых простых (и широкоизвестных) паттернов: «Singleton». Его предназначение (согласно Вике)
Очень интересное начало статьи: ссылка на Википедию. Википедию никто не пишет как целостное описание (хотя должен писать). Строго говоря, в статье должна быть формулировка, взятая из (перво)источника.
У класса есть только один экземпляр, и он предоставляет к нему глобальную точку доступа. При попытке создания данного объекта он создаётся только в том случае, если ещё не существует, в противном случае возвращается ссылка на уже существующий экземпляр и нового выделения памяти не происходит.
Этого абзаца вполне достаточно. Зачем нужен оборот "и он предоставляет к нему глобальную точку доступа", непонятно. Дальше идёт нагромождение каких-то утверждений. А где, собственно, статья, то есть — связный текст?
Нужно ли эту реализацию называть специальным словом «паттерн» и обособлять среди других конструкций языка?
Можно ничего ни делать. Можно не возводить в культ. Да. Многие возводят в культ и, даже, книжки пишут.
"Паттерн" — это просто некоторый фрагмент кода, который возникает всякий раз, когда мы хотим добиться определённого результата. Не более. Вопрос, лишь в том, чего мы хотим — дело сделать или "паттерн" применить.
Боже упаси оказаться в одной команде с автором данной статьи. Или же работать с его наследием.
Дико плюсую (хабр не дает правда, я не очень активный, но всё-таки)
Есть темы от которым прям несет... коричневой теплой массой
ООП - это тема, от которой за версту несет при первом же знакомстве
Но миллионам мух по понятным причинам она оказалась по вкусу, теперь сидят тут автору жужжат
Никогда не читайте перед обедом книг по специальности