Size: a a a

Programming Offtop

2020 October 26

(

( in Programming Offtop
Ilmir
Ты просто не умеешь их готовить.
Не умею и не буду учиться, я уже говорил, почему я считаю это плохим инструментом
И ты тогда в ответ написал лонгрид, который сам язык развенчивает с тех пор
источник

AM

Andrew Mikhaylov in Programming Offtop
Mikhail Levchenko
так и знал, что AMA будет норм таким источником мемов
А чё тут мемного-то?)
источник

QH

Quantum Harmonizer in Programming Offtop
(
Не умею и не буду учиться, я уже говорил, почему я считаю это плохим инструментом
И ты тогда в ответ написал лонгрид, который сам язык развенчивает с тех пор
оу, можно ссыль?
источник

ML

Mikhail Levchenko in Programming Offtop
Andrew Mikhaylov
А чё тут мемного-то?)
ну типа "дратути, а KMM заменит флаттер?"
источник

I

Ilmir in Programming Offtop
(
Не умею и не буду учиться, я уже говорил, почему я считаю это плохим инструментом
И ты тогда в ответ написал лонгрид, который сам язык развенчивает с тех пор
Wishful thinking же. В котлине с появлением новых фич будут новые идиомы, как и паттерны. А вот ХКТ я как-то не вижу.
источник

(

( in Programming Offtop
Quantum Harmonizer
оу, можно ссыль?
Telegram
( in Programming Offtop
Начиная с определённого момента, котлин начинает форсить в вашу кодовую базу анемичную модель. Это не плохо и не хорошо, это просто следствие того, что он принял некоторые функциональные подходы и перевел фокус с действий на данные. Котлинисты теперь больше стали думать не над тем, как декораторы раскидать, а как по коллекции красиво пройтись, вот что-то из этого рода. В некотором смысле это можно назвать идиоматическим кодом.
Но тащить разные фичи в язык и называть их идиомами - это путь к тому, что Set.filter возвращает лист, юзеры постоянно спотыкаются на корнер-кейсах, полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
ХКТ - это не какая-то прихоть, и даже не идиома. Это логичное развитие любого языка с дженериками, потому что раз вы параметрически полиморфны по значениям, будьте добры быть параметрически полиморфными и по оберткам, иначе вы привязываетесь к бесконечному числу частных случаев.
И втаскивание…
источник

I

Ilmir in Programming Offtop
Quantum Harmonizer
оу, можно ссыль?
У меня есть даже не ссыль, в паста!

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

Kd

Konstantin dmz9 in Programming Offtop
vote ban
источник

(

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

QH

Quantum Harmonizer in Programming Offtop
(
Начиная с определённого момента, котлин начинает форсить в вашу кодовую базу анемичную модель. Это не плохо и не хорошо, это просто следствие того, что он принял некоторые функциональные подходы и перевел фокус с действий на данные. Котлинисты теперь больше стали думать не над тем, как декораторы раскидать, а как по коллекции красиво пройтись, вот что-то из этого рода. В некотором смысле это можно назвать идиоматическим кодом.
Но тащить разные фичи в язык и называть их идиомами - это путь к тому, что Set.filter возвращает лист, юзеры постоянно спотыкаются на корнер-кейсах, полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
ХКТ - это не какая-то прихоть, и даже не идиома. Это логичное развитие любого языка с дженериками, потому что раз вы параметрически полиморфны по значениям, будьте добры быть параметрически полиморфными и по оберткам, иначе вы привязываетесь к бесконечному числу частных случаев.
И втаскивание фич в язык "по необходимости", а не "по задумке" - это, кстати, и есть С++ вей. Вот юзер споткнулся на каком-то кейсе, накатал пропозал, ему решили его проблему очередной фичей, отлично. Что это за фича? Будет ли она синергировать с другими? Нужна ли она другим юзерам? Какой мне толк от делегейтед пропертей, если команда крутит пальцем у виска, не понимая, что здесь написано?
Язык должен стремиться к тому, чтобы максимальное количество вещей можно было выразить на нём же, не открывая ютрек, иначе он всегда превратится в С++. Тут кстати и про суспенды - им необязательно быть частью компилятора, в пресловутом хаскеле почти такие же корутины реализованы на уровне библиотеки через ХКТ и монады и не отличаются от всего остального кода в смысле каких-то специальных ключевых слов или чего-то в этом роде.
Короче, если котлин-вей - обсуждать в пропозалах "а кому это надо" и "не сломает ли нам это что-нибудь", то увидимся через пять лет в паблике с мемами, где котлин будут сравнивать с плюсами. Если, конечно, язык выдержит такое многообразие взаимномешающих фич и вообще сможет развиваться
> если команда крутит пальцем у виска

так может, проблема в команде?)
источник

I

Ilmir in Programming Offtop
(
Мог бы тоже ссылку кинуть, теперь скроллить неудобно :/
Не, я за то, чтобы это превратилось в пасту.
источник

(

( in Programming Offtop
Quantum Harmonizer
> если команда крутит пальцем у виска

так может, проблема в команде?)
Может и в команде, я не помню, почему я именно это тогда написал
источник

KD

Konstantin Dovnar in Programming Offtop
Ilmir
Не, я за то, чтобы это превратилось в пасту.
источник

AN

Alexander Nozik in Programming Offtop
Mikhail Levchenko
ну типа "дратути, а KMM заменит флаттер?"
KMM не заменит, а Компоуз поверх KMM - да
источник

(

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

BP

Bogdan Panchenko in Programming Offtop
Konstantin dmz9
Какая нахуй разница ооп не ооп, при определенном желании можно вообще все что угодно чем угодно назвать, потому что те, кто придумывают эти термины - дегенераты и говноеды
Топ
источник

I

Ilmir in Programming Offtop
(
Решил перечитать ещё раз
> HKT - идиома
Когда котлиновские идиомы формализуете, тогда поговорим
А смысл? Банда четырёх тоже не формализовала ни один паттерн.
источник

I

Ilmir in Programming Offtop
И ещё. @happy_bracket в чём _формальное_ отличие цикла от хвостовой рекурсии? В каком папире мне найти выкладки, показывающие это отличие?
источник

AN

Alexander Nozik in Programming Offtop
(
Решил перечитать ещё раз
> HKT - идиома
Когда котлиновские идиомы формализуете, тогда поговорим
https://npm.mipt.ru/confluence/display/PUB/Kotlin+idioms. Это пока не официально, потому что список пополняется. Кстати суспендов пока нет. Это упущение.
источник

AN

Alexander Nozik in Programming Offtop
Ilmir
И ещё. @happy_bracket в чём _формальное_ отличие цикла от хвостовой рекурсии? В каком папире мне найти выкладки, показывающие это отличие?
Найти то, чего нет?
источник