Size: a a a

Programming Offtop

2020 October 27

VP

Vladimir Petrakovich in Programming Offtop
Кирилл Романенко
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-shared-flow/
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-state-flow/

В принципе то, о чём говорил Скобка: дизайн начинает плыть под натиском фичей.
Оч забавно читать все эти нюансы в стиле "это как бы flow, который изначально дизайнился как холодный, но вот этот горячий. И коллект тут другой, а ещё toList() засуспендит навечно".😍
Только речь про язык шла, а не про какую-то либу, пусть и от JB
источник

VP

Vladimir Petrakovich in Programming Offtop
Это всё равно что писать "джава говно потому что rxjava говно"
источник

с#

саша сок #KotlinGang... in Programming Offtop
Vladimir Petrakovich
Это всё равно что писать "джава говно потому что rxjava говно"
ну разница всё таки есть. корутины с какой-то стороны можно назвать частью языка
источник

с#

саша сок #KotlinGang... in Programming Offtop
Кирилл Романенко
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-shared-flow/
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-state-flow/

В принципе то, о чём говорил Скобка: дизайн начинает плыть под натиском фичей.
Оч забавно читать все эти нюансы в стиле "это как бы flow, который изначально дизайнился как холодный, но вот этот горячий. И коллект тут другой, а ещё toList() засуспендит навечно".😍
и какие проблемы с toList()?
если это бесконечный флоу то это вполне логично.
источник

VP

Vladimir Petrakovich in Programming Offtop
саша сок #KotlinGang
ну разница всё таки есть. корутины с какой-то стороны можно назвать частью языка
Корутины - это и есть часть языка, но kotlinx.coroutines - это не более чем либа, которая идёт к нему впридачу. Про JavaEE никто же не говорит, что это часть языка? Хотя, я думаю, и такие есть.
источник

VP

Vladimir Petrakovich in Programming Offtop
Я это всё к тому, что наговнячить в либе куда менее страшно, чем сделать это в языке.
источник

с#

саша сок #KotlinGang... in Programming Offtop
Vladimir Petrakovich
Я это всё к тому, что наговнячить в либе куда менее страшно, чем сделать это в языке.
тут +
источник

AN

Alexander Nozik in Programming Offtop
саша сок #KotlinGang
и какие проблемы с toList()?
если это бесконечный флоу то это вполне логично.
Собственно с бексконечным Sequence та же история.
источник

с#

саша сок #KotlinGang... in Programming Offtop
Alexander Nozik
Собственно с бексконечным Sequence та же история.
ну если уж очень лист нужен, никто не мешает
.take(1).toList() сделать
источник

AK

Anton Korotkikh in Programming Offtop
Ilmir
У меня есть даже не ссыль, в паста!

@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, которые нафиг не нужны в асинхронщине, но полезны в других областях.
Наконец, изучение языка - это не только изучение синтаксиса, это ещё и изучение идиом. И попытки использовать идиомы другого языка - распространённая ошибка новичков, которую они допускают в силу приобретенных привычек и которая ведёт к фрустрации, потому что идиомы не те, к которым они привыкли. Поэтому программирование на этом языке кажется _странным_. Требуется время, чтобы переделать свои привычки и использовать более подходящие идиомы.
Поэтому, кстати, нет плохих и хороших языков. Есть языки, идиомы которых _нравятся_ и языки, идиомы которых _не нравятся_. Мне, например, _не нравятся_ идиомы го и питона. Но я в восторге от идиом лиспа и перла. Возможно, просто котлин не для тебя и тебе больше подходит скала. Но котлин != скала и не стоит пытаться переиспользовать идиомы из скалы в котлине или жаловаться на то, что идиомы другие, _плохие_.
какая охуенная мысль, сейчас уже почти протрезвел и призадумался сильно
источник

AM

Andrew Mikhaylov in Programming Offtop
Кирилл Романенко
Тут конечно можно сказать, что такое можно сделать уже давно, например Channel#receiveAsFlow и т.д.
Это всё равно треш. И в случае с receiveAsFlow, этот экстеншен в 99% случаев применяется "на месте", а не передаётся в цепочки функций. И нужно быть конченным дебилом, чтобы дёрнуть их вместе. А тут даже стараться не надо: чуть-чуть передизайнил фичу, добавив в неё новые флоу, а потом у тебя может выстрелить какой-то кусок. Хотя нет, "выстрелить" тут не подходит. Выстреливают громко и явно, а тут, судя по всему, вообще неявно.
Мне нравится -- ты вспомнил, что флоу и раньше спокойно могли быть горячими, но всё равно натягиваешь какие-то на бегу придуманные аргументы :) Почему receiveAsFlow в 99% применяется по месту? У меня он в публичной функции-геттере лежал обычно рядом с пропертёй, которая сам броадкаст канал. Вроде проблем не вызывало.
Ты горячими и холодными обзёрваблами в рыксе себе хоть раз по ногам стрелял? Вроде обычно из интерфейса несложно понять, где какой.
источник

AM

Andrew Mikhaylov in Programming Offtop
Ну и да -- с инсайтами касательно того, чего в фиче видеть хотелось бы, а чего нет, полезно приходить во время разработки фичи. Я даже не помню, сколько именно стейтфлоу педалился в активном режиме, но это совершенно точно был значительный промежуток времени. Где ты был, раз тебя так судьба горячих и холодных флоу заботит?)
источник

ML

Mikhail Levchenko in Programming Offtop
Кирилл Романенко
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-shared-flow/
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-state-flow/

В принципе то, о чём говорил Скобка: дизайн начинает плыть под натиском фичей.
Оч забавно читать все эти нюансы в стиле "это как бы flow, который изначально дизайнился как холодный, но вот этот горячий. И коллект тут другой, а ещё toList() засуспендит навечно".😍
Да просто все обмазываются флоу не к месту и страдают
источник

(

( in Programming Offtop
Alexander Nozik
Нет, это Лейбниц. Куда как более полезно, но не то. Надо гуглить в хаскель. Но у них все тексты специально запутанные, чтобы неофиты трепетали. Монада - это состояние в виде функции.
Неправильно
источник

(

( in Programming Offtop
Обыкновенная функция это тоже монада, где у нее состояние?
источник

AN

Alexander Nozik in Programming Offtop
(
Обыкновенная функция это тоже монада, где у нее состояние?
У нее пустое состояние. Для обычных функций ты не будешь привлекать аппарат монад.
источник

AN

Alexander Nozik in Programming Offtop
И я не говорил, что у монады состояние, я говорил, что они нужны для выражения состояния.
источник

BP

Bogdan Panchenko in Programming Offtop
саша сок #KotlinGang
и какие проблемы с toList()?
если это бесконечный флоу то это вполне логично.
Так это не бесконечный флоу, это вообще ObservableValue, зачем они к флоу прикручивают - хз
источник

AN

Alexander Nozik in Programming Offtop
Bogdan Panchenko
Так это не бесконечный флоу, это вообще ObservableValue, зачем они к флоу прикручивают - хз
Потому что семантически это одно и тоже.
источник

с#

саша сок #KotlinGang... in Programming Offtop
Alexander Nozik
Потому что семантически это одно и тоже.
+
источник