Пацаны, там .NET 5.0 релизнулся

Как я уже ранее говорил, Котлин, учитывая такие фичи, как силед классы (которые в действительности можно назвать ГАДТ), инлайн-классы и дата-классы, смещает скоуп проектирования приложений с т.н. рич-модели, где модулярность достигается за счёт связей между компонентами наследованием, до анемичной модели, где граница данные-действия выражена чётче. Но если в первом случае у вас есть интерфейсы и вся инфраструктура, связанная с ними, то во втором случае ничего этого нет, потому что максимум, на который способен Котлин - маленькие беспомощные дженерики.
Вместе с тем, интерфейсы, будучи неспособными налагать контракты на конструкторы, не могут предложить достаточно возможностей для анемичной модели, поскольку последняя зачастую требует иммутабельности (в этом, собственно, и заключается её профит). Пример -https://t.me/pofftop/247905

Мой поинт в том, что хкт+тайпклассы - это та необходимая фича, которая сделает анемик модель по-настоящему мощной, а не странной маргинальной хуетой, в которой нужно много бойлерплейтить.
Ещё один пример - мои дельфины (github.com/happy-bracket/dolphins), где есть инфраструктура для т.н. коэффектов. Они не идут ни в какое сравнение с коэффектами в рефрейме, потому что кложура динамически типизирована. Как бы сильно динамическую типизацию не хейтили, у неё есть определенное преимущество - там, где статической типизации нужны абстракции, динамически типизированный язык предоставляет их просто так, в счёт мамы разработчика. И когда кложуристам нужно просто бахнуть dispatch :jopa, у меня в дельфинах нужно будет написать feature.mutate(IdMutation(event)), вместо просто feature.mutate(event), при условии, что Mutation предоставляла возможность сконструировать себя из event

Более того, как я ранее уже говорил, хкт - это естественное развитие дженериков. У лямбда-куба есть только три измерения, и любой язык всегда окажется на какой-то из граней, и я не понимаю, зачем идти замысловатым тернистым путём (как, например, декораторы), если вы все равно придёте к системе Ф-омега, просто взаимодействие фич заспавнит дополнительную сотню ишуй на ютреке? Разработчик может придумать бесконечное количество типов с дыркой, но в этом не будет никакого смысла, потому что для каждого конкретного взаимодействия с другим типом ему нужно будет писать пачку специализаций. Это ведёт только к роллбеку обратно в мутабельные классики и рич-модель, но если этого вы хотите - флаг в руки, реально

Конкретный пример:

interface List<T> {
 fun add(item: T)
}

Прекрасно абстрагирует добавление итема, любая имплементация листа сможет с этим делать что захочет, но

fun ImmutableList<A>.add(item: A): ImmutableList<A> = ???

Уже не выглядит так внушающе, правда? А абстрагировать никак нельзя(
И это не камень в огород стдлибы (хотя мог бы быть), это демонстрация возможностей (или невозможностей) разработчиков на котлине использовать возможности котлина хорошо

И есть только один способ реализовать хкт, точно так же, как есть только один способ реализовать дженерики (я не говорю о деталях реализации), потому что, ну, это те же дженерики, просто сильнее
И я не понимаю вот этого "нет юзкейсов", "не подходит идеологии котлина" по причинам, озвученным выше, алсо, потому что у котлина идеология - feature by request. Короче, если котлин не умрет через 5 лет, увидимся через 5 лет, когда Котлин будет прибивать хкт гвоздями

П.с.
Я, разумеется, даже не говорю об абстрагировании эффектов, потому что coroutines is the way

ещё пара переформулировок и получится keep

https://t.me/TheDailyKotlin/295 блин как же круто сделали

Как я уже ранее говорил, Котлин, учитывая такие фичи, как силед классы (которые в действительности можно назвать ГАДТ), инлайн-классы и дата-классы, смещает скоуп проектирования приложений с т.н. рич-модели, где модулярность достигается за счёт связей между компонентами наследованием, до анемичной модели, где граница данные-действия выражена чётче. Но если в первом случае у вас есть интерфейсы и вся инфраструктура, связанная с ними, то во втором случае ничего этого нет, потому что максимум, на который способен Котлин - маленькие беспомощные дженерики.
Вместе с тем, интерфейсы, будучи неспособными налагать контракты на конструкторы, не могут предложить достаточно возможностей для анемичной модели, поскольку последняя зачастую требует иммутабельности (в этом, собственно, и заключается её профит). Пример -https://t.me/pofftop/247905

Мой поинт в том, что хкт+тайпклассы - это та необходимая фича, которая сделает анемик модель по-настоящему мощной, а не странной маргинальной хуетой, в которой нужно много бойлерплейтить.
Ещё один пример - мои дельфины (github.com/happy-bracket/dolphins), где есть инфраструктура для т.н. коэффектов. Они не идут ни в какое сравнение с коэффектами в рефрейме, потому что кложура динамически типизирована. Как бы сильно динамическую типизацию не хейтили, у неё есть определенное преимущество - там, где статической типизации нужны абстракции, динамически типизированный язык предоставляет их просто так, в счёт мамы разработчика. И когда кложуристам нужно просто бахнуть dispatch :jopa, у меня в дельфинах нужно будет написать feature.mutate(IdMutation(event)), вместо просто feature.mutate(event), при условии, что Mutation предоставляла возможность сконструировать себя из event

Более того, как я ранее уже говорил, хкт - это естественное развитие дженериков. У лямбда-куба есть только три измерения, и любой язык всегда окажется на какой-то из граней, и я не понимаю, зачем идти замысловатым тернистым путём (как, например, декораторы), если вы все равно придёте к системе Ф-омега, просто взаимодействие фич заспавнит дополнительную сотню ишуй на ютреке? Разработчик может придумать бесконечное количество типов с дыркой, но в этом не будет никакого смысла, потому что для каждого конкретного взаимодействия с другим типом ему нужно будет писать пачку специализаций. Это ведёт только к роллбеку обратно в мутабельные классики и рич-модель, но если этого вы хотите - флаг в руки, реально

Конкретный пример:

interface List<T> {
 fun add(item: T)
}

Прекрасно абстрагирует добавление итема, любая имплементация листа сможет с этим делать что захочет, но

fun ImmutableList<A>.add(item: A): ImmutableList<A> = ???

Уже не выглядит так внушающе, правда? А абстрагировать никак нельзя(
И это не камень в огород стдлибы (хотя мог бы быть), это демонстрация возможностей (или невозможностей) разработчиков на котлине использовать возможности котлина хорошо

И есть только один способ реализовать хкт, точно так же, как есть только один способ реализовать дженерики (я не говорю о деталях реализации), потому что, ну, это те же дженерики, просто сильнее
И я не понимаю вот этого "нет юзкейсов", "не подходит идеологии котлина" по причинам, озвученным выше, алсо, потому что у котлина идеология - feature by request. Короче, если котлин не умрет через 5 лет, увидимся через 5 лет, когда Котлин будет прибивать хкт гвоздями

П.с.
Я, разумеется, даже не говорю об абстрагировании эффектов, потому что coroutines is the way

А чо там, кто следит, в цио хттп2 завезли? =)

Красиво change loge сделаны

У меня есть даже не ссыль, в паста!

@happy_bracket Итак, сейчас 7 утра субботы, у меня, наконец, есть настроение ответить тебе подробно, почему я не люблю HKT и весь "тру ФП", который идёт от хаскеля в другие языки, причём идёт в виде крестового похода, объявляя всё остальное ересью, словно существует один и только один способ решения задачи, независимо от задачи.
Но перед тем, как я перейду к ФП и, тем более, "тру ФП", я упомяну ООП с его вездесущими паттернами, адепты которых вели (а некоторые и сейчас ведут) себя похоже на сегодняшних адептов "тру ФП" и говорят о том, что паттерны - наше всё и только через паттерны можно писать расширяемый код. Доходило даже до того, что некоторые адепты code shape в ФП языках обозвали паттернами ¯\_(ツ)_/¯. Я, разумеется, выступаю против подобного. Потому что паттерны, как бы не были они хороши для унификации, а именно, унификации кода на разных языках (то есть код на смолтолке, плюсах и джаве будет отличаться только синтаксисом), оставляют за бортом кое-что важное. И это кое-что важное, которое я назову языковыми идиомами - то, что отличает _идеоматический_ код на одном языке от _идиоматического_ кода на другом. Отсюда и название - "идиомы". Они лежат где-то между синтаксисом и семантикой. То есть, одну семантику можно выразить разными идиомами на разных языках. Сравни код на шестой джаве и котлине 1.0:
ArrayList<Integer> list = new ArrayList<Integer>();
for (int i = 0; i < limit; i++) {
   list.add(i * i);
}
и
val list = (0 until limit).map { it * it }
они делают одно и то же, то есть имеют одну семантику. Но они отличаются также больше, чем синтаксисом.
Поэтому, кстати, тут @noraltavir пропесочил мой
while(
   when (val c = peek()) {
       c.isSpace() -> {
           pop()
           true
       }
       else -> false
   }
);
потому что этот цикл, будучи синтаксически и семантически корректен, не идиоматичен.
Идиомы - это то, что отличает один язык от другого. Поэтому, кстати, многие гоферы с годами опыта на го не понимают, зачем нужны дженерики в го. Потому что у них есть свои идиомы. Они прекрасно понимают, зачем нужны дженерики в других языках. Но зачем в го - нет. После появления дженериков появятся новые идиомы, а старые либо пробразятся, либо исчезнут, как было с джавой после появления в ней сначала тех же дженериков, а потом и лямбд со стримами.
Требовать от языка идиом другого языка, без попыток разобраться в его идиомах - это то, что я называю фанатизмом. Arrow пришли, наконец, к тому, чтобы не идти против языка, пытаясь натянуть чужие языковые идиомы, в данном случае IO, а взять существующие. В данном случае - suspend. Я, кстати, поэтому спросил тебя, не попутал ли ты HKT и IO. Потому что то IO, что есть в Arrow, на раз заменяется suspend. Удивительно, как проще становится код, если не пытаться натянуть идиомы из другого языка, а использовать уже существующие. Что-то мне подсказывет, что подобным образом можно избавиться также от Kind.
Ещё раз, я прекрасно понимаю пользу HKT... в скале и хаскеле. В котлине - пусть сначала идиома suspend получит большее распространение, за пределами асинхронщины. Я как раз топлю за multifire continuations, которые нафиг не нужны в асинхронщине, но полезны в других областях.
Наконец, изучение языка - это не только изучение синтаксиса, это ещё и изучение идиом. И попытки использовать идиомы другого языка - распространённая ошибка новичков, которую они допускают в силу приобретенных привычек и которая ведёт к фрустрации, потому что идиомы не те, к которым они привыкли. Поэтому программирование на этом языке кажется _странным_. Требуется время, чтобы переделать свои привычки и использовать более подходящие идиомы.
Поэтому, кстати, нет плохих и хороших языков. Есть языки, идиомы которых _нравятся_ и языки, идиомы которых _не нравятся_. Мне, например, _не нравятся_ идиомы го и питона. Но я в восторге от идиом лиспа и перла. Возможно, просто котлин не для тебя и тебе больше подходит скала. Но котлин != скала и не стоит пытаться переиспользовать идиомы из скалы в котлине или жаловаться на то, что идиомы другие, _плохие_.

Вас пинают в то что идиомы хреновые