это у вас кодовая фраза такая, что ли? какой контроль и каких эффектов?
Если хочется иметь возможность работать с побочными эффектами в ссылочно-прозрачном виде, то взять для этого eDSL - это нормальный вариант.
Doge
Vasily
это у вас кодовая фраза такая, что ли? какой контроль и каких эффектов?
Они так друг друга распознают
Vasily
Doge
Понятнее не стало
Если хочется работать с асинхронными задачами, мутабельностью, работой с окружением, вводом-выводом и т.д., как с обычными значениями в языке, то взять для этого eDSL -это нормальный вариант.
Doge
Что можно работать с ними как с обычными значениями в языке?
Doge
Добро пожаловать в хаскель, там всё это из коробки.
Vasily
Скала не совсем хаскель
Vasily
Т.е. я допускаю, что в хаскеле это валидный подход
Doge
Скала не совсем хаскель
Ну смотря в чём. На хаскеле устраивать грязную магию точно так же можно, было бы желание.
Vasily
Хотя на самом деле я просто не понимаю терминологию
Vasily
Был бы я хаскелистом, наверное понял бы
Shub
Если хочется иметь возможность работать с побочными эффектами в ссылочно-прозрачном виде, то взять для этого eDSL - это нормальный вариант.
и всякий раз, когда я задаю такой вопрос - прямого ответа никогда нет. ты намекаешь, что в ссылочно-прозрачном коде нет штатных методов работы с
Shub
эффектами?
Doge
и всякий раз, когда я задаю такой вопрос - прямого ответа никогда нет. ты намекаешь, что в ссылочно-прозрачном коде нет штатных методов работы с
Вопрос - почему именно eDSL или почему именно MTL?
Shub
Вопрос - почему именно eDSL или почему именно MTL?
не, вопрос не как контролировать эффекты, а 1) что подразумевается под контролем эффектов? и 2) как конкретно они контролируются?
Shub
самое близкое, что мне рассказывали - это мол мы создаем интерпретатор и в этом интерпретаторе мы можем подменить реальный вызов к БД (например) на мок. но подозреваю, что это неправда. т.к. если это правда, то это все бессмысленно
Vasily
Обычно это неправда
Doge
не, вопрос не как контролировать эффекты, а 1) что подразумевается под контролем эффектов? и 2) как конкретно они контролируются?
Ну народ это может сильно по разному трактовать. Я бы сказал:
1. Возможность работать с побочными эффектами как с обычными значениями языка (это можно и в обычно ссылочно-прозрачном коде добится) + то, что в сигнатуре функции отображаются те побочные эффекты, что в ней используются
2. Ну и контроль - это прежде всего то, что используемый эффект отображается в типе.
Vasily
Да я вот сколько общаюсь, никак не пойму
Vasily
Что конкретно это упрощает
Shub
Что? Что можно подменить вызов БД на мок?
там человек подразумевал один конкретный вызов, а не подмена вообще всех вызовов к БД
Doge
там человек подразумевал один конкретный вызов, а не подмена вообще всех вызовов к БД
И в чём проблема? Это можно сделать.
Shub
Ну народ это может сильно по разному трактовать. Я бы сказал:
1. Возможность работать с побочными эффектами как с обычными значениями языка (это можно и в обычно ссылочно-прозрачном коде добится) + то, что в сигнатуре функции отображаются те побочные эффекты, что в ней используются
2. Ну и контроль - это прежде всего то, что используемый эффект отображается в типе.
в том, что все трактуют это сильно по-разному, есть большая проблема. библиотека-то одна.
каким образом ты "работаешь" с побочными эффектами как с обычными значениями? чем побочный эффект отличается от callable?
Shub
И в чём проблема? Это можно сделать.
можно сделать в теории или регулярно делается? потому что ни в одном примере этого не наблюдалось. ну там в принципе вообще мало что наблюдалось, все примеры, которые мне показывали были уровня факториала по сложности решаемой проблемы и вещами типа тестирования там и не пахло. ну оно и понятно, потому что там все усилия были направлены на "взлететь со всей этой хренью". но вообще было бы интересно посмотреть
Shub
это понятное дело не претензия к mtl\tf, это скорее к категории людей, которые туда почему-то идут
Doge
можно сделать в теории или регулярно делается? потому что ни в одном примере этого не наблюдалось. ну там в принципе вообще мало что наблюдалось, все примеры, которые мне показывали были уровня факториала по сложности решаемой проблемы и вещами типа тестирования там и не пахло. ну оно и понятно, потому что там все усилия были направлены на "взлететь со всей этой хренью". но вообще было бы интересно посмотреть
Очень условно, делается это в таком стиле, если вещи типа репозиториев ты делаешь эффектом:
newtype MyTestAppIO a = ReaderT Ctx (... (IO a)) derive (Monad, MonadReader Ctx, ...)
instance MyRepository MyTestAppIO where
getUserById id = myMockFunction
Если вещи типа репозиториев протаскиваются как обычные сервисы (или рекорды функций, если речь о хаскеле), то всё один в один как с обычными ОО моками.
Doge
Если речь про фри монады, то там делаешь тестовый интерпретатор, где делаешь паттерн матч на GetUserId и точно так же вызываешь код мока
Shub
Очень условно, делается это в таком стиле, если вещи типа репозиториев ты делаешь эффектом:
newtype MyTestAppIO a = ReaderT Ctx (... (IO a)) derive (Monad, MonadReader Ctx, ...)
instance MyRepository MyTestAppIO where
getUserById id = myMockFunction
Если вещи типа репозиториев протаскиваются как обычные сервисы (или рекорды функций, если речь о хаскеле), то всё один в один как с обычными ОО моками.
это ответ на вопрос "как", но не на вопрос "зачем", особенно в свете того, что там все один в один с обычными ОО моками. ок, допустим, в хаскеле нет объектов, но в языках с продом они есть
Shub
в скале точно есть
Vasily
Не в обиду собакену, в скалу идет куча ебанатов
Vasily
Опять же , ебанат - скорее склад характера и подход к решению проблем
Vasily
Чем характеристика интеллекта
Doge
в скале точно есть
Ну мотивация - "я использую mtl, чтобы было проще тестировать" - она немного странная, потому что тестирование там не особо проще.
Разве что можно в некоторых тестах убрать асинхронность, если есть желание, но это не какой-то супер пупер выигрыш.
Roman
Что конкретно это упрощает
Глобальная идея — сделать так, чтобы для полного понимания работы метода было достаточно прочесть сигнатуру, а не читать весь колл стек.
Например, в сишарпе нихуя непонятно, чего ожидать от метода Task AccountService.CreateAccount(string userId, Account account). Пушто это блядина совершенно точно кидает исключения (которые как раз приходится читать в недрах имплементации и только там), и еще возможно мутирует Account, например, проставляя там айдишник, сгенерированный базой.
Vasily
Глобальная идея — сделать так, чтобы для полного понимания работы метода было достаточно прочесть сигнатуру, а не читать весь колл стек.
Например, в сишарпе нихуя непонятно, чего ожидать от метода Task AccountService.CreateAccount(string userId, Account account). Пушто это блядина совершенно точно кидает исключения (которые как раз приходится читать в недрах имплементации и только там), и еще возможно мутирует Account, например, проставляя там айдишник, сгенерированный базой.
Я так понимаю, уровень исполнителей, как обычно, дотягивает только до имитации упрощения
Roman
Вот сишарповый вариант — пример остутствия "контроля эффектов", что бы эта мистическая фраза ни значила)
Vasily
Как мне кажется, проблема тут все же несколько в другом
Roman
ну смотря какие исполнители. В среднем получается говно — ну так это не зависит от подхода, пушто средний прогер независимо от любимого подхода — некомпетентный мудак
Vasily
И подобным способом ее не решить
Roman
И подобным способом ее не решить
Ну вот ты ударяешься в философию, и от этого легче не становится. А людям хочется выработать подход, который можно применять на практике. И стремление это благое)
Doge
И подобным способом ее не решить
Подобный подход облегчает чтение кодовой базы и поиск по ней (если хугл настроить и ему подобные)
Уже легче работать, когда у тебя есть понимание что конкретно плохого может данная функция сделать.
Vasily
Подобный подход облегчает чтение кодовой базы и поиск по ней (если хугл настроить и ему подобные)
Уже легче работать, когда у тебя есть понимание что конкретно плохого может данная функция сделать.
Ну ты же понимаешь, что скорее всего сил на это уходит больше, чем просто писать понятный код?
Roman
Подобный подход облегчает чтение кодовой базы и поиск по ней (если хугл настроить и ему подобные)
Уже легче работать, когда у тебя есть понимание что конкретно плохого может данная функция сделать.
вот да. Я на практике вижу огромную разницу, особенно если никто в крайности не впадает в команде
Roman
Doge
Ну ты же понимаешь, что скорее всего сил на это уходит больше, чем просто писать понятный код?
Так сил на это не много уходит
Roman
К тому же, это и есть тот самый понятный код
Doge
(Если взять библиотечные вещи, а не городить с нуля своё)
Vasily
Я как начинаю скала код читать, у меня мозг отключается
Roman
Ну, я говорю про простые вещи вроде Async<Result<Account, AccountCreateError>>
Roman
Я как начинаю скала код читать, у меня мозг отключается
мб на тебя просто разом слишком много неизвестного/непривычного валится
Doge
Я как начинаю скала код читать, у меня мозг отключается
Если ты смотришь на астронавтов из ПОНВа, то это их астронавтика по фану.
Roman
и синтаксис и концепции
Anatoly
Ну, я говорю про простые вещи вроде Async<Result<Account, AccountCreateError>>
и чем это лучше эксепшнов?
Anatoly
тем, что мы везде потом пишем вместо try/catch иф или даже switch?
Ayrat
ну то есть это именно лучше тем, что тебе не надо смотреть имплементацию методы выискивая все throw
Anatoly
в 99% случаев тебе вообще плевать на эксепшн
Vasily
Ну тут я соглашусь
Vasily
Вопрос все же в том, какого уровня исполнители нужны
Vasily
Чтобы не получилось как обычно
Ayrat
в 99% случаев тебе вообще плевать на эксепшн
согласен. но есть умники которые контрол-флоу на эксепшнах делают
Hog
ну то есть это именно лучше тем, что тебе не надо смотреть имплементацию методы выискивая все throw
вот в жаве хорошо - там прям в сигнатуре всё! /s
Ayrat
типа if (money > moneyLimit) throw new NotEnoughMoneyException(…)
Roman
в 99% случаев тебе вообще плевать на эксепшн
зависит от исключения. Если это условное 500, то да. Если это какой-нить ValidationException — не плевать
Anatoly
ну да, так и есть
ну вот только сколько я не вижу кода, когда надо разбираться, лезть в имплементацию надо всё равно. и похер, есть там эксепшн или нет
Roman
ну вот только сколько я не вижу кода, когда надо разбираться, лезть в имплементацию надо всё равно. и похер, есть там эксепшн или нет
еще раз. Зависит от исключения. Когда ты доменные ошибки выражаешь исключениями — они в том числе засоряют тебе логи, и тебе потом надо отсеивать это говно от реальных исключений
Roman
Сигнатура с резалтом и асинком тебе говорит об области ответственности функции
Doge
Я как начинаю скала код читать, у меня мозг отключается
Никто не будет писать в чатик типа понва, что вот, у меня метод зацените, всё по сигнатуре понятно, все дела.
confirmOrder :: (MonadError InfrastructureException m, OrderRepository m, StockRepository m) => Order -> m (Either ValidationError ConfirmedOrder)
Потому что это никому из них не интересно, т.к. и так всем понятно. А вот закинуть какой-нибудь очередной непонятный препроморфизм - это да, это круто, посоны оценят.
Anatoly
еще раз. Зависит от исключения. Когда ты доменные ошибки выражаешь исключениями — они в том числе засоряют тебе логи, и тебе потом надо отсеивать это говно от реальных исключений
логи будет засорять не try/catch, а switch, ок, велика разница
Roman
логи будет засорять не try/catch, а switch, ок, велика разница
а свич-то зачем в логи совать? Кто тебя заставляет
Anatoly
а кто меня заставляет эксепшн в логи совать?
Roman
Ай короче впизду. Пишите как хотите, словно мне больше всех надо
Крылатый
согласен. но есть умники которые контрол-флоу на эксепшнах делают
А вот в Питоне это бай дизайн!