x
его в детстве linq-ми отпиздили
Ayrat
его в детстве linq-ми отпиздили
Ну кстати не самое плохое опиздюливание. Линк-то годный. Вот ладно бы его ковариантностью отмудохали
Ayrat
Кстати обогнали за ночь пронет
Ayrat
По количеству юзеров
x
видимо, много у кого машина на морозе сгорела
Anonymous
Да, просто, статья прям переживать заставляет... Последний раз я что-то подобное испытывал когда читал "Историю одного байта"
Anonymous
Кстати, кто помнит её?
Ayrat
Кстати, кто помнит её?
Название знакомое чот
Ayrat
@Liminiens где ты эти наркоманские гифки берёшь?
x
сам рисует
Ayrat
Anonymous
Название знакомое чот
про то как заказчик внезапно вспомнил, что в микроконтроллере должна быть реализована ещё одна функция. А память МК уже забита под завязку. И ГГ пытается решить эту проблему всю историю. Реально чуть ли не слезу вышибает.
Vladislav
Анна
О, Пельмень! Прихраню
Anonymous
https://habr.com/ru/post/27055/
Anonymous
Вот она
Bonart
Какой смысл париться по поводу фронта если его все равно на жс будут делать
Еще можно его в JS компилировать. Пока TS видится разумным компромиссом
Doge
Ок, можно пример зависимостей а хаскеле?
В хаскеле у тебя точно так же будут совсем явные зависимости: передача аргументов в функции в том или ином виде (просто аргументы, Reader, ReaderT и соответствующие mtl'ые тайпклассы) ; и относительно неявные, которые за тебя компилятор делает: передача инстансов тайпклассов.
Doge
Пример то конерретный можно?
Пример кода с большим числом зависимостей?
Bonart
Пример кода с большим числом зависимостей?
Большое число зависимостей - это везде запашок
Igor
Пример кода с большим числом зависимостей?
Ну да. P.S. До сих пор уверен что ридер, нужен только как пример монад. В реальных проектах он бесполезен и только усложняет код трансформерами
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
Может кто-то сможет посоветовать живой и используемый хаскелевский веб-проект?
Ayrat
Лол
Ayrat
Меня в тюрягу не посадят?
Doge
Фильтр на гитхабе, по тегу yesod 🤔
Я бы скорее искал по серванту.
Ayrat
Это на хаскеле если чо
Doge
А исходники есть?
Ayrat
Там ещё такой же
Ayrat
Почему то трава и канабис у хаскелистов в фаворе
Ayrat
Подумал, удалил ссылку
Igor
Подумал, удалил ссылку
Теперь она только для своих 👌🌝
Andrew
https://habr.com/post/436202/
Респект за статью) Во многом жизненно, только машина не сгорела, но со многим согласен
Doge
Фильтр на гитхабе, по тегу yesod 🤔
Что-то как-то не густо на что-то реальное и живое по серванту выходит, кроме разве что либ для самого серванта. Попробую по yesod'у
Ayrat
Зашо
Ссылки на сайты сделанные на хаскеле через один про каннабис
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
Vladislav
Сижу не понимаю о чем вы
Vladislav
Igor
У тебя и так программа будет в рамках какого-то эффекта исполняться. Вопрос только в том явно ли ты его описываешь или нет
Всякий раз убеждаюсь, что скалисты не могут в функциональное-проектирование. Им проще взять интерпретатор (tagless/free) или IO и написать все “процедурно”, завернув в “монаду”. При таком подходе, разница с ООП минимальна. Даже кложуристы в среднем более “функциональны” t.me/pofftop/8977
Igor
(извиняюсь, если меня занесло чутка)
Doge
(извиняюсь, если меня занесло чутка)
Ну я могу в ответ набросить, что такое ФП очень не далеко ушло от процедурного программирования в плане проектирования, тестируемости и расширяемости.
Doge
Всякий раз убеждаюсь, что скалисты не могут в функциональное-проектирование. Им проще взять интерпретатор (tagless/free) или IO и написать все “процедурно”, завернув в “монаду”. При таком подходе, разница с ООП минимальна. Даже кложуристы в среднем более “функциональны” t.me/pofftop/8977
И, имхо, в ООП принципиально нет ничего плохого. Плохое есть в том, что его обычно используют в варианте без ссылочной прозрачности и с гигантским количеством всякого spooky-action-at-a-distance, которые при этом ещё валится в рантайме и параметричность нарушает (привет рефлексия)
Igor
Сижу не понимаю о чем вы
Про то что монады - это плохо
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
Ну по поводу того, что основная бизнес логика должна быть без всяких эффектов - соглашусь. Проблема только в том, что в большинстве приложений образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым.
Doge
И тут как раз всякие IO, F[_] и тому подобное ощутимо помогают.
Igor
> образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым. Интеграционные - тесты, докеры/test-constainer/mountbank тп
Doge
> образуется достаточно большой и сложный инфраструктурный и интеграционный слой, который тоже хотелось бы иметь чистым и тестируемым. Интеграционные - тесты, докеры/test-constainer/mountbank тп
Ну это само собой. Но у таких тестов обычно достаточно большой лаг, их сложно и дорого прогонять локально, поэтому хотелось бы иметь и юнит тесты, да и неконтролируемые побочные эффекты в любом случае сильно поддержку и разработку усложняют. То есть, с помощью таких приемов в архитектуре с impure-pure-impure сэндвичом можно impure часть сократить до самого минимума.
Фил Ранжин
код на картинке, это не код, а картинка
Фил Ранжин
он должен выглядеть прикольно, вот его работа
Igor
Это ставит под сомнение, все что ты ниже написал… И я не понимаю чем read |> processData |> writeData хуже, люди же читают сверху-в-низ слева-на-право