Сегодня я видел небольшой самодельный ERP (много мелких крудов типа оформления отпуска) на скале, с Кафкой и Кассандрой. Там есть блоги. На скале.

А вчера — высоконагруженное e-commerce решение с ядром на битриксе.

Не могу решить, что мне нравится больше 👀

Мой учитель по психотерапии говорит, что почти в каждом терапевте есть мазохистическая часть личности, иначе в профессии делать нечего. В IT-аудите — похожая история.

Ещё круто, что как не издевайся над здравым смыслом — все равно ведь работает и даже деньги зарабатывает. Мир шире и богаче, чем я себе представлял.

https://www.hackster.io/news/the-lisperati1000-is-a-cyberdeck-terminal-dedicated-to-lisp-programming-bb564f2ffcff

If you’re new to coding and want something easy to use, Python is great. For performance and capability, it’s hard to beat programming in C. But if you need some complex algorithms — particularly algorithms that do a lot of heavy mathematical lifting — then Lisp is the ideal choice.

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

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

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

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

По той же причине я против засилия синтаксического сахара и в 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 и пр.) меньше, чем для статически типизированных. Потому что довольно много работы выполняет компилятор (транспилятор), код проще сопрвождать — система типов самодокументируема, хотя бы на уровне структуры данных.