Комментарии 18
НЛО прилетело и опубликовало эту надпись здесь
Эрланг не чистый.
Потому что всё не так просто. А именно prog21.dadgum.com/4.html, да и вообще prog21.dadgum.com/archives.html. Рекомендую.
Цитата:
В императивном языке намного проще реализовать такое поведение, ведь мы можем реагировать на какие либо события «в реальном времени», в то время как в чистых функциональных языках нам придётся откладывать общение с системой до самого конца.
Совсем не понятен смысл этого предложения.
В императивном языке намного проще реализовать такое поведение, ведь мы можем реагировать на какие либо события «в реальном времени», в то время как в чистых функциональных языках нам придётся откладывать общение с системой до самого конца.
Совсем не понятен смысл этого предложения.
Попробую объяснить. В Haskell все IO действия выполняются только внутри монады IO (если мы не нарушаем запрет, конечно). И чтобы их выполнить, нам приходиться «нести» эти действия до main, ведь только там IO будет запущена. То есть, например в C, мы можем вывести строку на экран или считать её в любом месте программы, а в Haskell мы будем ждать до тех пор, пока не сформируем окончательное IO действие в main.
Т.е. в Haskell действия делятся на те что можно выполнять за пределами main, и те что нельзя? В нашем случае ввод-вывод.
Скажем так — в Haskell действия делятся на IO и на все остальные. IO действие может прийти из любой точки программы, но выполнится оно только в main.
А в чем профит-философия такого подхода?
Это и есть та хвалёная чистота Haskell. Так как IO действия и остальной код разделены, мы не можем поменять какую либо переменную прямо в ходе программы или считать что-либо извне. Значит функции будут всегда предсказуемы: на один аргумент всегда тот же ответ. Это сильно упрощает отладку, позволяет проводить мощные оптимизации компилятором, а также даёт возможность работать с кодом как с математическими выражениями. Вот тут про это немного рассказано: Чистота языка программирования
Ну на самом деле конечно и переменные есть и всё прочее, но на Haskell так писать не принято. Само разделение на IO и не-IO уже провоцирует код разделять на логику и ввод-вывод.
И в этом смысле очевидный способ реагировать на события «грязными» IO-функция сработает, конечно, и в Haskell, но это не идиоматично.
Сразу возникает вопрос, а зачем надрываться? Поначалу это кажется пустой тратой времени, но потом выясняется, что работать разделенной логикой и вводом-выводом намного проще. Divide et impera.
И в этом смысле очевидный способ реагировать на события «грязными» IO-функция сработает, конечно, и в Haskell, но это не идиоматично.
Сразу возникает вопрос, а зачем надрываться? Поначалу это кажется пустой тратой времени, но потом выясняется, что работать разделенной логикой и вводом-выводом намного проще. Divide et impera.
Пожалуйста, не вводите людей в заблуждения. И поймите вещи немного получше, прежде чем объяснять их другим людям.
Тип IO может иметь не только функция main. Можно написать программу, где вообще все определённые пользователем функции будут иметь тип IO. Соответственно и «действия» выполняться могут там.
«в Haskell мы будем ждать до тех пор, пока не сформируем окончательное IO действие в main» — эта фраза вообще не имеет никакого смысла.
Тип IO может иметь не только функция main. Можно написать программу, где вообще все определённые пользователем функции будут иметь тип IO. Соответственно и «действия» выполняться могут там.
«в Haskell мы будем ждать до тех пор, пока не сформируем окончательное IO действие в main» — эта фраза вообще не имеет никакого смысла.
Скорее всего я просто не смог правильно выразить свои мысли.
Я знаю, что любая функция может иметь тип IO, но сама по себе IO не выполнится. Чтобы увидеть хоть какой-нибудь эффект от неё, мы должны либо добавить её в main (unsafePerformIO и вызвать из ghci не рассматриваем).
Грубо говоря, идея моей фразы в том, что чтобы выполнить IO действие в Haskell, мы обязаны сделать это внутри монады IO, которая «оживёт» только в main.
В принципе, если у Вас есть идея как сделать то моё высказывание (из первого абзаца) понятней, я приму это предложение.
Я знаю, что любая функция может иметь тип IO, но сама по себе IO не выполнится. Чтобы увидеть хоть какой-нибудь эффект от неё, мы должны либо добавить её в main (unsafePerformIO и вызвать из ghci не рассматриваем).
Грубо говоря, идея моей фразы в том, что чтобы выполнить IO действие в Haskell, мы обязаны сделать это внутри монады IO, которая «оживёт» только в main.
В принципе, если у Вас есть идея как сделать то моё высказывание (из первого абзаца) понятней, я приму это предложение.
Да, и это неправильное выражение мыслей вводит в заблуждение.
Здесь нет ничего специфичного для хаскеля. Чтобы увидеть эффект от любой фукции в Си мы должны точно также добавить её в main.
Если бы я понимал что вы хотите выразить этим высказыванием, я бы не задавал свой вопрос.
Здесь нет ничего специфичного для хаскеля. Чтобы увидеть эффект от любой фукции в Си мы должны точно также добавить её в main.
Если бы я понимал что вы хотите выразить этим высказыванием, я бы не задавал свой вопрос.
Я надеялся, что смог объяснить его смысл :-P
Наверное не стоило заострять внимание на откладывании IO действий, к тому же FRP даёт выигрыш совсем в другом месте.
«В императивном языке намного проще реализовать такое поведение, ведь в нём мы можем изменять состояние программы, в то время как в чистом функциональном языке нам придётся оперировать специальным громоздким типом для состояния, передавая его из одной функции в другую.» — эта фраза достаточно ясна? Смысл совсем другой, но по-моему, она намного лучше отражает проблему, решаемую FRP.
Наверное не стоило заострять внимание на откладывании IO действий, к тому же FRP даёт выигрыш совсем в другом месте.
«В императивном языке намного проще реализовать такое поведение, ведь в нём мы можем изменять состояние программы, в то время как в чистом функциональном языке нам придётся оперировать специальным громоздким типом для состояния, передавая его из одной функции в другую.» — эта фраза достаточно ясна? Смысл совсем другой, но по-моему, она намного лучше отражает проблему, решаемую FRP.
Даже unsafePerformIO не выполнит IO-действие, пока его обратно не обернут так или иначе в IO в main. Потому что реальные вычисления только там (и оттуда же форсируются чистые).
Т.е.
Т.е.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реактивное программирование