Здравствуйте, D. Mon, Вы писали:

DM>А вот интересно было бы увидеть эдакий хит-парад монад, используемых в коде на хаскеле, отсортированный по частоте использования. Вроде: "из 12345 модулей на hackage 96% используют монаду List, 90% используют IO для ввода-вывода, 85% используют ST для мутабельных векторов, 61% использует Reader" и т.д.
DM>Не удивлюсь, если 83% использованных монад придутся как раз на те вещи, что в императивных языках встроены.

Такой хит-парад будет осмыслен только в сопоставлении с альтернативами:

— n1% используют монаду List во всей полноте
— n2% — ограничиваются синтаксисом set comprehension
— n3% — фолд-мап-фильтр
— n4% упорствуют в ереси и пишут на хаскелле, как на лиспе 50-х, с рукодельной рекурсией

— n1% используют функции высшего порядка над IO
— n2% — do-нотацию, шоб красиво было
— n3% — конвеер-панки, пишут >>= \_ -> ...
— n4% — хакают ввод-вывод, вручную расставляя энергичные вызовы сишных функций

— n1% используют Reader для протягивания неявных параметров
— n2% протягивают параметры вручную
— n3% обвязывают всё в гигантские let-выражения или ещё как-то выкручиваются

и т.д.

Тогда будет видно — где именно истинная сосисочность монады востребованы, а где земная оболочка бездумный синтаксический сахар.

Здравствуйте, Ikemefula, Вы писали:

I>Не хочу за тебя додумывать. Очевидно, реактивная обработка у тебя не получилась, ты скипнул основную часть, так шта

Так это и не было темой обсуждения) Однако, как ты сам увидел, это делается даже ещё короче цикла. )

I>Это заблуждение. Самый глубокий блок == листовой блок, т.е. тот у которого нет других блоков. Здесь нужен простейший автомат с магазином. Очевидно, все что нужно, это получить закрывающий токен, ни больше, ни меньше. Все что после этого токена никого не интересует.

Ну конечно. )))

begin
    begin
    end//вот у нас тут листовой блок и что?
    begin
        begin
        end//ещё листовой и вот он самый глубокий
    end
end

I>Насколько коряво выглядит грамматика в query comprehension С# не имеет никакого отношения к монадам, вообще.

Тут дело как раз в в query comprehension, а не в C#. Я думаю что можно даже на C# (там же хотя бы переопределение операторов то есть) реализовать задание БНФ намного красивее, чем тот дикий ужас.

I>Ты пока не показал никакого релевантного кода, вообще. Если так будет и дальше, мой вариант окажется наилучшим

Под тот конкретный пример очевидно же что даже линейный код (и без всяких библиотек) вышел проще. Но это на самом деле довольно бредовое сравнение не имеющее особого смысла для нашей дискуссии и являющиеся лишь следствием плохого выбора примера (пример использование библиотеки явно должен быть удонее тупого кода в лоб). Реально же для подобного сравнения надо взять какую-то библиотеку для подобного же анализа коллекций, но реализованную не через монады (причём лучше на том же C#, чтобы влияние разницы языков не влезало). И сравнить удобство их использования.

Здравствуйте, alex_public, Вы писали:

_>Ну конечно. )))

Именно так — листовые.

I>>Насколько коряво выглядит грамматика в query comprehension С# не имеет никакого отношения к монадам, вообще.

I>>Ты пока не показал никакого релевантного кода, вообще. Если так будет и дальше, мой вариант окажется наилучшим

_>Под тот конкретный пример очевидно же что даже линейный код (и без всяких библиотек) вышел проще.

Твой линейный ни о чем. Код который я тебе дал он рабочий, надо только референсы на сборки добавить и запустить. А у тебя мусор.

Здравствуйте, Ikemefula, Вы писали:

I>Именно так — листовые.

Ну так тебе нужные листовые элементы или же один самый глубокий? Если первое, то нафига тебе вообще какие-то парсеры, если достаточно завести одну булеву переменную и всё. А если второе, то опиши как твой парсер будет работать не имея весь набор данных.

I>Твой линейный ни о чем. Код который я тебе дал он рабочий, надо только референсы на сборки добавить и запустить. А у тебя мусор.

Этот тоже можно запустить и получить такой же результат, причём он даже ни одной левой библиотеки не использует. )))

Здравствуйте, alex_public, Вы писали:

I>>Именно так — листовые.

_>Ну так тебе нужные листовые элементы или же один самый глубокий?

А что, слово "листовые" оставляет какие то варианты ?

>Если первое, то нафига тебе вообще какие-то парсеры, если достаточно завести одну булеву переменную и всё.

Пудозреваю "одну булеву переменную и всё" == автомат с магазином + одна булева переменная.

I>>Твой линейный ни о чем. Код который я тебе дал он рабочий, надо только референсы на сборки добавить и запустить. А у тебя мусор.

_>Этот тоже можно запустить и получить такой же результат, причём он даже ни одной левой библиотеки не использует. )))

Да, допилить напильником и дописать основную логику.

Здравствуйте, alex_public, Вы писали:

_>Вообще то в том моём примере с boost.optional был как раз буквально этот код. И я что-то не увидел каких-то проблем с ним.

Так я про обобщенный liftM2, sequence и т.д. а не специализированный для optional

_>Так речь идёт не о тестовых примерах придуманных для этого форума, а о реальной практике. Т.е. например о каких-то известных библиотеках или архитектурах. Но опять же на определённых языках.

Так Ikemefula вам привел пример — Reactive Extensions. Библиотека реальная, используемая на практике. И это в языке, в котором пользы от монад можно получить самый минимум. На момент написания этого поста ее установили nuget-ом 144788 раз.

_>Ну а если скажем Питон возьмём? )

Если возьмем Питон — тоже ничего хорошего не получится.

_>А чего конкретно в C++ не хватает для поддержки подобной функциональщины?

Да, собственно, всего. Там даже Upward Funarg Problem не решена. А это самый минимум, необходимый для того, чтоб вообще можно было о какой-то поддержке ФП говорить. Это даже в C# есть.

_>Ага, т.е. в итоге похоже что вы согласны с моей оценкой пользы от монад...

У нас с вами есть расхождение по вопросу их необходимости в чистом ФЯ. В Хаскеле монады используют потому, что могут. И они не существуют как-то изолированно — это только один из элементов общего принятого там "алгебраического" подхода к дизайну библиотек. И этот подход может быть полезен везде (хоть и в разной степени, потому что полагается на реализацию преимуществ, которые не во всех языках есть). Применение монад в гибридных языках не вопрос их (монад) полезности, а вопрос реализуемости в них (языках) такого подхода.
Просто декларируемая "гибридность" зачастую остается только декларацией, не подкрепленной чем-то практическим. В большинстве таких языков ФП-фичи существуют "для галочки"

Автор: Klapaucius
Дата: 01.11.13

, потому что это модно, но при попытке их использовать в сколько-нибудь заметных масштабах все сразу рассыпается.

Здравствуйте, D. Mon, Вы писали:

DM>Не удивлюсь, если 83% использованных монад придутся как раз на те вещи, что в императивных языках встроены.

"Встроены" не самое подходящее слово. Оно создает ложное впечатление о том, что обеспечивается равноценная монадам функциональность. Но песок — неважная замена овсу, в данном случае "встроенность" — красивое слово для обозначения того, что таких монад там нет.

Здравствуйте, alex_public, Вы писали:

_>Это же всё довольно мрачновато выглядит... ) В то время как на других языках (которые тут обсуждали) всё наоборот и подобный код чаще всего выглядит проще варианта с монадами.

Вопрос в том, насколько он подобный? Это декларативный код, который отличается от кода на "других языках", как код на прологе отличается от кода на фортране. Одно дело система контроля за эффектами и их комбинирования (оставляющая желать много лучшего, на самом деле), другое дело — отсутствие какого-то контроля и комбинирования.
Также, IO/ST код на хаскеле часто выглядит мрачно из-за "карательного" подхода. Т.е. функции для работы с ST-ссылками называются в стиле написаниеНазванияЭтойФункцииЯвляетсяНаказаниемЗаИспользованиеИзменяемыхСсылок, синтаксическая поддержка откровенно убогая/страшная (особенно в период, когда не было Monad Comprehensions, а Idiom Brackets и сейчас нет) и т.д. "Карательный" подход — это глупость, конечно, но это все решаемые проблемы.

Здравствуйте, Klapaucius, Вы писали:

K>Так я про обобщенный liftM2, sequence и т.д. а не специализированный для optional

Не вижу никаких проблем и с liftM2 в C++ — пишется в пару строк. Естественно подразумевая свою реализацию под каждый вид монад (например для optional). Если же подразумевается написать liftM2 подходящий для любой монады и просто использующий для непосредственной работы код liftM (который уже свой для каждого вида монад), то такое действительно сложно написать на C++. Но хочу заметить, что для многих монад прямая реализация liftM2 (а при большем числе аргументов тем более) будет более эффективна чем последовательное применение. Скажем для optional это может означать один if вместо двух. )

K>Так Ikemefula вам привел пример — Reactive Extensions. Библиотека реальная, используемая на практике. И это в языке, в котором пользы от монад можно получить самый минимум. На момент написания этого поста ее установили nuget-ом 144788 раз.

Если мы говорим про базовую идею Reactive Extension, то естественно к ней нет никаких претензий — это же один из самых известных паттернов проектирования (и кстати монады тут вообще ни при чём). Правда его очень часто реализуют в своём коде (там десятка строк достаточно на всё), а не подключают какие-то внешние библиотеки. Но и так тоже не плохо. Было бы... Если бы они не задумали притащить и сюда этот кривой linq синтаксис, который всё портит. Это же уже мания какая-то, пытаться всунуть его везде, даже если он и близко не подходит. Вот как раз на примере Ikemefula это очень хорошо видно. Там прослеживается попытка записать что-то типа БНФ через linq подобный синтаксис — так это же дикая жуть вышла! В то время как можно было придумать какой-то красивый способ задания БНФ (например использовать перегрузку операторов), взять тот же самый паттерн Наблюдатель и получить в итоге на том же C# красивый и удобный код. Правда монад тут скорее всего не было бы тогда... Так что пример Ikemefula для меня выглядит скорее как антипример. )))

K>Если возьмем Питон — тоже ничего хорошего не получится.

Ну так а хотя бы один подходящий мультипарадигменный язык есть?

K>Да, собственно, всего. Там даже Upward Funarg Problem не решена. А это самый минимум, необходимый для того, чтоб вообще можно было о какой-то поддержке ФП говорить. Это даже в C# есть.

Правильнее сказать, что решение не зашито жёстко в язык, а отдано на выбор программиста, т.к. различные решения могут иметь разную эффективность в разных условиях.

K>У нас с вами есть расхождение по вопросу их необходимости в чистом ФЯ. В Хаскеле монады используют потому, что могут. И они не существуют как-то изолированно — это только один из элементов общего принятого там "алгебраического" подхода к дизайну библиотек. И этот подход может быть полезен везде (хоть и в разной степени, потому что полагается на реализацию преимуществ, которые не во всех языках есть). Применение монад в гибридных языках не вопрос их (монад) полезности, а вопрос реализуемости в них (языках) такого подхода.

Хех, похоже что дискуссия о пользе монад в различных языках всё же не возможна, пока не определимся с вопросом пользы монад вообще. Потому как допустим у нас есть два противоположных тезиса:

1. В C++ монады редко используются из-за того, что язык не подходящий (подразумевая что сами по себе монады крайне полезные везде, но C++ такой убогий, что не позволяет удобно использовать их везде).
2. В Хаскеле монады используются постоянно из-за того, что без них совсем грустно (подразумевая что сами по себе монады нафиг не нужны, но Хаскель такой убогий, что без них заниматься реальной работой очень неудобно).

Какой из них ближе к истине? ) Зависит как раз от вопроса применимость самой концепции монад к реальному миру. Лично по моим ощущениям: задачи отлично ложащиеся на концепцию монад в природе есть, но их совсем не много.

K>Просто декларируемая "гибридность" зачастую остается только декларацией, не подкрепленной чем-то практическим. В большинстве таких языков ФП-фичи существуют "для галочки"

Автор: Klapaucius
Дата: 01.11.13

, потому что это модно, но при попытке их использовать в сколько-нибудь заметных масштабах все сразу рассыпается.

Возможно. Но думаю что будущее всё равно за гибридами. Пока что всё развитие языков программирования свидетельствует именно об этом.

Здравствуйте, Klapaucius, Вы писали:

K>Также, IO/ST код на хаскеле часто выглядит мрачно из-за "карательного" подхода. Т.е. функции для работы с ST-ссылками называются в стиле написаниеНазванияЭтойФункцииЯвляетсяНаказаниемЗаИспользованиеИзменяемыхСсылок, синтаксическая поддержка откровенно убогая/страшная (особенно в период, когда не было Monad Comprehensions, а Idiom Brackets и сейчас нет) и т.д. "Карательный" подход — это глупость, конечно, но это все решаемые проблемы.

Так тут возможно и кроется один из ключевых моментов дискуссии: монады широко используются в Хаскеле потому что он это позволяет или же потому что он к этому принуждает (без них намного неудобнее)?

Здравствуйте, Klapaucius, Вы писали:

DM>>Не удивлюсь, если 83% использованных монад придутся как раз на те вещи, что в императивных языках встроены.
K>"Встроены" не самое подходящее слово. Оно создает ложное впечатление о том, что обеспечивается равноценная монадам функциональность.

Нет, я на такое не намекаю даже. Встроены состояния, встрен ввод-вывод, встроены исключения. Т.е. не сами именно монады, но те вещи, ради которых монады, возможно, задействованы в 83% кода на хаскеле. Не пишут же монадный код ради самих монад, ими решают какие-то определенные нужды.

K> Но песок — неважная замена овсу, в данном случае "встроенность" — красивое слово для обозначения того, что таких монад там нет.

В данном случае нам нужен именно песок (ввод-вывод, состояния..).

Здравствуйте, alex_public, Вы писали:

_>Если же подразумевается написать liftM2 подходящий для любой монады

Да, именно это и подразумевается.

_>и просто использующий для непосредственной работы код liftM (который уже свой для каждого вида монад), то такое действительно сложно написать на C++.

Вообще-то liftM2 с помощью только liftM не написать, хоть на C++, хоть на чем угодно другом. Тем не менее, написать liftM2 для любой монады, разумеется, можно.

_>один if вместо двух.

Да, если оптимизатора нормального нету.

_>Если мы говорим про базовую идею Reactive Extension, то естественно к ней нет никаких претензий — это же один из самых известных паттернов проектирования

Нет, базовая идея — это комбинаторы для этого "одного из самых известных паттернов проектирования" и в них же — комбинаторах — весь его смысл.

_>Ну так а хотя бы один подходящий мультипарадигменный язык есть?

Подходящий для чего?

_>Правильнее сказать, что решение не зашито жёстко в язык, а отдано на выбор программиста, т.к. различные решения могут иметь разную эффективность в разных условиях.

Вот только лучшего и наиболее практичного решения среди вариантов выбора для программиста на C++ нет. А то, что есть — вообще трудно считать "решениями UFP".

_>1. В C++ монады редко используются из-за того, что язык не подходящий (подразумевая что сами по себе монады крайне полезные везде, но C++ такой убогий, что не позволяет удобно использовать их везде).
_>2. В Хаскеле монады используются постоянно из-за того, что без них совсем грустно (подразумевая что сами по себе монады нафиг не нужны, но Хаскель такой убогий, что без них заниматься реальной работой очень неудобно).

Моя позиция близка к 1) с той поправкой, что вместо "редко используются" будет "не используются".

_>задачи отлично ложащиеся на концепцию монад в природе есть, но их совсем не много.

Вот уж точно. Возвращать что-то из одних функций и потом передавать в другие — это крайне экзотическая задача. В реальной жизни этого, разумеется, программисты никогда не делают.

_>Возможно. Но думаю что будущее всё равно за гибридами.

В краткосрочной перспективе — да, в среднесрочной — нет.

Здравствуйте, alex_public, Вы писали:

_>Так тут возможно и кроется один из ключевых моментов дискуссии: монады широко используются в Хаскеле потому что он это позволяет или же потому что он к этому принуждает (без них намного неудобнее)?

Вы не поняли, "карательный" подход сдерживает использование IO/ST. А данная ветка дискуссии вообще о том, что "использовать IO" и "использовать монады" — это не одно и то же. Хаскельная базовая библиотека действительно так спроектирована, что она с одной стороны принуждает использовать IO/ST, а с другой — сдерживает их использования для пресечения "злоупотребления" или аналогичного сомнительного повода. Но монады-то тут причем?

Здравствуйте, D. Mon, Вы писали:

DM>Нет, я на такое не намекаю даже. Встроены состояния, встрен ввод-вывод, встроены исключения. Т.е. не сами именно монады, но те вещи, ради которых монады, возможно, задействованы в 83% кода на хаскеле. Не пишут же монадный код ради самих монад, ими решают какие-то определенные нужды.

Монады задействованы для того, чтоб повторно использовать код. А IO/ST, вне зависимости от того, были бы они монадами или нет, для того, чтоб в языке были нормальные комбинирующиеся комбинаторы при сохранении возможности пользоваться изменяемым состоянием (без которого все рано никак нельзя). Они для того, чтоб можно было писать чистый код и оптимизировать его, а не для того, чтоб массив менять по месту. Потому, что второе и без них можно, а вот первое — нельзя (упрощенно говоря, понятно, что есть другие способы получить это, помимо IO/ST). Поэтому говорить, что IO/ST в хаскеле существуют для того же, для чего в императивных языках состояния, по моему, в корне неверно.
Из этого заблуждения все подобные разговоры и растут. Понятно, что человек ставит вопрос таким образом: "IO/ST нужны для того, чтоб было изменяемое состояние" и потом недоумевает: "но в моем Алгол++ изменяемое состояние есть без всяких IO/ST, как же так?". Ну а IO/ST на самом деле нужно для того, чтоб в языке были функции, которых в Алгол++ как раз и нет — одни процедуры.

Здравствуйте, Klapaucius, Вы писали:

K> Тем не менее, написать liftM2 для любой монады, разумеется, можно.

Ну правильно, весь вопрос в том, где будет браться информация об особенностях конкретной монады. Кстати здесь какой вариант подразумевался?

K>Нет, базовая идея — это комбинаторы для этого "одного из самых известных паттернов проектирования" и в них же — комбинаторах — весь его смысл.

Ага, на базе sql-подобного языка (он для коллекций то даже далеко не идеал, а уж тут вообще молчу) — в топку!

_>>Ну так а хотя бы один подходящий мультипарадигменный язык есть?
K>Подходящий для чего?

Для широкого использования монад.

K>Вот уж точно. Возвращать что-то из одних функций и потом передавать в другие — это крайне экзотическая задача. В реальной жизни этого, разумеется, программисты никогда не делают.

А причём тут монады? )))

Здравствуйте, Klapaucius, Вы писали:

K>Вы не поняли, "карательный" подход сдерживает использование IO/ST. А данная ветка дискуссии вообще о том, что "использовать IO" и "использовать монады" — это не одно и то же. Хаскельная базовая библиотека действительно так спроектирована, что она с одной стороны принуждает использовать IO/ST, а с другой — сдерживает их использования для пресечения "злоупотребления" или аналогичного сомнительного повода. Но монады-то тут причем?

Монады тут при том, что хотя они не обязательны, они сильно облегчают работу. Кстати, когда я когда смотрел примеры работы на Хаскеле с системными задачами (например работа с неким gui фреймворком), то там обычно вообще всё приложение занимала одна гигантская IO монада! Мне кажется, что всё же авторы языка подразумевали несколько иные пропорции. Но как видим при столкновение с практическими, а не академическими задачками, мы получаем вот такую реальность...

Так вот лично мне вся эта ситуация всё же кажется следствием недостатков Хаскеля (которые монады слегка подправляют), а не преимуществом позволяющим свободно использовать монады. )))

Хотя для чистоты эксперимента нам нужна всего лишь один простой пример: язык программирования в котором монады реализуются так же легко, как и в Хаскеле, но при этом не имеющий вышеописанных проблем Хаскеля. Соответственно, если мы увидим, что и в нём люди используют монады на каждом шагу, то это будет означать их реальную повсеместную пользу. Ну а если же нет, то... )))

Здравствуйте, Нахлобуч, Вы писали:

G>>Или не до конца понимаете в программировании?
Н>Не совсем программирование, но все же. Не могу понять, в чем такая прелесть vi/emacs (если пользователи не врут).

Там довольно мощные средства обработки текста.
Я сейчас для работы с кодом перелез на MSVS, но время от времени использую vim для вспомогательных задач. Например, сейчас я работаю с исходниками, обрабатывающими tsv-файлы. Часто бывает нужно, например, найти все строки, где в нужном столбце заданное значение. Или добавить ко всем значениям в определённом столбце порядковый индекс. Или поменять столбцы местами. Ну и т.д.

Очень часто бывает нужно вставить кусок текста в юниттест, при этом нужно экранировать все кавычки.

vim имеет удобно интегрированную поддержку регулярных выражений, что позволяет легко и быстро производить такую обработку текста.

vim я использовал для кодинга на с/с++/erlang/tcl/python/bash много лет. Потом решил освоить emacs, но за несколько лет так и не смог отучить его от некоторых неприятных особенностей поведения. Главной неприятностью оказалась его принципиальная однопоточность, а следовательно всякие медленные операции вроде парсинга исходников нельзя перевести в фон. Поэтому лет 5 назад перелез на Eclipse, а сейчас на MSVS, т.к. пишу на шарпе.

Здравствуйте, alex_public, Вы писали:

K>> Тем не менее, написать liftM2 для любой монады, разумеется, можно.
_>весь вопрос в том, где будет браться информация об особенностях конкретной монады.

liftM2 можно написать для любой монады безотносительно ее особенностей.

_>Ага, на базе sql-подобного языка

Не обязательно.

_>(он для коллекций то даже далеко не идеал, а уж тут вообще молчу) — в топку!

Непонятно, почему вам не нравится именно query expressions. Они как то выделяются из всего остального что ли? По моему, в C# синтаксис буквально всего страшнее атомной войны. Ну так даже query expressions часто лучше, чем лямбда-лапша.

_>Для широкого использования монад.

Есть широкий спектр языков в которых можно какую-то пользу от монад в какой-то форме получать. Ну ее и получают.

K>>Вот уж точно. Возвращать что-то из одних функций и потом передавать в другие — это крайне экзотическая задача. В реальной жизни этого, разумеется, программисты никогда не делают.
_>А причём тут монады? )))

При том, что вот для этого монады и применяются. Т.е. если вы пишете на брейнфаке, например, то практической пользы от монад не будет. Как только появляются какое-то подобие функций, так сразу можно и какую-то пользу извлекать и по мере того, как подобие функций становится функцией — все больше и больше.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Dair, Вы писали:

D>>Для меня загадка — современные алгоритмы шифрования (криптографии). Мат.аппарата не хватает

D>>На практическом уровне — public key/private key понятно, но чо там внутри — чисто магия.

_>Да ладно, если говорить о принципах, то там же всё вообще тривиально.

_>Вот смотри, предположим у нас есть функция y=exp(x); и соответственно обратная ей x=ln(y); Причём (и это ключевой момент) ln вычисляется намного дольше, чем exp. Кстати, это и для обычных exp и ln справедливо, а в асимметричной криптографии используется спец. вариант, в котором ln вычисляется годами... Теперь, при наличие пары таких функций, мы можем тривиально наладить защищённый канал.

_>Вот предположим у нас есть два человека (1 и 2) с каждый стороны и ещё третий, прослушивающий канал. 1 и 2 генерируют по одному случайному числу k1 и k2. Затем считают от них p1=exp(k1) и p2=exp(k2). И отсылают друг другу. В итоге у первого есть k1 и p2, у второго k2 и p1, а у прослушивающего p1 и p2. Теперь первые два считают число z=p2^k1=p1^k2=exp(k1*k2) — теперь у них есть некий общий секрет z, который они могут использовать например как ключ для обычного блочного шифрования данных и спокойно обмениваться ими. Ну а бедный подслушивающий будет занят вычислениями ln(p1) или ln(p2), для того чтобы получить тот же самый z...

Насколько я понимаю — это все работает только в том случае, если третий человек умеет только читать канал, но не умеет в него писать?? Потому что если он умеет писать, то он банально перехватит от юзера1 его p1 и заменит на p1_fake=exp(k1_fake). для юзера2 тоже самое, его p2 меняется на p2_fake=exp(k2_fake) и отправляется юзеру1.
В результате слушатель может читать сообщения и того и другого юзера. ПРичему например полученное от юзера1 сообщение он может зашифровать используя p2^k1_fake и отправить юзеру2 и оба юзера будут думать, что они друг с другом разговаривают.

От этого же как то защищаются, вроде всякие сертификаты как раз для это?? Можно на таком же уровне, для дошкольников, объяснить как они работают??

Здравствуйте, alex_public, Вы писали:

_>Монады тут при том, что хотя они не обязательны, они сильно облегчают работу.

И в чем, по вашему, специфика этого облегчения? Почему тут вы видите, что они облегчают, а относительно других языкуов у вас сомнения?

_>Кстати, когда я когда смотрел примеры работы на Хаскеле с системными задачами (например работа с неким gui фреймворком), то там обычно вообще всё приложение занимала одна гигантская IO монада!

Что за гигантская монада? И что значит "все приложение занимает"? Вы это можете как-то расшифровать?

_>Мне кажется, что всё же авторы языка подразумевали несколько иные пропорции. Но как видим при столкновение с практическими, а не академическими задачками, мы получаем вот такую реальность...

Ну так IO и нужно для "системных задач". Если вы пишете вычисления факториалов, то никакой пользы от контроля за эффектами нет, тут какой-нибудь ML не хуже чистого языка. Ну, а чем больше "системных задач", тем больше пользы от системы контроля за эффектами, в случае хаскеля — от IO/ST.

_>Хотя для чистоты эксперимента нам нужна всего лишь один простой пример: язык программирования в котором монады реализуются так же легко, как и в Хаскеле, но при этом не имеющий вышеописанных проблем Хаскеля. Соответственно, если мы увидим, что и в нём люди используют монады на каждом шагу, то это будет означать их реальную повсеместную пользу. Ну а если же нет, то... )))

О каких проблемах идет речь? Об использовании IO для того, для чего IO предназначено? И где тут проблема? Вы свои претензии как-то более конкретно выразите, без "больших монад", которые "место занимают".