Size: a a a

Programming Offtop

2020 July 25

I

Ilmir in Programming Offtop
Apache DOG™
Вы час это строчили? Не иначе как с телефона, но это только увеличивает ваши заслуги.  Ваша позиция ясна и понятна, и достойна уважения. Но вы выпускаете несколько вещей. Во-первых: тру ФП идёт ой не от хаскеля. Оно идёт от конструктивной математики и лямбда исчисления и потом сверху из того что описано в category theory for working mathematician. Следствие этого пункта: у одного термина по хорошему должно быть одно значение, и если вы что то называете ФП, это должно соответствовать эталону из п.1, по мнению "крестоносцев". Вы не можете сделать какую-то лабуду и назвать её матан, точно так же им ФП. Во вторых: следование идиомам языка прямой способ запереть себя в них и больше за эти рамки не выходить. Язык это всего лишь средство выражения чего-то, это не священная корова, lingua kotlina non penis canina тут не работает. По этому идиомы языка это то что подлежит критике и правке, и сюда докапывается скобка. В третьих, идиомы скалы и ФП прекрасно переиспольузуются хоть в джаве хоть в котлине, не все но все же многие, и переиспользуются зашиьись
А что мешает писать на скале, а не превращать котлин в её брата-близнеца?
источник

AN

Alexander Nozik in Programming Offtop
Apache DOG™
Например уравнивание уровня энергии по всей материи?
Это максимум энетропии. Но это так для образования.
источник

AN

Alexander Nozik in Programming Offtop
Ilmir
А что мешает писать на скале, а не превращать котлин в её брата-близнеца?
+
источник

AN

Alexander Nozik in Programming Offtop
Apache DOG™
Например уравнивание уровня энергии по всей материи?
При максимальной энтропии математики тоже нет, поскольку нет информации.
источник

AD

Apache DOG™ in Programming Offtop
Но на самом деле не важно потому что математические объекты отвязаны от "реального" мира
источник

AD

Apache DOG™ in Programming Offtop
Alexander Nozik
При максимальной энтропии математики тоже нет, поскольку нет информации.
Это не информация
источник

AN

Alexander Nozik in Programming Offtop
Apache DOG™
Это не информация
Ну ка, а какое у вас определение инофрмации? Шеннона или может быть Фишера? Поздравляю, вы залезли в мою область математической экспертизы :)
источник

AN

Alexander Nozik in Programming Offtop
Apache DOG™
Но на самом деле не важно потому что математические объекты отвязаны от "реального" мира
А это уже Платон. Читали Платона?
источник

AN

Alexander Nozik in Programming Offtop
Или более современных последователей?
источник

AD

Apache DOG™ in Programming Offtop
Неа, просто логические умозаключения
источник

AM

Andrew Mikhaylov in Programming Offtop
Alexander Nozik
При максимальной энтропии математики тоже нет, поскольку нет информации.
Математика, как по мне, никуда не девается от того, что она нигде не существует в мире в виде чего-бы-то-ни-было.
источник

AN

Alexander Nozik in Programming Offtop
Apache DOG™
Неа, просто логические умозаключения
Почитайте. Очень полезно. Во конкретно диалоги Платона. Там конкретно изложена эта точка зрения и даже обозначены некоторые ее проблемы
источник

AN

Alexander Nozik in Programming Offtop
Andrew Mikhaylov
Математика, как по мне, никуда не девается от того, что она нигде не существует в мире в виде чего-бы-то-ни-было.
☝️
источник

AM

Andrew Mikhaylov in Programming Offtop
Да, увидел.
источник

AN

Alexander Nozik in Programming Offtop
Из более современного - Декарт. Тоже очень интеерсное чтение. По поводу самопознания вселенной через математику.
источник

AN

Alexander Nozik in Programming Offtop
Я вот на полке обнаружил книжку Витгенштейна - тоже все программистам почитать, хотя это уже не про математику, а как про языки и что такое язык.
источник

AN

Alexander Nozik in Programming Offtop
Раз уж пошла философия, в августе в JBR буду читать лекцию по Турчину (одному из основателей кибернетики). И эволюционных тенденциях в ПО,
источник

BV

Boris Vanin in Programming Offtop
Вообще непонятно о чём спор. Мы вроде там говорили конкретно про котлин. И можно использовать абсолютно любой подход в нем даже который максимально далёк от идиом, просто не нужно жаловаться, что язык кривой косой и фп в нем нормально не работает
источник

AM

Andrew Mikhaylov in Programming Offtop
Boris Vanin
Вообще непонятно о чём спор. Мы вроде там говорили конкретно про котлин. И можно использовать абсолютно любой подход в нем даже который максимально далёк от идиом, просто не нужно жаловаться, что язык кривой косой и фп в нем нормально не работает
Ну, а дальше опять теоретики с практиками схлестнулись, и понеслось.
источник

(

( 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, которые нафиг не нужны в асинхронщине, но полезны в других областях.
Наконец, изучение языка - это не только изучение синтаксиса, это ещё и изучение идиом. И попытки использовать идиомы другого языка - распространённая ошибка новичков, которую они допускают в силу приобретенных привычек и которая ведёт к фрустрации, потому что идиомы не те, к которым они привыкли. Поэтому программирование на этом языке кажется _странным_. Требуется время, чтобы переделать свои привычки и использовать более подходящие идиомы.
Поэтому, кстати, нет плохих и хороших языков. Есть языки, идиомы которых _нравятся_ и языки, идиомы которых _не нравятся_. Мне, например, _не нравятся_ идиомы го и питона. Но я в восторге от идиом лиспа и перла. Возможно, просто котлин не для тебя и тебе больше подходит скала. Но котлин != скала и не стоит пытаться переиспользовать идиомы из скалы в котлине или жаловаться на то, что идиомы другие, _плохие_.
Начиная с определённого момента, котлин начинает форсить в вашу кодовую базу анемичную модель. Это не плохо и не хорошо, это просто следствие того, что он принял некоторые функциональные подходы и перевел фокус с действий на данные. Котлинисты теперь больше стали думать не над тем, как декораторы раскидать, а как по коллекции красиво пройтись, вот что-то из этого рода. В некотором смысле это можно назвать идиоматическим кодом.
Но тащить разные фичи в язык и называть их идиомами - это путь к тому, что Set.filter возвращает лист, юзеры постоянно спотыкаются на корнер-кейсах, полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
ХКТ - это не какая-то прихоть, и даже не идиома. Это логичное развитие любого языка с дженериками, потому что раз вы параметрически полиморфны по значениям, будьте добры быть параметрически полиморфными и по оберткам, иначе вы привязываетесь к бесконечному числу частных случаев.
И втаскивание фич в язык "по необходимости", а не "по задумке" - это, кстати, и есть С++ вей. Вот юзер споткнулся на каком-то кейсе, накатал пропозал, ему решили его проблему очередной фичей, отлично. Что это за фича? Будет ли она синергировать с другими? Нужна ли она другим юзерам? Какой мне толк от делегейтед пропертей, если команда крутит пальцем у виска, не понимая, что здесь написано?
Язык должен стремиться к тому, чтобы максимальное количество вещей можно было выразить на нём же, не открывая ютрек, иначе он всегда превратится в С++. Тут кстати и про суспенды - им необязательно быть частью компилятора, в пресловутом хаскеле почти такие же корутины реализованы на уровне библиотеки через ХКТ и монады и не отличаются от всего остального кода в смысле каких-то специальных ключевых слов или чего-то в этом роде.
Короче, если котлин-вей - обсуждать в пропозалах "а кому это надо" и "не сломает ли нам это что-нибудь", то увидимся через пять лет в паблике с мемами, где котлин будут сравнивать с плюсами. Если, конечно, язык выдержит такое многообразие взаимномешающих фич и вообще сможет развиваться
источник