Моя гипотеза, что понв плох примерно тем же, чем радфем.
Есть херова туча фриков, которые берут свои собственные проблемы, негативный опыт и инсекьюритис и втаскивают их как часть идеологии.
Т.к. все фрики фрикануты по-своему, сабсет ебанатики, включаемой в результирующий концепт сильно различается, и они регулярно срутся друг с другом, считая истинным говном своё говно, обсирая чужое говно.
Итого соваться в понв себе дороже, лучше назвать другими словами, иначе тебя обосрут и сторонники и противники.

В Яндексе появились армяне. На этом можно считать, что технологической компанией Яндекс быть перестал.

Книги Кока пересекаются с книгой Scala with cats ?

И в продолжение:
сейчас реатом не имеет четкой концепции и сейчас находится в её поиске. https://github.com/artalar/reatom/projects/1 Собираются сделать futures. но это немного не подходящая концепция для жс. В общем там ещё слишком много работы для устаканивания. А в стандартной поставке первой версии, слишком много неконсистентностей.

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

Теоретически, тимлид и СТО могут уметь программировать и даже делать это время от времени, особенно если обычно вреда от них больше, чем пользы, и чем больше они занимаются программизмом - тем меньше вредят.
Главное, чтобы это не мешало работе.

Даже более того, компании, в которых основа зарабатывания денег - именно программизм, скорее в меньшинстве.
И горе, если СТО - это программист-переросток, а компания живёт не с разработки.

Худшие из виденных мной СТО были из программистов.
Лучшие - никогда не программировали.

Удивительно, какой высокий процент людей до сих пор живёт в заблуждении, что бзнес-задачи решаются программированием…
Впрочем, возможно они просто сами в анамнезе программисты и уже одни только жтим фактом своего недопонимания уже прекрасно иллюстрируют мой тезис, что из программистов - худшие СТО.

Какой же это тру СТО-девелопер, который себе хотя бы сам телеграм клиента из исходников не скомпилировал...

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

Сейчас, посмотрев на 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 решениями (вместо известных практик), и той пресловутой формалистской узостью применения инструментов. К сожалению, все еще существует некая убежденность академической части хаскеллистов в том, что если не формализовано - значит, не существует, или плохое. Но это лишь мнение. Ведь практика, как мы знаем, сильно расходится с теорией.

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