x
его в детстве linq-ми отпиздили
Ayrat
его в детстве linq-ми отпиздили
Ну кстати не самое плохое опиздюливание. Линк-то годный.
Вот ладно бы его ковариантностью отмудохали
x
Ну кстати не самое плохое опиздюливание. Линк-то годный.
Вот ладно бы его ковариантностью отмудохали
ты что, а вдруг бы понравилось? а он же мальчик
Ayrat
Кстати обогнали за ночь пронет
Ayrat
По количеству юзеров
x
видимо, много у кого машина на морозе сгорела
Anonymous
Да, просто, статья прям переживать заставляет... Последний раз я что-то подобное испытывал когда читал "Историю одного байта"
Anonymous
Кстати, кто помнит её?
Ayrat
@Liminiens где ты эти наркоманские гифки берёшь?
x
сам рисует
Ayrat
Anonymous
Название знакомое чот
про то как заказчик внезапно вспомнил, что в микроконтроллере должна быть реализована ещё одна функция. А память МК уже забита под завязку. И ГГ пытается решить эту проблему всю историю. Реально чуть ли не слезу вышибает.
Vladislav
Анна
Anonymous
https://habr.com/ru/post/27055/
Anonymous
Вот она
Igor
Bonart
Какой смысл париться по поводу фронта если его все равно на жс будут делать
Еще можно его в JS компилировать. Пока TS видится разумным компромиссом
Doge
Ок, можно пример зависимостей а хаскеле?
В хаскеле у тебя точно так же будут совсем явные зависимости: передача аргументов в функции в том или ином виде (просто аргументы, Reader, ReaderT и соответствующие mtl'ые тайпклассы) ; и относительно неявные, которые за тебя компилятор делает: передача инстансов тайпклассов.
Igor
Igor
Пример кода с большим числом зависимостей?
Ну да.
P.S. До сих пор уверен что ридер, нужен только как пример монад. В реальных проектах он бесполезен и только усложняет код трансформерами
Doge
Ну да.
P.S. До сих пор уверен что ридер, нужен только как пример монад. В реальных проектах он бесполезен и только усложняет код трансформерами
Ну явно использовать ридер не нужно.
Обычно надо MonadReader из mtl юзать
Doge
Ну да.
P.S. До сих пор уверен что ридер, нужен только как пример монад. В реальных проектах он бесполезен и только усложняет код трансформерами
Если в шутку, то вот замечательный вариант (но он конечно же кодогенеренный):
http://hackage.haskell.org/package/AlignmentAlgorithms-0.1.0.0/docs/DP-Seq-Align-Global-Affine2.html
Если нет, то из реальных прикладных проектов я сейчас сходу вспомнил XMonad и решил именно его посмотреть. Прям совсем страшного там ничего нет, но там как раз используется подход с MonadReader для передачи внешних параметров и зависимостей (в типе XConf) и с MonadState для работы с внутренним состоянием и зависимостями (в типе XState)
И если посмотреть на все семантические зависимости то их наберется весьма не мало. И ещё надо учесть, что часть зависимостей, которые явно передавались бы в ОО мире, тут идёт тайпклассами и их реализацией, которые передаются неявно. (Например, смотри дофига инстансов, которые выводятся через deriving и те, которые явно обьявлены)
Doge
Может кто-то сможет посоветовать живой и используемый хаскелевский веб-проект?
Igor
Может кто-то сможет посоветовать живой и используемый хаскелевский веб-проект?
Фильтр на гитхабе, по тегу yesod 🤔
Ayrat
Лол
Ayrat
Меня в тюрягу не посадят?
Ayrat
Это на хаскеле если чо
Doge
А исходники есть?
Ayrat
Там ещё такой же
Ayrat
Почему то трава и канабис у хаскелистов в фаворе
Ayrat
Подумал, удалил ссылку
Andrew
https://habr.com/post/436202/
Респект за статью)
Во многом жизненно, только машина не сгорела, но со многим согласен
Doge
Фильтр на гитхабе, по тегу yesod 🤔
Что-то как-то не густо на что-то реальное и живое по серванту выходит, кроме разве что либ для самого серванта.
Попробую по yesod'у
Igor
Если в шутку, то вот замечательный вариант (но он конечно же кодогенеренный):
http://hackage.haskell.org/package/AlignmentAlgorithms-0.1.0.0/docs/DP-Seq-Align-Global-Affine2.html
Если нет, то из реальных прикладных проектов я сейчас сходу вспомнил XMonad и решил именно его посмотреть. Прям совсем страшного там ничего нет, но там как раз используется подход с MonadReader для передачи внешних параметров и зависимостей (в типе XConf) и с MonadState для работы с внутренним состоянием и зависимостями (в типе XState)
И если посмотреть на все семантические зависимости то их наберется весьма не мало. И ещё надо учесть, что часть зависимостей, которые явно передавались бы в ОО мире, тут идёт тайпклассами и их реализацией, которые передаются неявно. (Например, смотри дофига инстансов, которые выводятся через deriving и те, которые явно обьявлены)
> И ещё надо учесть, что часть зависимостей, которые явно передавались бы в ОО мире
Какие? Репозиторий для доступа к базе?
Это же 100% не (“чисто”) функционально
Igor
По твоему “функционально” - значит размазать по всей программе IO? (все ручки чистенькие, это же хаскель)
Doge
> И ещё надо учесть, что часть зависимостей, которые явно передавались бы в ОО мире
Какие? Репозиторий для доступа к базе?
Это же 100% не (“чисто”) функционально
Например, скорее всего в ОО мире вместо инстанса MonadState, например, был бы сервис инкапсулирующий получение и изменение этого состояния
Doge
По твоему “функционально” - значит размазать по всей программе IO? (все ручки чистенькие, это же хаскель)
Функционально - это значит ссылочно-прозрачно. А уж как этого добиться вариантов много.
Doge
Явное использования IO, Mtl-стиль и final tagless, Free, impure-pure-impure сэндвич
Igor
Функционально - это значит ссылочно-прозрачно. А уж как этого добиться вариантов много.
Монады оооочень плохой способ.
Еще Эрик Маейр говорил “монады это плохо, тк они заражают все вызывающие функции”.
Монады должны быть где-то в корне программы, а дальше plane-function-programming
Doge
Монады оооочень плохой способ.
Еще Эрик Маейр говорил “монады это плохо, тк они заражают все вызывающие функции”.
Монады должны быть где-то в корне программы, а дальше plane-function-programming
У тебя и так программа будет в рамках какого-то эффекта исполняться.
Вопрос только в том явно ли ты его описываешь или нет
Vladislav
Сижу не понимаю о чем вы
Vladislav
Igor
У тебя и так программа будет в рамках какого-то эффекта исполняться.
Вопрос только в том явно ли ты его описываешь или нет
Всякий раз убеждаюсь, что скалисты не могут в функциональное-проектирование.
Им проще взять интерпретатор (tagless/free) или IO и написать все “процедурно”, завернув в “монаду”.
При таком подходе, разница с ООП минимальна.
Даже кложуристы в среднем более “функциональны” t.me/pofftop/8977
Igor
(извиняюсь, если меня занесло чутка)
Doge
Всякий раз убеждаюсь, что скалисты не могут в функциональное-проектирование.
Им проще взять интерпретатор (tagless/free) или IO и написать все “процедурно”, завернув в “монаду”.
При таком подходе, разница с ООП минимальна.
Даже кложуристы в среднем более “функциональны” t.me/pofftop/8977
Ну так почему именно скалисты? В хаскеле точно так же делают.
Doge
(извиняюсь, если меня занесло чутка)
Ну я могу в ответ набросить, что такое ФП очень не далеко ушло от процедурного программирования в плане проектирования, тестируемости и расширяемости.
Doge
Всякий раз убеждаюсь, что скалисты не могут в функциональное-проектирование.
Им проще взять интерпретатор (tagless/free) или IO и написать все “процедурно”, завернув в “монаду”.
При таком подходе, разница с ООП минимальна.
Даже кложуристы в среднем более “функциональны” t.me/pofftop/8977
И, имхо, в ООП принципиально нет ничего плохого.
Плохое есть в том, что его обычно используют в варианте без ссылочной прозрачности и с гигантским количеством всякого spooky-action-at-a-distance, которые при этом ещё валится в рантайме и параметричность нарушает (привет рефлексия)
Igor
https://habrastorage.org/webt/41/ye/yh/41yeyhzxfisl1uunx8jo2vtfwbi.png
@fillpackart это фишка такая использовать обратный пайп?
Doge
Про то что монады - это плохо
Ну оно сложнее, чем просто плохо.
Во-первых, когда мы говорим про контроль эффектов с их помощью, то использовать явно какую-то конкретную монаду не стоит. Надо от конкретики абстрагироваться, т.к. чаще всего в таком случае тебе конкретные особенности данной монады не интересны.
Во-вторых, да, если возможность описать что-то с помощью стрелок, аппликативных и обычных функторов, то лучше брать их, потому что удобно, когда ограничения на эффект как можно более точные.
Doge
А сам абстракция от эффекта интересна тем, что она даёт лучшую поддержку параметричности (т.к. с абстрактным эффектом куда меньше всего можно сделать, чем с конкретным) и становится ощутимо проще писать и рассуждать о свойствах частей программы.
Doge
Про параметричность можно почитать в оригинальной статье - Theorems for Free! и где-то в инете валялись приличные слайды на эту тему от Морриса.
Vasily
Стоило уехать отдыхать, в чате началась наркрмания
Igor
Про параметричность можно почитать в оригинальной статье - Theorems for Free! и где-то в инете валялись приличные слайды на эту тему от Морриса.
Я вот честно не понимаю эти градации чистоты.
Для меня код
- либо чистый,
- либо, если он лезет в базу/кидает исключение/любой IO/изменения стейт - он грязный, сколько бы там не было F оберток
Igor
@fillpackart я понял как надо читать твои статьи - говорилкой в Safari на 2x
Она прям про меня (только у меня нет машины… и детей)
Igor
Doge
Я вот честно не понимаю эти градации чистоты.
Для меня код
- либо чистый,
- либо, если он лезет в базу/кидает исключение/любой IO/изменения стейт - он грязный, сколько бы там не было F оберток
Ну чистая функция, если уж говорить про определения - эта та, которая является детерминированной и не исполняет побочные эффекты.
Функция, которая просто возвращает IO и не делает внутри себя всякие unsafePreformIO и т.п. - она чистая.
Потому что именно эта функция эффекты не исполняет и детерминирована.
Грязь тут будет только в тот момент, когда для собранного тобой из результатов таких функций IO ты или компилятор вызовет unsafePerformIO.
Igor
> Функция, которая просто возвращает IO и не делает внутри себя всякие unsafePreformIO и т.п. - она чистая.
Она бесполезная… Это попытка скрыть весь мусор под ковер (в рантайм).
А если это обычная IO, то ты с ней вообще не можешь ничего сделать, кроме как запустить.
Doge
> Функция, которая просто возвращает IO и не делает внутри себя всякие unsafePreformIO и т.п. - она чистая.
Она бесполезная… Это попытка скрыть весь мусор под ковер (в рантайм).
А если это обычная IO, то ты с ней вообще не можешь ничего сделать, кроме как запустить.
А почему она бесполезная?
Её результаты ты вполне можешь комбинировать и преобразовывать.
А то если так рассуждать, то и функция возвращающая async или холодный Task тоже бесполезная.
Vladislav
https://github.com/Microsoft/visualfsharp/issues/6096
Igor
А почему она бесполезная?
Её результаты ты вполне можешь комбинировать и преобразовывать.
А то если так рассуждать, то и функция возвращающая async или холодный Task тоже бесполезная.
> А то если так рассуждать, то и функция возвращающая async или холодный Task тоже бесполезная.
Абсолютно, тк скорее всего если ей это надо, то где-то внутри она делает такое-же ленивое IO
Все, она уже НЕ тестируема (без моков и тп), если это бизнес-логика то это ужасно.
“Бизнес-логика не должна быть асинхронной” (для тестируемости)
Об этом еще Марк говорил в докладе https://youtu.be/F9bznonKc64
Doge
> А то если так рассуждать, то и функция возвращающая async или холодный Task тоже бесполезная.
Абсолютно, тк скорее всего если ей это надо, то где-то внутри она делает такое-же ленивое IO
Все, она уже НЕ тестируема (без моков и тп), если это бизнес-логика то это ужасно.
“Бизнес-логика не должна быть асинхронной” (для тестируемости)
Об этом еще Марк говорил в докладе https://youtu.be/F9bznonKc64
> “Бизнес-логика не должна быть асинхронной” (для тестируемости)
Ну поэтому и надо абстрагироваться от эффектов. Тогда ничто не мешает в тестах юзать SyncIO или вообще какой-нибудь Eval/Id и т.п.
Doge
> А то если так рассуждать, то и функция возвращающая async или холодный Task тоже бесполезная.
Абсолютно, тк скорее всего если ей это надо, то где-то внутри она делает такое-же ленивое IO
Все, она уже НЕ тестируема (без моков и тп), если это бизнес-логика то это ужасно.
“Бизнес-логика не должна быть асинхронной” (для тестируемости)
Об этом еще Марк говорил в докладе https://youtu.be/F9bznonKc64
Ну по поводу того, что основная бизнес логика должна быть без всяких эффектов - соглашусь.
Проблема только в том, что в большинстве приложений образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым.
Doge
И тут как раз всякие IO, F[_] и тому подобное ощутимо помогают.
Igor
> образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым.
Интеграционные - тесты, докеры/test-constainer/mountbank тп
Doge
> образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым.
Интеграционные - тесты, докеры/test-constainer/mountbank тп
Ну это само собой.
Но у таких тестов обычно достаточно большой лаг, их сложно и дорого прогонять локально, поэтому хотелось бы иметь и юнит тесты, да и неконтролируемые побочные эффекты в любом случае сильно поддержку и разработку усложняют.
То есть, с помощью таких приемов в архитектуре с impure-pure-impure сэндвичом можно impure часть сократить до самого минимума.
Фил Ранжин
Фил Ранжин
код на картинке, это не код, а картинка
Фил Ранжин
он должен выглядеть прикольно, вот его работа
Igor
Это ставит под сомнение, все что ты ниже написал…
И я не понимаю чем
read
|> processData
|> writeData
хуже, люди же читают сверху-в-низ слева-на-право