Проблема не в академиках, а в фундаментальном непонимании, что язык такое. Что сокращение кода — не цель. Единственная цель — читабельность кода, быстрая и однозначная. Сокращение этому не поможет, если оно не даёт компактности записи, а оно не даёт. С точки зрения человека пустое пространство — мусор для зрительной памяти, а вот механизмы очистки от этого мусора, мягко скажем, ДРУГИЕ, чем те что предполагает язык. В результате код воспринимается по внешнему виду, и это восприятие доминирует. Читаются совсем другие связи, чем те что будут прочитаны машиной. В результате ошибки не видны.

Появление ошибок в процессе написания кода процесс естественный, большинство из них обычные опечатки и исправляются сразу же. Но не в Скале. В Скале механизм памяти привыкает к потоку паразитно распознаваемому мусору, в результате механизм памяти в принципе считает поток мусора естественным, становясь толерантным к ошибкам.

Примерно так же вы толерантны к ошибкам в естественном языке. Почему и говорю, в эту Скалу осталось добавить неправильные глаголы и нечитаемые согласные, чтобы угробить окончательно. Только в отличие от естественных языков, где людям тупо приходится подчиняться большинству, Скала явно не в этом большинстве. А потому, глупость построения языка не простят. Как вы бы не простили тройную горчицу и красный перец в лазанье, добавленные без вашего запроса, но по мнению повара который считает что так лучше.

В отличие от естественных языков, языки программирования не имеют избыточности. Ошибка будет ошибкой, если ошибки пропускать, код будет дерьмом. А делать из дерьма конфетку — да, это наша профессия, а потому и разбираться в сортах дерьма тоже.

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

имхо статическая типизация была придумана в ЯП как костыль, чтобы правильно выделять и освобождать память. И ведь к этому костылю все настолько привыкли, что считают это необходимостью. Да, она позволяет во время компиляции оптимизировать код и отловить 1% ошибок с неправильной передачей параметров. Но чем более высокоуровневый язык, тем меньше пользы и больше головной боли от статики. Для эрланга это вообще бесполезная если даже не вредная хрень. Хотя диалайзер - отличная штука и часто выручает

Кастуешь UML :)

Типа такого нарисуешь, потом понятней, как писать)

На текущий момент, используя тесты около 8 лет, с разной интенсивностью, могу сказать следующее: Имеет смысл покрывать тестами только переиспользуемый код. Какие-то функции ядра вашего приложения. То, что вызывается из множества мест вашего приложения. Или тестом стоит фиксировать сложно уловимый баг.
Конечный код, который формирует http ответ, или рисует гуй или ещё что-то тестировать смысла нет. И вот теперь почему:
1. Тесты это действительно код, и код которые требует затрат на содержание.
2. Количество тестов растёт. И затраты на них тоже. Часто можно обнаружить что тесты растут быстрее самого приложения. Мы очень редко удаляем код, в тесты удаляются ещё реже. Когда есть тысяча работающих тестов, никто не пойдёт удалить 500 из них. Да, начинается деление на сьюты постоянных и страховочных, но затраты на содержание никуда не уходят.

Ну и самый главный вопрос, сколько тестов писать: ровно столько, сколько нужно для вашей персональной уверенности, с небольшой оглядкой на команду. В идеале тестов должно быть столько чтобы каждый член команды был уверен что всё ок. И это не 100% покрытие Это скорее что-то около 10%. Ядра системы как правила меньше чем куча нашлёпок по интеграции внешних апи, гуи и прочего одноразового кода. Чем чаще что-то меняется тем нужнее там тест(и помните что цена растёт с частотой изменений). А чем больше тестов, тем выше цена поддержки. Таким образом стоимость поддержки тестов на часто меняющуюся систему растёт, от времени, сверхлинейно, и никогда не имеет тенденций к снижению.

Хз, что вы там настраиваете, обычно процесс ознакомления с софтом == 2 недели + 2 недельки немного поковырять что-то, не больше...

чтобы хорошо программировать на scala надо убить лет 10 на ассемблере

Ещё интересно узнать ваш опыт программирования.

Всё-таки DI, IoC, синглтоны, графы, гарантии — это всё-таки понятия из области знаний Джуниор-программистов. А программирование на уровне структур данных, минимальная абстракция, простота, иммутабельность, робастность системы, понимание задачи клиента — это входит в лексикон разработчика на году 10—15-м коммерческой работы.

Возможно, из-за этого тоже недопонимание в треде.

«Структуры данных» — я не имел в виду уровня интервью для приёма на первую работу типа «инвертируй красно-чёрное дерево». Я писал про структуру данных системы: архитектура, преобразования, зависимости, выбранные ограничения и пределы абстракции.

Всегда смешно с программистов фронтенда, которые молятся на нетипизированный на стадии компиляции код.

Вы литералли берёте статически типизированные данные со статически типизированной Java на бэкенде, упакованные в статически типизированный Protobuf, переданный по сети, динамически типизированным протоколом HTTP, меняете два поля и отправляете назад в статически типизированную SQL базу данных через статически типизированный запрос.

Просто абсолютный ноль рефлексии у чуваков.

людям обычно больше 5 модулей поднимать не надо

Не видел таких исследований. 5 — условная цифра. Её, в принципе, должно хватить на любой микросервис. Но объём команды для динамически типизированных языков (js, clj, python, groovy и пр.) меньше, чем для статически типизированных. Потому что довольно много работы выполняет компилятор (транспилятор), код проще сопрвождать — система типов самодокументируема, хотя бы на уровне структуры данных.

Просто реально, сделать правило: сколько компонентов нужно поднять для каждого теста, минус два, столько огурцов в жопу должен взять архитектор на квартальном отчёте.

И посмотреть, потребуется ли DI после этого.

А вообще, если вы, как и я, вляпались зачем-то в Java экосистему, особенно энтерпрайзную, и начинаете все больше и больше испытывать отвращение к программированию, все острее чувствовать абсурдность происходящего и бояться за свой рассудок, помните:

С вами все в порядке. Вы молодец и все делаете правильно. Проблема в консерватории, ее уже не починить.

Также помните, что рядом полно нормальных, адекватных людей и они создают куда более приятные экосистемы. Такие, в которых люди не соревнуются в том, кто кого переусложнит и у кого Hello World займет больше строчек, сервисов и ресурсов. В которых проекты измеряются не миллионами строк кода, а десятками тысяч, и ни в чем не уступают по функционалу. Проекты, которые зарабатывают миллионы долларов и меняют мир, ничуть не менее «серьезные», вопреки мнению тех самых Джавистов.

И туда всегда можно перейти, найти свое счастье и душевное спокойствие. Я в свое время сбежал на Питон, потом на Erlang, и в конце концов на Clojure.

В любом случае, бежать к адекватным людям и здравому смыслу было лучшим решением в моей жизни. Рекомендую.

На этом неделя Java в канале официально объявляется закрытой, и мой гештальт тоже. Надеюсь, в следующий раз услышу о ней не раньше чем через еще 10 лет.

P.S. Если вам нормально — ну и классно, просто проигнорируйте этот пост
P.P.S. JVM все еще нежно люблю, пост исключительно о java как экосистеме
P.P.P.S. Убрал языки, про которые я знаю только понаслышке. Там тоже может быть хорошо, но обещать не могу

Не так уж и сложно, кстати, я на чистый javac как раз перешел. curl и вперед. Проект собирается полностью быстрее, чем мавен только запускается

Перестаем ныть и переходим к конструктиву. В комментах к прошлому посту спрашивали, как же починить проблему логирования, когда есть 15 разных библиотек?

Действительно, логирование штука очень неудобная, в первую очередь потому что библиотеки. Каждая библиотека выбирает свой фреймворк, вы выбираете 15 библиотек (это еще по-божески) и привет, у вас в приложении 15 разных логгеров. Вот что с этим делать?

Давайте применим дизайнерское мышление и проанализируем ситуацию. Сторонние библиотеки не работают, потому что кто-то нет-нет да и напишет новую, а какой-нибудь глупец соблазнится на сиюминутные преимущества и заиспользует ее, проигнорировав общую картину. То есть сразу нет.

Методом исключения получаем, что логирование должно быть в стандартной библиотеке языка. Иначе никак.

Кстати, в Java логирование _есть_ в стандартной библиотеке, но проблема осталась. Почему так? Почему никто не переехал на java.util.logging? У меня две версии, и подозреваю, они сыграли обе.

Первая — потому что мало сделать новый логгер, надо еще перестать использовать старый. В программировании вообще недооценен процесс возвращения и переделывания того, что было сделано, а зря. Дописывание — да, за милую душу, а вот переписывание не любят. Хотя я, например, обожаю переделывать и переписывать, потому что перфекционист и с первого (и даже со второго) раза нормально сделать не могу (нормально по моим меркам, по меркам индустрии у меня и с первого раза очень неплохо получается).

Вторая версия — что java.util.logging вышел куцым по функциональности в сравнении с «настоящими» логгерами. Мне-то как раз это нравится, а вот Java-программистам, подозреваю, не зашло.

И тут я выскажу радикальное мнение: по мне, так логгинг должен быть максимально куцым. Тот же log4j может: срать в несколько файлов, обкусывать файлы, менять файлы в зависимости от дня недели, фильтровать записи, форматировать записи, грузить конфиги, перезагружать конфиги, варить кофе^W^W. Это полноценный фреймворк, на настройку которого можно потратить не один день.

Что же в этом плохого? Опять же, давайте посмотрим на общую картину (дизайн мышление, помните?). Если логгер умеет делать так много, это значит что он будет делать так много, то есть, все эти настройки будут гвоздями прибиты к вашему приложению.

А это не задача вашего приложения — решать, где я хочу видеть логи, сколько и как часто. Генерить логи — да, пожалуйста, но фильтрация, хранение, организация — это явно другой уровень и решаться должно снаружи. Когда это делается изнутри, это негибко, это лишний функционал и плохая интеграция. Будете в следующий раз пить аспирин после настройки log4j — задумайтесь об этом. 12 factor apps всем, пацаны!

Так что же, как в итоге должен выглядеть идеальный логгер? Идеальный логгер — это println.

злеер - хуета с убогим апи

просто код в месиво превращает