Java, быдлокодинг, chatGPT

Несколько лет назад наткнулся на годный текст про Java. Найти оригинал можно где-то там. В годину смуты chatGPT (всех программистов уволят) и расцвета быдлокодинга (дешево и быстро) текст весьма актуален. Немного поправил, откорректировал (убрал мат), отформатировал, кое-где перефразировал, что-то изменил, и вот результат, который можно опубликовать.

И все же самая большая проблема в быстродействии, это не тормоза джавы, а тормоза-быдлокодеры. С одной стороны, новомодные штуки типа ORM до ужаса расхолаживают народ, который вообще перестает думать о малейшей оптимизации, и считает память бесконечной большой, а процессор бесконечно быстрым. Потянуть тысячи объектов из базы через ORM, чтобы посчитать какую-то простую статистику? Легко! Точно так же, ни один быдлокодер не занимается мало-мальскими алгоритмическими оптимизациями, поэтому инициализировать соединение с БД по несколько раз за один запрос или инициализировать какую-то ерунду на тэгах каждый раз, когда вызывается тэг в рамках генерации страницы — это общепринято. Куча уровней абстракций и простота языка позволила вырасти целому поколению идиотов, которые кодят быстро, но работает оно потом медленно. С другой стороны, толпы не менее дебильных индусов сбивают цену, и заказчик не хочет переплачивать за оптимизацию. Зато потом такие индусо-поделки приходят на рефактор, после которого, как правило, памяти жрется в 10 раз меньше, а работает оно в 5 раз быстрее.

Тем не менее, регулярное битье по рукам быдлокодеров заставляют джаву работать в разы быстрее. Если бьет реально грамотный разработчик, который начинал с древних машин, где память была дорогой, а процессор — медленным, скорость джавы возрастает до межгалактических размеров. Улучшение по параметрам в разы после грамотного «воспитания» — для быдлокодеров типично.

Проблема джавы в том, что она обманчиво проста. На первый взгляд всё элементарно, но на самом деле, в языке куча подводных камней. Особенно это касается оптимизации: правильно работающий код может работать в дофига-и-более раз медленнее, чем мог бы, из-за какой-нибудь не принципиальной на первый взгляд мелочи вроде выбора типа коллекции. Поэтому хороший джавакодер должен знать, как работает любая нативная функция, а не тупо использовать её как черный ящик. Другой вопрос, что это подразумевает необходимость курить исходники и мануалы, курить много, долго и муторно. А зачем, если «и так работает»? Вот и получается, что хороший язык присмотрели быдлокодеры, из-за которых слово «джава» стало чуть ли не ругательством.

«Няшная сишка» тоже чувствительна к: «…не принципиальной на первый взгляд мелочи вроде выбора типа коллекции», да и вообще, она чувствительна ко всему. Простой пример — синхронизация потоков. В «няшной сишке» нужно будет использовать нативный интерфейс ОС, или библиотеку типа pthreads, a специфика языка заставит хоть на сколько-нибудь изучить вопрос «что такое мьютексы с семафорами». А в джаве можно просто взять и «наделать» слово synchronized везде, где левая пятка положит — и при унитарных тестах это вполне себе будет работать. А при стрессовых интегральных — тормозить до ужаса и сыпать исключениями о зависших threads. Обычно интегральные тесты проходят на завершающих этапах разработки, когда и выясняется, что нужно очень много переделывать, вот из-за такой ерунды.

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

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