[монады] абстракция или костыль?

http://www.linux.org.ru/view-message.jsp?msgid=4288933&page=1&lastmod=1259681...

>http://www.linux.org.ru/view-message.jsp?msgid=4288933&page=1&lastmod=1259681...

Ну молодец, да. Хорошо пошутил. Мы все оценили.

Теперь по сути. Хаскель перестал быть ленивым от того, что ты петросянишь?

>Ну молодец, да. Хорошо пошутил. Мы все оценили.
Если у меня нет проблем с памятью, то автор той шутки не я.

Теперь по сути. Хаскель перестал быть ленивым от того, что ты петросянишь?

Зачем нужна функция main в хаскеле?

Или нет, лучше так спрошу - является ли моя программа-helloworld на си ленивой только от того, что я ее вызываю только когда хочу, а не сразу как написал?

>Если у меня нет проблем с памятью, то автор той шутки не я.

Ты ее сюда скопипастил + ссылку в треде уже два раза кидал.

Зачем нужна функция main в хаскеле?

Это функция которая возвращает основное вычисление. Да, ленивая.

Или нет, лучше так спрошу - является ли моя программа-helloworld на си ленивой только от того, что я ее вызываю только когда хочу, а не сразу как написал?

Программа - нет. Ты - да =)

Вообще. Вся программа на хаскеле - это функция main, которая возвращает вычисление.

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

>Ладно, что делает программа на хаскеле, запускаясь?

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

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

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

Это демагогия.
Монада IO это сайд-эффекты и последовательные вычисления, и это, кстати, «грязная» монада.

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

Твое дело.

Это демагогия.

Это называется «модель». Все взрослые дяди так делают.

>Это называется «модель».
Это не модель, это какое-то двуличие.

>Это не модель, это какое-то двуличие.

Что значит двуличие?

Например свет иногда мы считаем, что это волна, иногда частицы.

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

Это все абстракции, модели.

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

Да отовсюду - от rsdn до LtU.

не канает. поискать по гуглу я и сам могу, но ни одного примера описания «опупенной крутости» я не вижу. я просил конкретную ссылку на конкретную статью, пост или книгу, декларирующие преимущество монад над каким-либо другим методом проектирования

вот только не будет их, потому как и быть не может. потому как с точки зрения программиста, который написал что-то большее, чем Hello World на Haskell, класс монад - всего лишь один из многих элементов проектирования; наравне с теми же аппликативными функторами. потому и пишут о них либо серьёзные статьи в functional pearls, либо очередные учебники, либо вот такие трололо-посты как у тебя по ссылке

Пол Грэм это не то чтобы так уж прямо авторитет. LOL аналогично

и что? факт в том, что голословные рассуждения про «опупенную крутость» чего-либо присущи прежде всего CL-community. целые книги пишут о том, какой крутой CL, и какие убогие все остальные языки. ты сам в этом треде привёл ссылку на неадекватных лиспоблоггеров; я могу привести ещё с десяток подобных примеров - от Луговского до RSDN-троллей

я что-то сказал про принципиальную невозможность реализации чего-то без макросов

а кто-то утверждает, что монады в Haskell (кроме IO) являются чем-то незаменимым? монада - всего лишь один класс типов, описывающий один паттерн взаимосвязи функций и данных в программе. абстракция вычислительного процесса. моноид в категории эндофункторов, с композицией эндофункторов в качестве умножения, и id в качастве единицы

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

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

Я просто упомянул, что вот она, сила макросов, вобщем-то, преимущества ее можно увидеть и пощупать. И попросил подобный пример с монадами.

т.е. тебе нужен пример практического применения монад в Haskell? пожалуйста:

http://book.realworldhaskell.org/read/programming-with-monads.html

Real-World библиотека с монадическим (и аппликативным) интерфейсом - Parsec. достаточно в качестве примера?

Книжки, в которых преимущества CL подробно описываются

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

Монада IO это сайд-эффекты и последовательные вычисления

монада IO - единственная «плохая» монада в Haskell, по более-менее очевидным причинам. отождествлять класс типов с одним крайне выделяющимся инстансом, мягко говоря, ошибочно

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

а с поставленной задачей справляется. да, не даёт такого ощущения избранности, как CL,- зато работает

мне, почему-то, всегда казалось, что это важней

TH не может по ряду причин функционал макросов CL изобразить в полной мере.
Но, конечно, if на нем написать через cond может и можно. Только вот нафиг не нужно.

О, а кто это отождествляет?
Я что-то не думаю, что лиспер-автор-статьи имел ввиду, например, что все монады содержат побочные эффекты и императивны. Если это то, что кто-то отсюда там увидел, и потому на него набросился, жаль, потому как этот кто-то не умеет читать и слишком много додумывает.

TH не может по ряду причин функционал макросов CL изобразить в полной мере.

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

Но, конечно, if на нем написать через cond может и можно. Только вот нафиг не нужно.

на CL можно написать всё что угодно, однако создатель Qi почему-то свернул проект, назвав одной из главных причин именно выбор CL в качестве платформы. и предложил продолжать работу на Python

О, а кто это отождествляет?

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

>т.е. тебе нужен пример практического применения монад в Haskell? пожалуйста:
Ну емое, я ж сказал, тот, который именно преимущество монад покажет.
А то, собственно, тема то топика в том - костыль это или реально крутая фича. И получается, если преимуществ нет - то, очевидно, костыль.

в сообществе CL принято описывать не инструменты проектирования, а преимущества.

А, собственно, что в этом такого? Если у чего-то нет каких-либо преимуществ над чем-то другим, нахрен его вообще использовать тогда?
Беда в том, что многие, особенно на территории недоразвитых стран, вроде стран СНГ, думают, что преимуществ как раз нет, поэтому лисперы иногда стараются их в этом разубедить(по тем банальным причинам, что преимуществ у CL куча, а ошибочное мнение о каком-либо близком предмете слышать неприятно)

Не знаю, насколько уж полезна. В хаскеле то необходимость контролируемости как раз из-за ленивости. В лиспе ленивости нет, и по мне, так «контролируемость» была бы только наставлением палок в колеса.

>а в CL нет классов типов, семейств типов и обобщённых алгебраических типов
Ну, дело в том что эти вещи применительно к языкам с динамической типизацией, и, тем более, с моделью типизации CL, рассматривать бессмысленно. А вот макросы более-менее языконезависимая фича. В том или ином виде есть и в сях, и вон в хаскеле. Другое дело, что где-то кроме лиспа, и, вообще, языков с концепцией code-as-data(хотя, конечно, из таких языков более-менее живы только лиспы(не надо про форт только, там другое)), они смотрятся убого, но это другое дело.

на CL можно написать всё что угодно, однако создатель Qi почему-то свернул проект, назвав одной из главных причин именно выбор CL в качестве платформы. и предложил продолжать работу на Python

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

>я могу привести ещё с десяток подобных примеров - от Луговского до RSDN-троллей
Луговский был, кстати, невероятно адекватен. А на RSDN так не то что лиспотроллей, так вообще, лисперов я уже сотню лет как не видел, там сейчас один хаскель.

Ну емое, я ж сказал, тот, который именно преимущество монад покажет.

преимущество над чем? слушай, ты вменяемый вообще?

И получается, если преимуществ нет - то, очевидно, костыль.

у процедур нет преимуществ. у классов нет преимуществ. у System-F нет преимуществ. и у динамического рантайма, очевидно, тоже нет преимуществ. по твоей логике мы живём в мире из сплошных костылей

Беда в том, что многие лисперы, особенно на территории недоразвитых стран, вроде стран СНГ, думают, что преимуществ как раз нет, поэтому функциональщики иногда стараются их в этом разубедить(по тем банальным причинам, что преимуществ у Haskell куча, а ошибочное мнение о каком-либо близком предмете слышать неприятно)

что-то поменялось? да ничего

Не знаю, насколько уж полезна

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

Ну, дело в том что эти вещи применительно к языкам с динамической типизацией, и, тем более, с моделью типизации CL, рассматривать бессмысленно

надо же, к концу треда стали появлятся здравые мысли

А вот макросы более-менее языконезависимая фича

и тут же закончились. жаль

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

Обычный бред функциональщиков... «Побочные эффекты без побочных эффектов»

Чистая правда.

а, ну вас. не хотите конструктивного диалога - не надо. если вдруг кому будет эта тема интересна, советую почитать вот это:

http://www.haskell.org/haskellwiki/Typeclassopedia

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

Ага, будешь смеяццо, но функции типа putStrLn сами по себе ничего не пишут.

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

Причём он (если я правильно понимаю, о ком речь) имеет для того некоторые основания.

Причём он (если я правильно понимаю, о ком речь) имеет для того некоторые основания.

я о thesz; основания, в принципе, есть у многих - у него просто самая радикальная позиция. даже на rsdn'е забанили

> «КАК» это инженерия. А наука всегда отвечает только на вопрос «ЧТО»

Никакая наука никогда не отвечает на вопрос «ЧТО». Ни физика, ни математика, ни какая другая. Этим вопросом интересуется разве что философия, но это не наука.

> Что касается IO, то его можно было сделать без монад.

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

>>Никакая энергичность не заточена в монадах.

Да ну! А то монада I/O просто так существует.

Во-1, есть монада IO. Монады I/O нет.

Во-2, IO - всего лишь один тип, предоставляющий, среди прочего, монадический интерфейс.

Возьми для примера монаду State. У неё есть две версии, в стандартной библиотеке GHC. Одна - энергичная, другая - ленивая. Как-то странно после этого говорить, что в монадах сосредоточена энергичность.

По большей части, энергичность сосредоточена в паттерн-матчинге. Но не вся.

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

Это неверно. Кто мешает все неленивые конструкции вынести за пределы языка (и его стандартной библиотеки) и сделать к ним вполне себе ленивый интерфейс.

Другой вопрос, что в целях оптимизации (Хаскель, всё-таки, язык практический) так не делают.

>>Что такое main? Она просто так, значит? Или, может, она в хаскель не входит?

Это до мозга костей ленивая функция.

Это вообще, если на то пошло, не функция. Это значение типа IO (). Вычисляемое ленивым образом.

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

И вменяемой статической типизации там не может быть в принципе. Если только мы не перепишем вообще все функции стандартной библиотеки, запретим все предопределённые специальные формы и переделаем ридер, чтобы случайно что-то не то не пролезло.

Что не делает CL таким уж плохим языком.

> В хаскеле то необходимость контролируемости как раз из-за ленивости. В лиспе ленивости нет, и по мне, так «контролируемость» была бы только наставлением палок в колеса.

Изобрази STM без контролируемых сайд-эффектов. И посмотрим, сколько времени оно продержится.

Что не делает CL таким уж плохим языком.

не делает. более того, CL - очень даже приятный язык, как по мне

>ну тогда почитай вот это днём. там в конце много ссылок

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

>Луговский был, кстати, невероятно адекватен.

Эм. Он конечно говорил правильные вещи в основном, но говорить, что он «адекватен» или тем хуже «невероятно адекватен» это уже через чур.

Черт, я все понял. Человек начитался Луговского и вот теперь пожалуйста.

Это вообще, если на то пошло, не функция. Это значение типа IO (). Вычисляемое ленивым образом.

Ну вообще да =)

>Это, вроде бы, просто - монада это конвеер. Монады нужны, чтобы организовывать императивную последовательность действий в ФЯ.

это ведь можно делать через аргументы функций и композиции.

>Есть. Выгода в простоте, понятности, лаконичности, расширямости, ну и далее по тексту (выгода обычно приводится при сравнении с чем-нибудь, а пока не с чем сравнивать, ты ничего не привёл.)

с любыми функциями и применением нечистых функций.

Если ты знаешь, что такое эксепшны и зачем они нужны - то посмотри на монаду Maybe.

И что потом с этим исключением делать? Какая стратегия нахождения обработчика и возврату к нормальному выполнению программы? Что-то я не улавливаю отличия от [val or false] в динамических языках.

>Реальная польза монад в том, что они позволяют спрятать «под коврик» ненужные детали реализации и сократить объем кода.

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

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

никак

>Хм, и хаскел тут что-то сократит? Как?

без понятия, но только куда там в монаде пропал треугольник (1,1,1)?

это ведь можно делать через аргументы функций и композиции.

да. монада - это и есть пара функций, инкапсулирующих эту машинерию

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

Maybe - это не реализация condition'ов, это очень простой механизм протягивания исключительной ситуации сквозь вычисления. есть и более сложные, но и их реализация занимает чуть больше места

> как компилятор проверяет выполнение монадических законов?

Никак. И это хорошо: зачастую монадические законы выполняются «с точностью до». Из моей практики: монада, в которой значение в некоторый момент сериализуется, потом зачитывается обратно. В зависимости от расстановки скобок, результат сериализации может быть разным - но и функция десериализации тоже получится разная, а результат десериализации окажется тем же.

> это ведь можно делать через аргументы функций и композиции.

Конечно, можно, никто и не против.