Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.
Когда трава была зеленее, когда мы сильно боролись за каждый такт процессора, тратя на это наше время, которое мы тогда не очень ценили, все было в какой-то мере проще.
Если тебе нужна была фича, ты ее делал сам.
Или ты искал уже реализованную фичу, и прикручивал к своему коду.
Больше времени уходило на поиск. Не всегда можно было найти.
Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, �� ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё ни разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.
Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.
Потом конечно ты находишь в документации к конкретной версии фреймворка новый способ отключения ненужного тебе функционала, но .... Ты теряешь время. И твои предыдущие знания обесцениваются.
И так каждый раз. Количество свистоперделок, которые надо отключать, растет. Новые знания, которые ты приобретаешь, не понадобятся. Когда ты будешь пытаться применить их снова, все изменится.
Ощущаешь себя плотником, который каждый раз обрубает все более и более корявые заготовки, из которых надо что-то сделать.
Ты хочешь простых и предсказуемых деталей, из которых сможешь собрать полезную вещь. Но тебе каждый раз выдают новые и все более кривые детали, с кучей дополнительного функционала.
Многие из них зависят друг от друга, причем от конкретных версий. А от других версий ломаются.
Зато стильно, модно, молодежно.
И вместо усиления знаний по действительно важным вещам и принципам приходится копаться в разных версиях одного и того же фреймворка.
А таких фреймворков все больше, и они все более и более обрастают новыми возможностями. Меняется не только синтаксис, но и семантика.
Даже простой, как автомат Калашникова, SQL правдами и неправдами пытаются заменить на что-то другое: на xml из liquibase, jql, hsql и т.д. В языке появляются новые классы. Старые классы меняются. Каждый из классов все более представляет собой минибиблиотеку, причем изменяющуюся во времени.
Это ад сборочного программирования.
Создавая ООП, мы пытались разделить код на более простые объекты с небольшим количеством методов в каждом. Что же мы получили? В каждом объекте 100500 методов. И самих объектов 100500. И все надо знать, чтобы не писать велосипед. Но это декартово произведение, комбинаторный взрыв. Нет ничего удивительного, что ИИ будет писать лучше и компактнее простой код. Он просто больше кривых деталей держит в оперативной памяти чем любой человек. Даже на самом низком начальном уровне стандартной библиотеки языка Java для определения числа элементов мы имеем length, length(), size().
Это тупик.
Уж лучше иметь меньше сущностей, но более универсальных, с более универсальными методами. Сделать один метод count, который будет работать со всеми коллекциями, что бы они не представляли.
Мы прекрасно храним любые данные и параметры любых фреймворков в json и yaml. Зачем же мы делаем столько классов и объектов, чтобы работать с данными, которые можно представить в одном и том же виде?
Лучше иметь несколько структур данных и несколько сотен постоянных функций над ними. Постоянных - т.е. они не будут меняться из класса в класс, из объекта в объект. Нужно только разобраться один раз.
Здравствуй, функциональное программирование. Какой же я дурак, что так не ценил тебя.
Надо сворачивать. Пока не поздно. Но может, мы уже опоздали.
