ITT меряются школами

в любом случае вынести какой-то список команд в эффект/монаду и указать, что в этом коде у тебя вот этот эффект (MonadDB, MonadState), и потом мокать конкретные эффекты

вот так надо ^

mtl это хорошо

только мокать MonadDB замучаешься, надо что-то поконкретнее

Это нормально.

все пишем в ReaderT IO, мокать ничего не нужно, так Снойман сказал

Ну если у тебя в ReaderT лежит рекорд функций

Эффекты ортогональны моканию

все пишем в ReaderT IO, мокать ничего не нужно, так Снойман сказал

тут уже можно сказать, что и ридер не нужен

я говорю как Снойман сказал, не надо спорить с умным человеком

и какое-то свое мнение или подходы придумывать, он придумал уже

Точнее, IoC/DI

и какое-то свое мнение или подходы придумывать, он придумал уже

Я полагаю, я тоже кое-что придумал. А скорее, скомпилиррвал

Но до Сноймана, конечно, далеко

что ты там придумал, все программирование Снойман уже сделал в своих TH-макросах к Yesod, ты теперь пользуйся только

два макроса вызвал, потом ReaderT, IO, приложение готово, всё

ну, при сноймановских представлениях о прагматичности его переход к идее "просто пишем функции из рекордов в IO ()" это только вопрос времени

ну, при сноймановских представлениях о прагматичности его переход к идее "просто пишем функции из рекордов в IO ()" это только вопрос времени

IOref'ов не хватает только

так голое ио же, конечно иорефы можно, можно ни в чем себе не отказывать

ну, при сноймановских представлениях о прагматичности его переход к идее "просто пишем функции из рекордов в IO ()" это только вопрос времени

следующий логический шаг сделали ребята из Well Typed, там Duncan Coutts и Alexander Vieth сказали, мол, так и пишите, напридумывали еще что-то кроме функций и IO

рекорды, функции, IO, вперёд

если что, то это в контексте того, что IOHK нанимали FP Complete и Well Typed для консалтинга/аудита/разработки Cardano SL, и опытные господа там всё высказали

и кусками переписали

Эффекты ортогональны моканию

ну не в этом случае же

а если только рекорды и функции, без IO, то это вообще высший пилотаж

а если только рекорды и функции, без IO, то это вообще высший пилотаж

ФП какое-то, фу

если что, то это в контексте того, что IOHK нанимали FP Complete и Well Typed для консалтинга/аудита/разработки Cardano SL, и опытные господа там всё высказали

Я читал отчет от FP Complete. Не припомню наездов на IO. Но не исключаю, что пропустил. А правильно ли я понимаю, что это сейчас было в пику ребятам из Serokel?

во-первых наезды на IO были от WT, а не от FP Complete во-вторых я не знаю что такое "в пику"

и что "это сейчас" такое было

Отчет от WT тогда бы хотел тоже читануть. Но да, за IO-императивщину в Haskell я бы тоже ругался

ФП какое-то, фу

они там просто сами до конца решить не могли, что считается, а что не считается за чистый код вроде если MonadFoo m, MonadBar m писать код, то там ничего его к IO не привязывает, а все равно плохо, жалуются, говорят на рекорды и функции переписать но в реальном-то мире надо к IO инстанцировать, иначе стриминга не будет

Отчет от WT тогда бы хотел тоже читануть. Но да, за IO-императивщину в Haskell я бы тоже ругался

Нет там никакого отчета, по крайней мере публичного. На GitHub только жалуются, ничего лучше не предлагают.

По-моему надо как в агде -- IO только в одной функции и норм

Такое работает только если код не запускать

Фу, ещё код запускать

Если у тебя в базе данных гигабайты лежат, и тебе обработать их надо, то ты либо пишешь логику обработки в IO, либо используешь стриминг-абстракцию (которую инстанцируешь в IO), либо пытаешься совместить чистую функцию и lazy IO (на практике никогда не работает, понятное дело, это же lazy IO)

а когда эта логика в ядре системы, то у тебя получается либо вся система в IO, либо вся система в абстрактной монаде, либо вся система без стриминга (так нельзя)

даже если концептуально можно было бы написать все чистыми функциями, в каком-то там мире с бесконечной RAM

очень отвратительно было с WT работать, которые советовали одно (пишите всё чистыми функциями, не переабстрагируйте!!11), а как их до кода пускали, то использовали какие-то адские абстракции вроде IO пятой вложенности и переизобретения своего варианта mtl, и очень радовались, какие они умные и все придумали

как будто их трейнинг был не консалтить, а мешать разработке и делать так, чтобы их подольше нанимали. консалтинг мутится, баблишко крутится

Если у тебя в базе данных гигабайты лежат, и тебе обработать их надо, то ты либо пишешь логику обработки в IO, либо используешь стриминг-абстракцию (которую инстанцируешь в IO), либо пытаешься совместить чистую функцию и lazy IO (на практике никогда не работает, понятное дело, это же lazy IO)

Блин, я шутил :(

у меня просто горит с WT, я высказаться хотел

Вот так срыв покровов.

Не используйте Eff в PureScript. Его, во-первых, выпилили, во вторых это больше мешает, чем помогает. Не помогает от слова совсем. freer от Intakt страдает тем же. Да и вообще, расширяемые эффекты - зло

Иначе говоря алгебраические эффекты страдают тем, что в них ты теряешь контроль над типами эффектов?

Иначе говоря алгебраические эффекты страдают тем, что в них ты теряешь контроль над типами эффектов?

Не знаю. Знаю только, что их использование не приносит бенефитов, а боли добавляет немеряно. В условиях непрерывно изменяющихся требований и постоянного рефакторинга тасовать типы совсем неинтересно.

в то же время FP Complete в лице Сноймана кстати хорошо консалтили и все его рекомендации по делу и консистентны между собой просто у него принцип разработки в том, что написать boilerplate не страшно, писать надо код предельно тупой. ReaderT IO, и лучше TVar с STM вместо IORef код, конечно, получается, императивный, но все и так знают, что Haskell is the best imperative language, вот примерно таким его Снойман и видит

лучше так писать, чем на Java, но это не то чтобы был большой прыжок технологический на фоне Java

TVar с STM и правда лучше

ну да, кроме трех тонн оверхеда, которые они за собой несут, но до профайлинга об этом нечего рассуждать я просто говорю, что у Сноймана есть фичи языка, которые он знает, что хорошо работают (IO, STM, ReaderT, async), и он крайне скептично относится ко всему, что в его привычный тулкит не укладывается

и возможно правильно делает, если цель поскорее хуяк-хуяк и в продакшен, а не узнать три новых факта о том, какие проблемы есть у свободных эффектов и т.д.

Не, ну так и к успеху можно придти

Что-то я все равно не пойму, Снойман - он хороший или плохой?

Господа, а зайдите в расточат. Там идиотская дискуссия намечается

Ссыль!

Обожаю идиотские дискуссии

Люди хотят отправлять get с body и говорят, что это норм

@rustlang_ru ?

Хотя, мб это не тот расточат.

Я хз.

@rustlang_ru

Лоооооооооол тело запроса у GET

Люди хотят отправлять get с body и говорят, что это норм

да пусть отправляют, хоть через руки дойдёт

надо быть нарокманом чтобы такое придумать

Насколько я помню, хаскельные HTTP клиенты даже не дают такое сделать

не только хаскельные

тело запроса у гет может быть

но оно не стандартизировано

Насколько я помню, хаскельный Network.HTTP не даёт делать https-запросы.

ERROR: S client not available

потому харам

И я точно видел вопрос на SO про это.

Насколько я помню, хаскельный Network.HTTP не даёт делать https-запросы.

вообще?

Что-то я все равно не пойму, Снойман - он хороший или плохой?

Он хороший, потому что консистентен в своей позиции, объясняет хорошо, вникает в проблему, т.е. консалтит грамотно Но он плохой, потому что если его много слушать, то можно из Haskell сделать функциональный Go, в том смысле, что новые фичи отторгаются в пользу проверенно работающих, даже если их видно не хватает для задачи

тело запроса у гет может быть

Мне вот что-то кажется, что если даже стандарт особо не запрещает тело у get, то всё равно наверняка не все веб сервера будут такое поддерживать. И не все клиенты.

Снойман Шредингера

в смысле?

вообще?

Вообще

типа хороший и плохой одновременно?

нельзя же так людей делить

Он не обидится :)

я вот пожаловался, например, на Alexander Vieth из Well-Typed, который консалтит не пойми как и в коде страшные вещи наворотил, но в то же время не буду отрицать, что он умный, крутые вещи время от времени придумывает (вроде https://github.com/avieth/type-lambda), и в GHC полезные contributions делает, и т.д.

хороший он или плохой?

Он не обидится :)

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

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

я вот прочитал это и живо представил себе, как происходит каррирование человеков! мне этот ваш хаскель весь мозг сломал ?

Вот с хаскеллистами всегда так. Как что-нибудь придумывать, так они впереди планеты всей, ворочают вещами, уровень абстракции которых не поддается описанию. А как на в продакшене, так сразу какую-то ерунду пишут неподдерживаемую

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

булевая слепота у вас. data Goodness = Good | NoGood

изоморфно

можно добавить еще конструкторов

Null

для практичности

WorkButSmells

Вот с хаскеллистами всегда так. Как что-нибудь придумывать, так они впереди планеты всей, ворочают вещами, уровень абстракции которых не поддается описанию. А как на в продакшене, так сразу какую-то ерунду пишут неподдерживаемую

Думаю, что специфика языка влияет. Он позволяет сделать слишком много, и люди берутся за разное, экспериментируют. Поддерживаемый код в продакшене писать не так сложно, там обычный опыт программирования применим. Просто Haskell не так популярен, хорошие подходы не так сильно распространены, пока ещё слишком много разных способов написать что-то, и не всегда понятно, какой лучше.

Good | Ungood | Doubpleplusungood

Думаю, что специфика языка влияет. Он позволяет сделать слишком много, и люди берутся за разное, экспериментируют. Поддерживаемый код в продакшене писать не так сложно, там обычный опыт программирования применим. Просто Haskell не так популярен, хорошие подходы не так сильно распространены, пока ещё слишком много разных способов написать что-то, и не всегда понятно, какой лучше.

Да, согласен

WorkButSmells

WorkButtSmells

Good | Ungood | Doubpleplusungood

UNACCEPTABLE CONDITION https://www.youtube.com/watch?v=Oqa9tKarkNA

АЛГЕБРАИЧНО!

WorkButtSmells

улётная шутка

Он хороший, потому что консистентен в своей позиции, объясняет хорошо, вникает в проблему, т.е. консалтит грамотно Но он плохой, потому что если его много слушать, то можно из Haskell сделать функциональный Go, в том смысле, что новые фичи отторгаются в пользу проверенно работающих, даже если их видно не хватает для задачи

Проблема в том, что нужно как-то сохранять ограниченное количество активно используемых фич. То есть если вводится какая-то новая суперважная всем нужная фича, то какую-то старую по хорошему бы задепрекейтить. Иначе будет разрастаться контекст, а кривая обучения будет становиться всё круче.

UNACCEPTABLE CONDITION https://www.youtube.com/watch?v=Oqa9tKarkNA

улётный ролик

?