Есть ли вещи, которые вы прницпиально не понимаете... - Философия программирования

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

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

То, что для любой можно — это без сомнения. Вопрос в том, как мы будем учитывать индивидуальные особенности этой монады. Можно это сделать написав код liftM2 для каждого вида монад отдельно (это кстати наиболее оптимизированный по быстродействию, но затратный по разработке вариант). А можно вынести учёт особенностей в отдельную абстракцию (и эти сущности уже должны быть под каждый тип монад) и тогда соответственно можно написать как бы единый код liftM2 для всех типов монад. Вот я соответственно и спрашиваю, в какой конкретно абстракции предлагается скрывать особенности реализации конкретного вида монад.

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

Неее, мне не именно query expressions. Ведь это всего лишь вариант записи. Но даже если мы записываем через лямбды, то всё равно набор базовых примитивов остаётся как раз полностью соответствующим sql. И вот он то мне и не нравится. Собственно он и для баз данных мне не особо, но там ещё можно терпеть по определённым причинам (хотя в последнее время nosql стараюсь использовать — намного удобнее). А уж когда это суют не только в базы данных, а буквально везде (в c# мире я имею в виду), то получается реальный ужас.

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

А есть ли среди этого широкого спектра хотя быть один язык со следующими свойствами:
— компилируется в нативный код
— поддерживает императивную парадигму
— не совсем маргинальный.

У меня один подобный язык есть на примете (на букву O который

), но я если честно не в курсе как там обстоят дела с монадами. ))) Я когда игрался с ним, то ничего подобного вроде не встречал.

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

Безусловно. Но только в тех случаях (на мой взгляд совсем не частых), когда реальная задача хорошо ложится на концепцию монад. Однако в некоторых языка монады используются явно гораздо чаще этого. И я предполагаю, что это не от хорошей жизни, а как раз от того, что там кругом "только функции". )

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

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

Не совсем. Просто задачи шифрования канала передачи данных (не обмениваясь при этом секретом в реале) и задача проверки личности собеседника — это в общем то никак не связанные между собой задачи. Т.е. теоретически возможно первое само по себе, возможно второе само по себе. И возможен вариант когда обе техники вместе работают — это как раз вариант SSL.

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

Да там всё очень просто. С одной стороны (которую требуется идентифицировать) присылается не просто p1=exp(k1), а: он же, плюс информация о ресурсе m и плюс электронная подпись s с помощью некоторого ключа c. Электронная подпись s — это всего лишь некий хэш от m и p1, зашифрованный (что-то типа s=exp(h(m, p1)*c); ) ключoм c. А ключ c — это опять же некое случайное число, хранящееся в главном сейфе (типа мегаценность!) центра сертификации. При этом r=exp(c) (так называемый корневой сертификат этого центра) предустановлен в поставке браузера (если мы например про https говорим). Собственно набор p1, m, s и образуют "сертификат" (хотя там ещё куча всякой служебной информации есть, типа сроков, имени центра и т.п., но это уже не главное). Соответственно дальше действия простые — другая сторона получив p1, m, s и имея у себя r путём простейшей проверки может гарантированно убедиться, что p1 честно соответствует m (а это обычно что-то вроде текста "ООО Рога и Копыта"). Очевидно, что прислать другой p1 для того же m невозможно, без знания какого-то нибудь из c. Т.е. при условии, что ни один официальных центров сертификации не занимается жульничеством, система даёт гарантию, что никто не влезет посередине подобного соединения.

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

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

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

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

Ну практически весь код приложения расположен внутри монады IO. Т.е. как бы красивого декларативного ленивого кода Хаскеля, которым он вроде как и хорош, в приложение уже считай что нет вообще.

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

Да, только если классический ленивый декларативный Хаскель (там где он такой применим) обычно обходит другие языки по выразительности, то его монадная часть (подразумевая IO/ST) скорее наоборот, заметно менее удобна, чем аналоги из других языков.

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

Но это всё на самом деле уже совсем другая тема. Это я по сути заговорил уже о самом Хаскеле, а не о монадах.

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

Проблемы "хаскеля без монад" отлично продемонстрировали вы сами в том примере, где показали реализацию IO/ST без монад. Жуть же полная, хотя да, работает...

Проблемы "хаскеля с монадами" я изложил выше.

И естественно это всё актуально не для любого софта, а для интенсивно работающего с системой. Т.е. скажем для какого-нибудь конвертера запускающегося из командной строки и состоящего на 95% из сложного алгоритма такие проблемы точно не актуальны. Только вот в современном мире подобное ПО — это же скорее исключение...

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

_>Этот тоже можно запустить и получить такой же результат, причём он даже ни одной левой библиотеки не использует. )))
Прямо такой же — не получится. Потому, что в исходном коде подразумевается реактивность. Т.е. ваша задача — не энергичный цикл (который встанет в ожидании следующего события, заморозив нативный поток и отожрав мегабайт address space процесса), а как раз функция OnEvent(Event e){Analyze(e.value);}.
Когда вы её напишете, можно будет сравнить объём и понятность кода.

В простых случаях у вас будет получаться более-менее понятный код. Примерно как в обработчике события MouseClick, который отлавливает Double Click путём сравнения текущего клика с предыдущим. Ну, только надо будет руками декларировать все переменные состояния — скалярные в случае тикера/тренда и стек в случае обработчика листьев дерева. А с монадами и прочими автогенераторами стейт-машина генерируется автоматически компилятором.

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

_>То, что для любой можно — это без сомнения. Вопрос в том, как мы будем учитывать индивидуальные особенности этой монады.
Зачем учитывать какие-то особенности?
_>Можно это сделать написав код liftM2 для каждого вида монад отдельно (это кстати наиболее оптимизированный по быстродействию, но затратный по разработке вариант).
То есть вы заранее полагаете, что компилятор хуже вас разбирается в оптимизациях, и хотите делать всё вручную. Почему?

_>А можно вынести учёт особенностей в отдельную абстракцию (и эти сущности уже должны быть под каждый тип монад)
А это ещё зачем? Все особенности монады уже есть в самой монаде. Никакие дополнительные сущности под каждый тип не нужны. Вы же не пишете какие-то дополнительные сущности под каждый тип коллекции, чтобы разрешить алгоритмам из STL работу с ними.

_>Неее, мне не именно query expressions. Ведь это всего лишь вариант записи. Но даже если мы записываем через лямбды, то всё равно набор базовых примитивов остаётся как раз полностью соответствующим sql. И вот он то мне и не нравится. Собственно он и для баз данных мне не особо, но там ещё можно терпеть по определённым причинам (хотя в последнее время nosql стараюсь использовать — намного удобнее). А уж когда это суют не только в базы данных, а буквально везде (в c# мире я имею в виду), то получается реальный ужас.
Вы по-прежнему не понимаете основной идеи RX. Вот, скажем, когда вы пишете императивный код, который энергично процессит какие-то структуры, вы почему-то мало заботитесь о том, что нужно учитывать все эти ваши локальные переменные, их scope, частоту обращений, и прочее. Регистры за вас прекрасно выбирает компилятор. Вы пишете код типа x[i] = yy[i*aWidth+yoffset+j]*MulY + xx[i*aHeight+xoffset+j]*MulX и не паритесь о том, что на самом деле это элементарно записывается в обратной польской записи, и там даже можно сэкономить на лишних push и pop, подбирая порядок операций. Это привычно и удобно.
А вот когда речь идёт о коде, в котором, к примеру, поток управления диктуется снаружи, вы теряетесь. Попробуйте представить себе код, вычисляющий x[i], в котором нет возможности обратиться к "переменным" типа yy[...], а вместо них приходят внешние вызовы вроде set_yoffset(), set_MulY(), set_i().
При этом про порядок этих вызовов вы знаете не очень много — т.е. он сегодня один, а завтра другой. Конечно же, для каждого случая формулы и порядка прихода значений "легко" написать стейт-машину — вот только при "традиционной" реализации стейт-машины объём её кода будет несопоставим с приведённой формулой, и восстановить её логику крайне тяжело. Как вы поймёте, что делает эта стейт-машина, читая кусочки методов?

RX — это попытка записать подобные штуки в понятном виде. Т.е. вы пишете как бы активный код, который "сам" превращается в реактивный. А уж в каком виде вам удобнее писать предикаты и проекции — ваше дело. Если вам хочется иметь минимум синтаксического мусора, то query comprehensions — ваш выбор. Если вас раздражает SQL (а судя по вашим комментариям про NoSQL это именно так), то вам подойдёт лямбда-синтаксис, с явным выписыванием всех этих (previousEvent, currentEvent) => { return previousEvent.ClickPoint.InRect(new Rect(0, 0, 5, 5).Offset(currentEvent.ClickPoint.X, currentEvent.ClickPoint.Y);}.
С моей точки зрения это та же ручная state machine, вид сбоку.

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

_>Вот я соответственно и спрашиваю, в какой конкретно абстракции предлагается скрывать особенности реализации конкретного вида монад.

Вы переводите разговор в плоскость цены абстракции? Ну, я считаю, что если существует такая возможность улучшить производительность, как выделение некоего сочетания операций и переписывание их определенным образом, то ее неплохо использовать, написав правило перезаписи, в соответствии с которым компилятор перепишет паттерн в более эффективный код автоматически. В конце концов, чистые функции и "алгебраизация" библиотек в том числе для этого и нужны.
Т.е., например, liftM2 для списков дает после специализации два concatMap, которые "фьюзятся" какой-нибудь build/foldr техникой.

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

Не понятно, о каких "базовых примитивах" идет речь если мы используем ФВП и лямбды?

_>А есть ли среди этого широкого спектра хотя быть один язык со следующими свойствами:
_>- компилируется в нативный код
_>- поддерживает императивную парадигму
_>- не совсем маргинальный.
_>У меня один подобный язык есть на примете (на букву O который

), но я если честно не в курсе как там обстоят дела с монадами. ))) Я когда игрался с ним, то ничего подобного вроде не встречал.

Зависит от того, что понимать под словом "маргинальный". Если вопрос сводится к тому, есть ли польза от использования монад в окамле — то ответ: да, есть.

_>Безусловно. Но только в тех случаях (на мой взгляд совсем не частых), когда реальная задача хорошо ложится на концепцию монад. Однако в некоторых языка монады используются явно гораздо чаще этого. И я предполагаю, что это не от хорошей жизни, а как раз от того, что там кругом "только функции". )

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

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

W>А я вот в упор не понимаю, почему такой ппц навороченный оракл не умеет нормальных средств автоматизации?
Все просто. Там внутри такой жуткий индусокод судя по всему, что там что то поменять просто нереально. Чудо что это вообще работает. Уже костыли настолько внутри огромны, что совершенно невозможно без переписывания всей системы с нуля написать хотя бы инсталлятор, чтобы не было дикого геморроя с созданием базы к которой легко подключиться. Про автоматизацию вообще можно молчать — там наверняка внутри архитектура "все связано со всем", и чтоб что то там сделать — нужно это скопипастить в тысячу мест. Проекту уже не один десяток лет, писался толпой индусов — кто то думает что в этом можно разобраться?
Грамотный маркетинг у этого Оракла и ничего более. В результате те, у кого много денег, думают что без оракла невозможно создать даже вебмагазин на 100 товаров, и само слово Оракл сделает продукт безглючным просто оттого, что будет использоваться.

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

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

Нельзя ли конкретнее? О каких проблемах языка в данном случае идет речь?

_>Ну практически весь код приложения расположен внутри монады IO.

Не совсем понятно, что в данном случае понимается под "весь код внутри IO". Все функции, какую детальную декомпозицию мы не предприняли бы имеют сигнатуры вида a -> IO b ? Так не бывает. Все функции вызываются, возможно, через ряд промежуточных функций, из функции вида a -> IO b ? Ну так все программы на хаскеле такие.

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

С точки зрения красоты и декларативности функции a -> IO b не являются функциями второго сорта.

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

Вы сначала вроде бы соглашаетесь с моим доводом, говоря "да", а потом пишете нечто противоположного смысла. Видимо я недостаточно понятно выразился.
Нет никакой пропасти между "классическим" и "монадным" хаскелем, по крайней мере, если я правильно понял, что вы имели в виду.
Как раз наоборот, при написании вычислителей факториалов и чисел Фибоначчи хаскель не имеет принципиального преимущества перед ML-ями. Ну ладно, имеет благодаря ленивости, и это даже в некотором смысле благодаря IO, но сейчас разговор не об этом. При работе с таким кодом и в ML-ях применим equational reasoning (с оговорками, но это и в хаскеле так, их там немногим меньше), и вообще это, в основном, хороший ФП код.
Совсем другое дело, когда дело доходит до решения системных задач. Тут разница принципиальна и выразительность и контроль над сложностью у хаскеля существенно выше, чем у языков, где контроля эффектов нет. Потому, что в хаскеле эффекты первоклассны, типизированны (не достаточно легковесно, правда) и комбинируемы (с оговорками, как принципиального характера, так и связанными с убогостью хаскеля — его системы типов в первую очередь). Поймите меня правильно, система контроля за эффектами хаскеля имеет множество недостатков, критиковать ее можно и нужно, но с позиции других, превосходящих систем контроля за эффектами, а не с позиции отсутствия такой системы. Тут разница, как между языками типизированными и бестиповыми — это разные лиги, тут даже сравнивать нечего.

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

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

_>Проблемы "хаскеля без монад" отлично продемонстрировали вы сами в том примере, где показали реализацию IO/ST без монад. Жуть же полная, хотя да, работает...

Не могли бы вы пояснить, в чем именно жуть. И какая тут связь с монадами (на всякий случай поясню, что то, что я описывал реализовано именно так и в "хаскеле с монадами", в чем собственно и был весь пойнт моего сообщения)?

_>Проблемы "хаскеля с монадами" я изложил выше.

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

_>И естественно это всё актуально не для любого софта, а для интенсивно работающего с системой. Т.е. скажем для какого-нибудь конвертера запускающегося из командной строки и состоящего на 95% из сложного алгоритма такие проблемы точно не актуальны. Только вот в современном мире подобное ПО — это же скорее исключение...

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

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

S>Прямо такой же — не получится. Потому, что в исходном коде подразумевается реактивность. Т.е. ваша задача — не энергичный цикл (который встанет в ожидании следующего события, заморозив нативный поток и отожрав мегабайт address space процесса), а как раз функция OnEvent(Event e){Analyze(e.value);}.
S>Когда вы её напишете, можно будет сравнить объём и понятность кода.

1. Мы в том той ветке дискуссии обсуждали именно парсеры (хотя я бы скорее назвал это некими анализаторами коллекций всё же, ну да ладно), а не реактивность. И код парсера вообще никак не зависит от метода его запуска. Цикл это или же функции обратного вызова — это всё в любом случае относится к коду "генератора данных", а не анализатора.
Т.е. то, что я написал код вида

for(;;){
    Analyze(rand());
    this_thread::sleep_for(chrono::seconds(1));
}

вместо чего-то вроде

auto generator=MakeGenerator(rand, chrono::seconds(1));
generator.Subscribe(Analyzer);
generator.Start();

абсолютно никак не поменяло обсуждаемую функцию Analyzer.

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

S>В простых случаях у вас будет получаться более-менее понятный код. Примерно как в обработчике события MouseClick, который отлавливает Double Click путём сравнения текущего клика с предыдущим. Ну, только надо будет руками декларировать все переменные состояния — скалярные в случае тикера/тренда и стек в случае обработчика листьев дерева. А с монадами и прочими автогенераторами стейт-машина генерируется автоматически компилятором.

Ну так если нам нужен конечный автомат, то для этого есть отличные специализированные инструменты, причём без всяких ужасов типа попытки записать некое подобие БНФ через linq синтаксис. Т.е. для простейших случаев пишем линейный код, а для сложных берём удобный конечный автомат (например boost.statechart). И это всё находится внутри функции Analyzer, которую опять же можно вызывать и внутри цикла и реактивным способом.

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

S>Зачем учитывать какие-то особенности?

Нуу если не надо, то тогда можно показать пример реализации liftM2 без учёта вида монады? )

S>То есть вы заранее полагаете, что компилятор хуже вас разбирается в оптимизациях, и хотите делать всё вручную. Почему?

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

S>А это ещё зачем? Все особенности монады уже есть в самой монаде. Никакие дополнительные сущности под каждый тип не нужны. Вы же не пишете какие-то дополнительные сущности под каждый тип коллекции, чтобы разрешить алгоритмам из STL работу с ними.

Хы, да не важно внутри или снаружи (хотя в языках с навязанным ООП только первый вариант и проходит). Главное что оно зависит от конкретного вида.

S>Вы по-прежнему не понимаете основной идеи RX. Вот, скажем, когда вы пишете императивный код, который энергично процессит какие-то структуры, вы почему-то мало заботитесь о том, что нужно учитывать все эти ваши локальные переменные, их scope, частоту обращений, и прочее. Регистры за вас прекрасно выбирает компилятор. Вы пишете код типа x[i] = yy[i*aWidth+yoffset+j]*MulY + xx[i*aHeight+xoffset+j]*MulX и не паритесь о том, что на самом деле это элементарно записывается в обратной польской записи, и там даже можно сэкономить на лишних push и pop, подбирая порядок операций. Это привычно и удобно.
S>А вот когда речь идёт о коде, в котором, к примеру, поток управления диктуется снаружи, вы теряетесь. Попробуйте представить себе код, вычисляющий x[i], в котором нет возможности обратиться к "переменным" типа yy[...], а вместо них приходят внешние вызовы вроде set_yoffset(), set_MulY(), set_i().
S>При этом про порядок этих вызовов вы знаете не очень много — т.е. он сегодня один, а завтра другой. Конечно же, для каждого случая формулы и порядка прихода значений "легко" написать стейт-машину — вот только при "традиционной" реализации стейт-машины объём её кода будет несопоставим с приведённой формулой, и восстановить её логику крайне тяжело. Как вы поймёте, что делает эта стейт-машина, читая кусочки методов?

Плохой пример тут выбрали, потому как вычисления вида x[i] = yy[i*aWidth+yoffset+j]*MulY + xx[i*aHeight+xoffset+j]*MulX в любом случае не являются управляемыми снаружи и не требуют никаких конечных автоматов. По одной простой причине — для вычислений требуется наличие всех данных. Т.е. в коде "реакций" у нас не будет никаких действий, а только сохранение данных.

А вот если мы посмотрим на пример требующий реального конечного автомата (типа того же примера в этой темке, хотя там автомат такой простой, что линейный код всё равно проще вышел), то увидим что на RX он выглядит уже совсем не так красиво как просто формулка выше. Точнее он выглядит просто ужасно. )))

S>RX — это попытка записать подобные штуки в понятном виде. Т.е. вы пишете как бы активный код, который "сам" превращается в реактивный. А уж в каком виде вам удобнее писать предикаты и проекции — ваше дело. Если вам хочется иметь минимум синтаксического мусора, то query comprehensions — ваш выбор. Если вас раздражает SQL (а судя по вашим комментариям про NoSQL это именно так), то вам подойдёт лямбда-синтаксис, с явным выписыванием всех этих (previousEvent, currentEvent) => { return previousEvent.ClickPoint.InRect(new Rect(0, 0, 5, 5).Offset(currentEvent.ClickPoint.X, currentEvent.ClickPoint.Y);}.
S>С моей точки зрения это та же ручная state machine, вид сбоку.

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

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

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

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

Пока что меня интересует пример универсальной реализации liftM2 и как в неё попадает информация о типе монады. А то возможно, что мы говорим немного о разных вещах, и я слишком поспешно согласился, что такое трудно написать на языках типа C++.

K>Не понятно, о каких "базовых примитивах" идет речь если мы используем ФВП и лямбды?

Не важно как мы записываем sql операторы, через пробел или через точку, они всё равно остаются собой по смыслу.

K>Зависит от того, что понимать под словом "маргинальный". Если вопрос сводится к тому, есть ли польза от использования монад в окамле — то ответ: да, есть.

Ага, отлично... А теперь ключевой вопрос: насколько интенсивно используются монады в ocaml'е?

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

Ну вот например sin(exp(x)). В чём тут может быть польза от монад? )

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

Не буду отвечать с цитированием, а попробую подвести некий общий итог.

Насколько я понимаю, вы считаете что реализация IO/ST в Хаскеле приносит некие серьёзные плюсы по отношению к другим языкам. И то, что при этом код реализации вроде как той же задачи выглядит намного страшнее (что с монадами, что без), чем в других языка, это всё равно окупается теми самыми плюсами. Я правильно изложил?

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

Да, и по поводу примеров "весь код приложения — одна монада"... Можно взглянуть на примеры из того же wxHaskell — там оно в полный рост. )))

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

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

Не понятно, зачем вам может понадобиться "информация о типе монады" если не для специфических для данной монады оптимизаций. Если коротко, то эта информация в liftM2 никак не попадает — это называется "абстракция".

_>Не важно как мы записываем sql операторы, через пробел или через точку, они всё равно остаются собой по смыслу.

Все еще не понимаю, что вам не нравится. Что Filter называется Where не смотря на то, что смысл у него не совсем тот либо совсем не тот, что у sql-ного where?

_>А теперь ключевой вопрос: насколько интенсивно используются монады в ocaml'е?

Не знаю, я на окамле не пишу. Но вот компания, которая пишет — Jane Street — выпускала и монадические библиотеки вроде Async и синтаксические расширения для монад, а значит, по всей видимости, использует.

_>Ну вот например sin(exp(x)). В чём тут может быть польза от монад? )

Зависит от того, что у вас возвращает exp. Я же вроде понятно написал выше по ветке для комбинирования функций какого вида нужны монады.

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

_>Насколько я понимаю, вы считаете что реализация IO/ST в Хаскеле приносит некие серьёзные плюсы по отношению к другим языкам.

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

_>И то, что при этом код реализации вроде как той же задачи выглядит намного страшнее (что с монадами, что без), чем в других языка, это всё равно окупается теми самыми плюсами. Я правильно изложил?

Я не согласен, что это выглядит намного страшнее, чем в других языках (если не считать упомянутые мной "карательные" наименования, которые легко исправить). Монадический код часто, но не всегда, требует синтаксической обвязки для "стыковки" в отличие от функций вида a -> b в хаскеле, и потому код с мутабельными ссылками/массивами может выглядеть многословнее, чем хаскель-код с иммутабельными. Но в большинстве языков обычно наворочено столько синтаксического мусора без всякого смысла вообще, что на этом фоне и монадический хаскель-код выглядит вполне пристойно. Потому и вопрос — что это за язык такой, по сравнению с которым хаскельный код выглядит намного страшнее.

_>В таком случае, хотелось бы увидеть пример демонстрирующий именно эти самые плюсы,

Да любой код, про который вы решите, что он лучше кода на языке икс — лучше, в конечном счете, как раз потому, что в хаскеле есть IO/ST

_>т.к. я их не особо заметил при изучение Хаскеля, а вот страшность подобного кода заметил очень хорошо.

Ну, приведите этот самый "страшный код", а рядом код на том самом загадочном языке, где это все лучше выглядит.

_>Да, и по поводу примеров "весь код приложения — одна монада"... Можно взглянуть на примеры из того же wxHaskell — там оно в полный рост. )))

Я видел код на wxHaskell, не уверен, правда, что тот же самый, что и вы. Вопрос о том, что означают ваши слова "весь код приложения — одна монада" остается, ответте на него вашими же словами, а не отсылкой на некий неназванный код, который вы когда-то видели.

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

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

Совершенно верно. Вот я и хочу увидеть конкретный вид этой абстракции, чтобы оценить почему имеются проблемы (если имеются) с её реализацией на языках типа C++.

K>Все еще не понимаю, что вам не нравится. Что Filter называется Where не смотря на то, что смысл у него не совсем тот либо совсем не тот, что у sql-ного where?

Имя не принципиально. Даже если переименовать sql, он всё равно останется со своей огромной кучей проблем и ограничений. Для узкого круга задач (типа работы с таблицами и то желательно без join'ов) он ещё более менее подходит, но linq то позиционируется гораздо шире...

K>Не знаю, я на окамле не пишу. Но вот компания, которая пишет — Jane Street — выпускала и монадические библиотеки вроде Async и синтаксические расширения для монад, а значит, по всей видимости, использует.

Не, ну так специализированные библиотеки под особые задачи с концепциями типа монад есть и на C++. Но применяются то они только в этих самых особых случаях. В то время как в том же Хаскеле трудно найти приложение без монад.

K>Зависит от того, что у вас возвращает exp. Я же вроде понятно написал выше по ветке для комбинирования функций какого вида нужны монады.

Возращает double. Но не в этом суть. Так получается что уже не для всех случаев полезны монады? )))

От:	lazy/cjow/rhrr	lj://_lcr_
Дата:	25.12.13 10:02
Оценка:	63 (8) +1

	От:	Dair
	Дата:	25.12.13 10:12
	Оценка:	6 (1)

От:	lazy/cjow/rhrr	lj://_lcr_
Дата:	25.12.13 11:28
Оценка:

	От:	fin_81
	Дата:	25.12.13 11:48
	Оценка:

	От:	alex_public
	Дата:	27.12.13 01:26
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	27.12.13 04:51
Оценка:

	От:	Klapaucius
	Дата:	28.12.13 14:56
	Оценка:	1 (1)