Фьючки больше монады чем колбеки

Сейчас, посмотрев на Idea, и на Java-тулинг, и на Android Studio, я понимаю, что это принципиальное противоречие: в самой идее IDE заложена сложность, кривость и неудобство.

Чистота архитектуры достигается желанием вмещать весь код в экран монитора. Я так уже пару ненужных бизнес функций выкинул из проекта

Солид достаточно абстрактный. Например какой уровень должен быть у responsibility или сегрегации? С разных сторон можно увидеть и отступление от солид и его выполнение

В этот четверг (28.05) в 19-00MSK состоится доклад " Context - библиотека управления состоянием системы в Clojure."

При создании новой системы разработчикам необходимо решить, каким образом они будут управлять состоянием ( state) системы. Для этого уже есть несколько устоявшихся подходов в виде библиотек mount, component.
Библиотека context предлагает еще один способ управления состоянием системы, в более простой форме.

Докладчик: Михаил Ананьев @mike_ananev

Ссылка на Zoom появиться за 5 минут до встречи.

Подробное описание кейса. Как product owner я предоставил команде выбор: или пишите на любимой java или я вас могу переучить clojure. Они подумали и решили что java, аргументировав тем что быстрее надо фичи выводить, а обучение новому языку потребует времени. Ну ок, мое дело бэклог и вижн продукта. Начались спринты: 1,2,3,4 .. После 4 спринта стало окончательно ясно, что чуваки вместо продукта делают церемонии в java: пилят ORM, делают обертки, фабрики и прочее, что принято в java мире. На каждую маленьккую задачу рождалось тонны кода, который еще внезапно не многопоточный, мутабельный со всех строн, на что просились дополнительные ресурсы. Это не только у меня. В соседних стримах по платформам банка это видно. Но хуже всего было то, что я тратил 1 день clojure, чтобы показать им, что они должны были сделать за спринт всей командой. Кроме шуток, после их объяснения почему что-то не получилось, я показвал им сам демо и встречал это полным молчанием. Как-то только от javaистов требовалось сделать что-то не как в их любимом фреймворке, то сразу стекланные глаза и завышение оценок в 2-3 раза.
После 4 спринта им было предложено прекратить тратить деньги организации "делая java" и переучиваться на clojure или уйти. Да, ушла ровно половина. И это пошло на огромную пользу продукту. Во-первых остались только мотивированные на создание продукта люди, а не на их java. Во-вторых набор новых высокомотивированных людей повысил общую атмосферу работы до дружеской и да еще писать на Clojure. Я согласовал затраты с боссами и 1,5 мес мы "жгли" деньги на обучение Clojure ребят. Уже после 1х спринтов вчерашние java'исты стали во-первых выводить фичи, а во-вторых они признавали что все получается заметно короче, а главное код проще.

Важное уведомление для новичков в Haskell.

Нужно относиться скептически ко всему, что говорится или утверждается в этом чате. Хаскеллисты делятся на "академиков" и "практиков". У первых проявляется узкий формалистический подход. Они могут утверждать, что какая-то вещь плоха или неприменима, ведь вот же есть пейпер, где так написано. Однако в пейперах чаще рассматривается узкая задача, с необходимыми исследователю ограничениями, потому что цель пейперов - в математических выкладках, для которых важны строго определенные начальные положения. На практике же задачи либо не требуют использовать инструмент так узко и без фантазии, либо ограничения вполне допустимы, либо можно применить какой-нибудь трюк, который академикам покажется "нечистым" и "небезопасным", из-за чего они его и не рассматривают вовсе. Это значит, что утверждения в этом чате о неприменимости все еще следует проверять экспериментом, не вычеркивать инструмент из своего набора, пока не найдено, что в вашей задаче он действительно неприменим. Также очень скептически стоит относиться ко всем околоформальным беседам про морфизмы, продвинутую магию на типах и прочий матан. Эти беседы ведет все та же академическая часть хаскеллистов, и они более всего заметны, что оставляет ощущение, что Haskell - сложный и непонятный. Однако на практике этот "высокий штиль" применяется очень редко, потому что в целом может вредить проекту больше, чем помогать: плохой поддерживаемостью, никому неизвестными ad-hoc решениями (вместо известных практик), и той пресловутой формалистской узостью применения инструментов. К сожалению, все еще существует некая убежденность академической части хаскеллистов в том, что если не формализовано - значит, не существует, или плохое. Но это лишь мнение. Ведь практика, как мы знаем, сильно расходится с теорией.

да нахуй оно не надо, можно просто взять рантаймовый диай и проверять корректность графа тестами

хаскелисты есть?

В абстрактном идельном сферическом объектно-ориентированом мире идентификаторы объекта нужны только для складывания/изятия из базы данных.

В конкретном реальном тоже.

Пиздон - худшее решение для мл

ты раб компилятора

ты надеюсь понимаешь что тот кто не знает скалу это не прочтет?

Любой код на скале нечитаемый из коробки.

в системно ПО нет возможности надеяться что компилятор за тебя все заинлайнит