https://habr.com/ru/company/tinkoff/blog/147759/

ПОНВ. НАЧАЛО.

Поскорее бы добавили дженерики в ПХП и он станет как Джава

зачем тебе персистентная очередь? твой сервак может уборщица из розетки вытащить?

Ребят, опытные скалисты - подскажите, есть ли жизнь с ООП в мире скалы ? Де гоус гонит всех оопшников из скалы в Котлин, в тоже время Мартин Одерски придерживается другой точки зрения.
Мне направится ООП в силу простоты (gof-паттерны, orm, di)- они хорошо разработаны индустрией.
В тоже время ФП хорош для конкурентного программирования , например для организации конвейера данных.

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

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

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

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

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

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

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

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

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

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

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

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

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