Я люблю эмоции, и сам обустраиваю жизнь так, чтобы испытывать эмоции. Я знаю, когда и какие я буду испытывать, но это мне не мешает.
Если я съем что-то вкусное, оно будет вкусное, даже если я знаю, что и зачем я ем.
Очевидно, имелось в виду, не хватает удобного map и filter.
А то так можно и про лямбды сказать «делайте struct с operator ()»
Собственно, именно про удобство всегда и говорят, ибо иначе нечего обсуждать, языки Тьюринг-полные.
Если вылетит исключение, файлы останутся незакрытыми.
Можно использовать withFile, но с ним неудобно открывать список файлов, ведь он принимает callback.
Но тут приходит на помощь монада Cont. file :: FilePath -> IOMode -> ContT r IO Handle
file f m = ContT $ withFile f m
files :: IOMode -> [FilePath] -> ContT r IO [Handle]
files m fs = mapM (\f -> file f m) fs
Теперь и защита от исключений, и без вложенных withFile.
В Haskell STM (Software Transactional Memory) реализовано в виде библиотеки. Благодаря тем самым «костыльным» монадам для состояния, у нас есть гарантия того, что всё STM изолировано и мы не можем внутри обращаться к «левым» ссылкам.
Как дать такие гарантии там, где потенциально всё — IO?
Также есть монада ST, мы можем локально заводить мутабельные переменные, но так как они изолированы, итоговое вычисление гарантированно чистое. Оборачиваем это в runST и получаем чистое значение, реализованное императивным способом. Это аналогично pure из D, но без дополнительного ключевого слова и какого-то специального анализа компилятора.
Вопрос тот же, как это сделать в языке, где нет таких «костылей»? В D пришлось ввести новое ключевое слово.
Странно, Agda, GHC и куча других компиляторов написано на Haskell как раз потому, что он для этого удобен.
Я пишу на нём уже несколько лет, писал WebSocket-сервер, mp3tags-декодер (ибо текущие реализации на тот момент на любом языке многие не поддерживали даже сжатия, не говоря о шифровании), и почему-то пока не столкнулся с ситуацией, где «все перечисленные достоинства» исчезали бы.
В случае языков ситуация, когда недостающая функциональность обходится другими средствами языка, при этом крайне неудобно. Как лямбды в C++03, например (boost::bind + boost::lambda).
Так вот чистота и ленивость — это фундаментально в Haskell, и сделано намеренно. И различие между IO/State/whatever и чистыми функциями тоже сделано намеренно. Это меняет подход, это неудобно новичкам, но это не костыль.
У сколь-нибудь опытных программистов на Haskell с этим проблем нет.
> новичку надо разобраться
То, что новичку что-то там не понятно, не тянет на аргумент о костыльности в системе.
Может, и теория групп в математике тогда костыли?
map от mapM отличаются не только тем, что там монада, а и тем, что для map выполняются функторные законы, для mapM — нет.
Тот же mapM можно написать как минимум двумя способами.
В хаскеле не нужно знать «тонкости», надо понимать, что такое чистота. Новичку и впрямь непривычно, но на костыльность это не указывает.
IO тоже можно без монад. Монада к IO имеет весьма посредственное отношение и вовсе не костыль, коль уж имеются монады Exception, Maybe, State, Async (async/await), Cont (call/cc) и другие.
Эдак можно сказать, что async/await — костыль для языков, где нет нормальных монад.
Хотя можно придерживаться т.з., что объекты — замыкания для бедных, а замыкания — объекты для бедных.
Для иллюстрации см. интерференцию электронов. На экране мы видим именно что индивидуальные точки, но большое количество складывается в интерференционную картину.
Волновые свойства электрона проявляются в том, что его волновая функция (квадрат которой есть вероятность его обнаружения) интерферирует сама с собой. Это кажется очень странным, но, грубо говоря, волновые свойства проявляет вероятность, а не сам электрон.
Фотон может поглотиться лишь целиком. На сетчатке никаких волновых свойств уже нет. Так что в почти идеальной темноте именно так и будет. Только один фотон вносит слишком слабый вклад и почти неразличим, поэтому не будет ярких точек на чёрном фоне.
> “Идеальной” картинки никогда не будет
Ну смотря что считать идеальной. В глаз тоже за секунду прилетает определённое количество фотонов, которое можно посчитать. Другое дело, что оно очень велико, но не бесконечно :)
Открыл ссылку, увидел ролик. Вспомнил, как в детстве я брал шприц без иголки, втыкал его в морковь так, чтобы наконечник забился кусочком моркови, а затем резко бил по поршню.
Лучше всего подходила именно морковь за большую плотность.
И непонятно, с чего вдруг у программиста должны быть проблемы в личной жизни. Если ты так хорошо понимаешь причинно-следственные связи — управляй.
«Мы не властны над своими эмоциями, но властны над своим поведением „
stelazin.livejournal.com/
Я люблю эмоции, и сам обустраиваю жизнь так, чтобы испытывать эмоции. Я знаю, когда и какие я буду испытывать, но это мне не мешает.
Если я съем что-то вкусное, оно будет вкусное, даже если я знаю, что и зачем я ем.
А то так можно и про лямбды сказать «делайте struct с operator ()»
Собственно, именно про удобство всегда и говорят, ибо иначе нечего обсуждать, языки Тьюринг-полные.
Можно использовать withFile, но с ним неудобно открывать список файлов, ведь он принимает callback.
Но тут приходит на помощь монада Cont.
file :: FilePath -> IOMode -> ContT r IO Handle
file f m = ContT $ withFile f m
files :: IOMode -> [FilePath] -> ContT r IO [Handle]
files m fs = mapM (\f -> file f m) fs
Теперь и защита от исключений, и без вложенных withFile.
В Haskell STM (Software Transactional Memory) реализовано в виде библиотеки. Благодаря тем самым «костыльным» монадам для состояния, у нас есть гарантия того, что всё STM изолировано и мы не можем внутри обращаться к «левым» ссылкам.
Как дать такие гарантии там, где потенциально всё — IO?
Также есть монада ST, мы можем локально заводить мутабельные переменные, но так как они изолированы, итоговое вычисление гарантированно чистое. Оборачиваем это в runST и получаем чистое значение, реализованное императивным способом. Это аналогично pure из D, но без дополнительного ключевого слова и какого-то специального анализа компилятора.
Вопрос тот же, как это сделать в языке, где нет таких «костылей»? В D пришлось ввести новое ключевое слово.
Я пишу на нём уже несколько лет, писал WebSocket-сервер, mp3tags-декодер (ибо текущие реализации на тот момент на любом языке многие не поддерживали даже сжатия, не говоря о шифровании), и почему-то пока не столкнулся с ситуацией, где «все перечисленные достоинства» исчезали бы.
В случае языков ситуация, когда недостающая функциональность обходится другими средствами языка, при этом крайне неудобно. Как лямбды в C++03, например (boost::bind + boost::lambda).
Так вот чистота и ленивость — это фундаментально в Haskell, и сделано намеренно. И различие между IO/State/whatever и чистыми функциями тоже сделано намеренно. Это меняет подход, это неудобно новичкам, но это не костыль.
У сколь-нибудь опытных программистов на Haskell с этим проблем нет.
Смотрите сразу страницу 24 (картинка) и 25 (код).
Оцените декларативность, схема почти напрямую переписана.
То, что новичку что-то там не понятно, не тянет на аргумент о костыльности в системе.
Может, и теория групп в математике тогда костыли?
map от mapM отличаются не только тем, что там монада, а и тем, что для map выполняются функторные законы, для mapM — нет.
Тот же mapM можно написать как минимум двумя способами.
В хаскеле не нужно знать «тонкости», надо понимать, что такое чистота. Новичку и впрямь непривычно, но на костыльность это не указывает.
Ну, а Async-monad — костыль для асинхронный действий?
А Cont-monad, надо полагать, костыль для call/cc?
В чём костыльность-то проявляется?
Эдак можно сказать, что async/await — костыль для языков, где нет нормальных монад.
Хотя можно придерживаться т.з., что объекты — замыкания для бедных, а замыкания — объекты для бедных.
Волновые свойства электрона проявляются в том, что его волновая функция (квадрат которой есть вероятность его обнаружения) интерферирует сама с собой. Это кажется очень странным, но, грубо говоря, волновые свойства проявляет вероятность, а не сам электрон.
Ну смотря что считать идеальной. В глаз тоже за секунду прилетает определённое количество фотонов, которое можно посчитать. Другое дело, что оно очень велико, но не бесконечно :)
Лучше всего подходила именно морковь за большую плотность.