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

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

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

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

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

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

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

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

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

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

Скала - такой же хлам для взял-положил как и 100500 других языкоа

Ну не нравится мне Котлин, get over it
- непонятно в чем профит в рантайме
- проще выбрать один jvm язык и писать на нем на автопилоте, а 99% либ всё равно на джаве
- месседжи от компилятора средненькие по понятности, типа infer не срабатывает там где норм в джаве и сидишь думаешь
🙂
- когда пишешь на джаве точно знаешь во что это скомпилится и как будет воспринято c1/c2, не думаешь что дешевле/дороже и тд
- кадры найти проще
Slightly smiling face
- в целом что джава, что котлин - всё одно, а для сахара я могу и тортик поесть)
- если не юзать всякие крутые конструкции языка, то в чем смысл
- а если юзать, то их надо мерить и изучать кишки, типа ‘here we go again’,до этого была скала и люди тем же самым занимались, после котлина еще какой-то jvm-based язык будет
- Вся статика сделана как-то странно, непонятно в чем профит и зачем так
Slightly smiling face
- Взрослым язык становится не тогда, когда ‘мы на проде у чуваков Х, поэтому юзайте нас’, а когда много людей в своих докладах и статьях померили перфоманс всех конструкций, когда есть парсеры (не нашел для котлина аля JavaParser), когда точно знаешь что bytebuddy отработает
Люди в целом с джавой делают очень много извращений и они к ним привыкли и сделали для этого инструменты. И шильдик ‘поддерживаем котлин’ на них далеко не всегдп есть
Slightly smiling face

(с) https://twitter.com/DrEdwardHyde/status/1267608226687782913

Даже википедия