Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.
Когда трава была зеленее, когда мы сильно боролись за каждый такт процессора, тратя на это наше время, которое мы тогда не очень ценили, все было в какой-то мере проще.
Если тебе нужна была фича, ты ее делал сам.
Или ты искал уже реализованную фичу, и прикручивал к своему коду.
Больше времени уходило на поиск. Не всегда можно было найти.
Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, и ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё ни разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.
Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.
Потом конечно ты находишь в документации к конкретной версии фреймворка новый способ отключения ненужного тебе функционала, но .... Ты теряешь время. И твои предыдущие знания обесцениваются.
И так каждый раз. Количество свистоперделок, которые надо отключать, растет. Новые знания, которые ты приобретаешь, не понадобятся. Когда ты будешь пытаться применить их снова, все изменится.
Ощущаешь себя плотником, который каждый раз обрубает все более и более корявые заготовки, из которых надо что-то сделать.
Ты хочешь простых и предсказуемых деталей, из которых сможешь собрать полезную вещь. Но тебе каждый раз выдают новые и все более кривые детали, с кучей дополнительного функционала.
Многие из них зависят друг от друга, причем от конкретных версий. А от других версий ломаются.
Зато стильно, модно, молодежно.
И вместо усиления знаний по действительно важным вещам и принципам приходится копаться в разных версиях одного и того же фреймворка.
А таких фреймворков все больше, и они все более и более обрастают новыми возможностями. Меняется не только синтаксис, но и семантика.
Даже простой, как автомат Калашникова, SQL правдами и неправдами пытаются заменить на что-то другое: на xml из liquibase, jql, hsql и т.д. В языке появляются новые классы. Старые классы меняются. Каждый из классов все более представляет собой минибиблиотеку, причем изменяющуюся во времени.
Это ад сборочного программирования.
Создавая ООП, мы пытались разделить код на более простые объекты с небольшим количеством методов в каждом. Что же мы получили? В каждом объекте 100500 методов. И самих объектов 100500. И все надо знать, чтобы не писать велосипед. Но это декартово произведение, комбинаторный взрыв. Нет ничего удивительного, что ИИ будет писать лучше и компактнее простой код. Он просто больше кривых деталей держит в оперативной памяти чем любой человек. Даже на самом низком начальном уровне стандартной библиотеки языка Java для определения числа элементов мы имеем length, length(), size().
Это тупик.
Уж лучше иметь меньше сущностей, но более универсальных, с более универсальными методами. Сделать один метод count, который будет работать со всеми коллекциями, что бы они не представляли.
Мы прекрасно храним любые данные и параметры любых фреймворков в json и yaml. Зачем же мы делаем столько классов и объектов, чтобы работать с данными, которые можно представить в одном и том же виде?
Лучше иметь несколько структур данных и несколько сотен постоянных функций над ними. Постоянных - т.е. они не будут меняться из класса в класс, из объекта в объект. Нужно только разобраться один раз.
Здравствуй, функциональное программирование. Какой же я дурак, что так не ценил тебя.
Надо сворачивать. Пока не поздно. Но может, мы уже опоздали.
Комментарии (27)
eao197
20.10.2025 21:55В этом плаче Ярославны очень не хватает примеров кода: мол, вот 20 (15 или даже 10) лет назад было вот так, а сейчас вот так и посмотрите какая разительная разница.
Jijiki
20.10.2025 21:55вот пример к чему я пришел в пет проекте, всё в своих структурках и компактно, в проекте я пошел дальше и теперь всё в модулях в своих структурах структуры есть уже иерархические, вроде это не ООП, помойму что ООП что структурно-функциональный подход в своей екзальтации сложны, вулкан на структурах например
SergioPredatore
20.10.2025 21:55Подставляю свой фреймворк (.net) и радуюсь что статья не про меня. У него есть конечно некоторые шероховатости, но он развивается и с каждым годом становится лучше. Да мне нравится мой фреймворк и мне нравится как он развивается.
basilios
20.10.2025 21:55EF например, с несколькими джойнами, группировками, оконными функциями и пейджингом.
Chaos_Optima
20.10.2025 21:55Лучше иметь несколько структур данных и несколько сотен постоянных функций над ними. Постоянных - т.е. они не будут меняться из класса в класс, из объекта в объект. Нужно только разобраться один раз.
И получаем 100500 функций * на 100500 объектов, и весёленький интелесенс. Может всё таки проблема не в ооп а в ручках?
nemavasi Автор
20.10.2025 21:55Зачем нужны объекты тогда?
Несколько структур данных и функции, которые только с ними работают.
Chaos_Optima
20.10.2025 21:55В смысле зачем? Если делать по нормальному а не фигачить по 100500 методов то всё будет в порядке, а так говнокодить можно в любой парадигме и не любом языке
Это замечательно когда проект небольшой, например микро сервис какой-нибудь, а когда проект становится здоровым, добавляется вариация с плагинами у кучей всего остального. Критичными становятся грамотно построенные интерфейсы, и ооп тут помогает несколько больше нежели функциональное программирование.
Ну и в конце концов, зачем обязательно упираться во что-то одно, можно ведь смешивать подходы, там где это выгодно. Бери плюсы из обоих миров.
nemavasi Автор
20.10.2025 21:55Идея функционального подхода как раз в том, чтобы иметь минимальное количество структур (желательно пересчитываемых пальцами одной руки) и много стандартных функций работы с ними. Тогда предотвращается комбинационный взрыв за счет композиции стандартных функций.
А ООП, которое предотвращает комбинационный взрыв, существенно отличается от текущего мейнстрима в ООП. Есть интересные проекты на эту тему - но тут надо целую статью писать. Понятие объекта там совсем другое.
Грамотно построенные интерфейсы/контракты - это разве требование только ООП?
Что касается вариации с плагинами и кучей всего остального - вот как раз куч хотелось бы избежать. Будем считать, что у нас разный опыт и каждый остался при своем мнении.
Alex_RF
20.10.2025 21:55Автору очень рекомендую перейти в Си-программисты. Да именно Си - который без плюсов, ибо в плюсах начинается полный АД. Для контроллеров или для ядра пишут так. Просто и выверено. И такие специалисты востребованы сейчас. Ну про безумие библиотек и подходов - тут тоже прав. Всегда на проекте может появится крутой перец - который попытается докинуть своих фитч. Он то их знает. Как с такими во времена тотальной демократии бороться, я просто не знаю.
Jijiki
20.10.2025 21:55философски автора понять можно, нужна стабильность, выверенный код, типо зачем математику обновлять, написал 1 раз и всё, а вот в библиотеке Х постоянные обновления.
это тоже Ахилесов вопрос - потомучто реализовывая свой велосипед дойдя до реализации, обязательно что-то да изменится)заметьте Линукс ядро тоже не стоит на месте, да есть код, который не трогают, но там постоянно происходит шлифовка, и получается стабильность от релиза к релизу
эти оба подхода по всей видимости это просто 2 взгляда на задачу
Alex_RF
20.10.2025 21:55Да понять можно. Работал в ЦФТ, там по таким причинам фрейворк для себя написали. Легче не стало. Просто проблемы из внешних перешли во внутренние.
zatim
20.10.2025 21:55В сях сейчас тоже много приколов. Раньше, чтобы мигнуть светодиодиком, пишешь в регистр порта ноль, потом единичку и все работает. А сейчас надо вызывать одну функцию из другой функции, у которой в параметре - непонятные макросы. И с библиотеками тоже беда. Одну подключаешь - не работает, другую подключаешь - не работает, подключаешь третью - о, заработало! Вместо этих танцев вокруг библиотек я бы быстрее сам написал свою функцию, но вот беда, с некоторыми ядрами можно работать только через библиотеки.
Pubert
20.10.2025 21:55Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
alyxe
20.10.2025 21:55Старые версии библиотек в большинстве случаев не удаляют. Хочешь как раньше, загрузи и мучайся. Хочешь быть на волне, адаптируйся, развивайся. Никакого тупика нет, разве что в голове.
guryanov
20.10.2025 21:55Самая большая проблема в слоеной архитектуре. Когда код написан в стиле
func do_something_useful() // что-то делаем do_something_useful_next() // что-то делаемИ так 20 раз тонкой нитью проходит через весь проект, через несколько репозиториев. Очень тяжело разбираться с таким кодом, писать и отлаживать.
logan1337
20.10.2025 21:55Но пока версии инструментов, либ и фреймворков обновляются - бизнесу приходится переходить под новые версии для упрощения написания и ввода новой функциональности, если такие подразумеваются в новых версиях.
В любом случае, мне кажется что тенденция рынка меняется не быстро, а меняется после тотальных обзоров той или иной технологии, когда ввели функциональное программирование для одной области востребовано, то в другой отрасле/компании или бизнес-проекте, до него не дошли или вовсе не слышали.
Думаю, вопрос актуален только для того - куда вы метите.
r00tGER
Уже давно пишу код только для своих пет-проектов, больше нет необходимости соответствовать требованиям отрасли. Никакого спринга, чистые сервлеты, чистый jdbc, никаких миграций - всё ручками прямо в БД, никаких докеров/куберов - гружу руками варники в Томкат... Просто кайфую, что не трачу кучу времени на всякое говно, могу сконцентрироваться на бизнес-логике. Благодаря ИИ, теперь ещё и фронт можно спокойно писать на чистом JS.
zababurin
Осторожнее только с чистым JS. Что бы по скорости написания фронт не отставал от бэка, его тоже правильно писать надо, модулями и архитектуру продумывать не меньше чем на бэке.
Даже 2 модуля как на скриншоте, становятся очень плохо поддерживаемыми, если просто попросить ИИ что то сделать. А нормально приложение таких модулей содержит 20-80 штук
zababurin
p.s. На скриншоте модули написаны на чистом JS с использованием ИИ. И подход примерно похож на то, что описано в статье. Я сейчас думаю, как ускорить процесс можно.