LINUX.ORG.RU

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


0

0

Здравствуйте.

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

Ответ на: комментарий от login738246

>интуиция мне подсказывает, что это что-то вроде смеси замыканий и мапов, правда тогда этот алгоритм будет говном, которое будет тестировать все возможные комбинации, со сложностью N^3. Даже интуитивно видно, что можно область поиска можно сократить.

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

yyk ★★★★★
()
Ответ на: комментарий от Love5an

> Вот тут хорошо написано, по-моему: http://lisp-univ-etc.blogspot.com/2009/11/blog-post.html

"... В итоге оказывается, что ленивыми в Haskell являются только чистые функции, а все вычисления (в понимании программистском), которых, на самом деле, большая часть — все равно остаются энергичными. ..."

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

Короче. Читать не стоит. Иначе сложится ложное представление о монадах и хаскеле. Особенно вредно читать лисперам ;) Хотя если хотите повысисть свою квалификацию форумного тролля и незнайки, то читайте!

dave ★★★★★
()
Ответ на: комментарий от dave

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

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

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

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

Ага, а в «грязных» языках побочный эффект привносится только когда мы запускаем программу.

Иначе сложится ложное представление о монадах и хаскеле.

И какое же ложное? Наверное такое, что монады и, вообще, хаскель не являются волшебными таблетками, да и многие вещи на нем делать не так уж и удобно, да?

Love5an
()
Ответ на: комментарий от Love5an

> Т.е. я правильно понял, Вы сами нифига еще толком не знаете, но, тем не менее, утверждаете, что автор все говорит неправильно? Как эти два факта согласуются?

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

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

Похоже статья таки сделала свое дело... Хотя монады устроены очень просто, они могут быть очень сложны для понимания. Это нужно принимать как данность. Например, как с самой математикой. В этом даже есть что-то положительное.

Ага, а в «грязных» языках побочный эффект привносится только когда мы запускаем

программу.

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

И какое же ложное? Наверное такое, что монады и, вообще, хаскель не являются волшебными таблетками, да и многие вещи на нем делать не так уж и удобно, да?

Глупая статья, порождающая еще больше глупости.

dave ★★★★★
()
Ответ на: комментарий от Love5an

Вот тут хорошо написано, по-моему:

чушь там, вообще говоря, написана; и в комментариях (излишне вежливо, как по мне) ему на это намекают

jtootf ★★★★★
()
Ответ на: комментарий от dave

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

Похоже статья таки сделала свое дело... Хотя монады устроены очень просто, они могут быть очень сложны для понимания. Это нужно принимать как данность. Например, как с самой математикой. В этом даже есть что-то положительное.

http://lurkmore.ru/Небыдло
?
Если что-то пишет в файл, оно не может не производить побочных эффектов по определению.

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

Это прекрасно, но как-то к теме не относится совершенно.
И вот это:

При этом все остается чистым и гладким

Ни в коей мере не объясняет. И не опровергает совершенно ничего из написанного в статье.

Love5an
()
Ответ на: комментарий от Love5an

Наверное такое, что монады и, вообще, хаскель не являются волшебными таблетками

а что, кто-то тебе сказал, что являются? успокойся, он пошутил

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

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

На более высоком уровне абстракции это может выглядеть так. Хаскелевская главная функция main порождает некоторую другую функцию, которая затем и запускается. В лиспе же мы запускаем уже сформированную готовую функцию. Благодаря ленивости хаскеля, разница в эффективности незначительна, но при этом удается добиться чистоты. Так понятно?

P.S. (Хаскелистам) Если неправ, плз поправьте.

dave ★★★★★
()
Ответ на: комментарий от jtootf

успокойся, он пошутил

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

Love5an
()
Ответ на: комментарий от Love5an

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

«вы просто не читали SICP», «вы просто пришли из мейнстрима и не видели никаких языков», «важно знать только CL», а по существу - ни одного возражение, одни ошибки

если уж и приводить пост на эту тему, я бы предложил что-то вот такое:

http://marijn.haverbeke.nl/monad.html

тоже эмоционально, но по крайней мере не на уровне детского сада

jtootf ★★★★★
()
Ответ на: комментарий от dave

Это к чему относится и каким местом? И как, еще раз, определяет отсутствие побочных эффектов?

btw:

(defun main ()
  (funcall
    (compile
      nil '(lambda ()
             (format *standard-output*
                     "Hello, world!")))))

Love5an
()
Ответ на: комментарий от Love5an

получается, что сообщество хаскелистов только наглым враньем и троллингом шутками и занимается

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

при всём уважении

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

> А конкретика, в итоге, будет, или будем и дальше с умным видом рассуждать о богоизбранности хаскеля, и, особенно, программистов на нем?

Бог с тобой! Я считаю, что хаскель важен в программировании так же как функциональный анализ в математике. Большинству программистов он действительно нафиг не нужен, как большинству инженеров совершенно ни к чему функан. Но для постижения дзена.. более глубокого понимания основных идей в программировании хаскель необходим. Точно также без функционального анализа и алгебры в современной математике никуда. Все зависит от того уровня, который ты хотел бы достичь.

Если говорите о практике, то мне сейчас очень нравится F#. Там даже монады есть :) Теперь я делю языки на два типа: с монадами и без. Возможно, что к лиспу их тоже можно красиво прикрутить с помощью макросов. Точнее они там всегда были. Тот же список есть пример монады. Их можно замечать или в упор не видеть. Все таки абстракция ;)

dave ★★★★★
()
Ответ на: комментарий от Love5an

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

dave ★★★★★
()
Ответ на: комментарий от jtootf

«вы просто не читали SICP»

Это шутка, там смайлик даже стоит. В дальнейшем контексте это употребляется ввиду того, что оппонент действительно слишком узко понимает словосочетание «стратегия вычисления», а в SICP, емнип, это понятие в более широком смысле, чем lazy vs eager, и правда раскрывается.

«вы просто пришли из мейнстрима и не видели никаких языков»

вот полностью, если я то нашел, что имеется ввиду:

> Мейнстримные языки обычно поддерживают
> два вида "вычислений"

Мне кажется, что Haskell-программистам не хватает кругозора :) Придя, обычно, в haskell именно из Мейстрима (включая C) они часто кажется не подозревают, что есть ещё много других языков.
собственно, то, что цитируют:
Что такое "единая ткань вычислений"? Мейнстримные языки обычно поддерживают два вида "вычислений": математические выражения и инструкции (statements), причем вторые обычно нужны для того, чтобы задать порядок побочных эффектов.
И что тут, собственно сказать? Он бы еще написал, что мейнстримные языки поддерживают только два вида циклов. И ладно бы еще просто так написал, но тут, и вообще, в контексте статьи, действительно, идет сравнение с CL, и полезность монад в контексте имеющихся в CL инструментов. Человек и правда, судя по всему, никогда в глаза не видел CL, однако же.

«важно знать только CL»

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

Love5an
()
Ответ на: комментарий от dave

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

Это просто решение задачи в другой парадигме. Примерно как с функциями из математики. Многие функции можно представить как ряд Фурье. Вроде бы та же функция, но разложена на ряд примитивных. Хаскель позволяет разложить побочный эффект на ряд «примитивных» чистых функций.

dave ★★★★★
()
Ответ на: комментарий от dave
LISPеры из /s/ пользуются технологией «ленивого программирования», аналогичной en.w:lazy evaluation.

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

Благодаря этому LISP разработчики экономят много времени, которое могут с пользой использоваться для эффективного троллинга. 

Похоже, время заменять «лисперы» на «хаскелисты».

Love5an
()
Ответ на: комментарий от Love5an

Человек и правда, судя по всему, никогда в глаза не видел CL, однако же.

а автор поста - Haskell. хотя бы о graph rewrite systems почитать можно было, не?

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

фанатичным лисперам - определённо. тут даже и говорить не о чём

не стоят «религиозного трепета», с которым их обычно упоминают

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

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>хотя бы о graph rewrite systems почитать можно было, не?
Это, емнип, только Clean через них устроен, а не хаскель.

фанатичным лисперам - определённо. тут даже и говорить не о чём

И какие же объективные преимущества? Т.е. я имею ввиду действительно что-то вменяемое, что с монадами решается на раз, а без них нет, а не «познать дзен».

где этот самый «трепет», где утверждения о «серебрянной пуле»? ткните меня носом, в упор не вижу

как минимум - жж thesz и nponeccop из них только и состоят.

Love5an
()
Ответ на: комментарий от Love5an

Это, емнип, только Clean через них устроен, а не хаскель.

спорим?

И какие же объективные преимущества?

а какие объективные преимущества макров лиспа? и вообще, преимущества чего над чем? монады - просто инструмент проектирования, такой же, как и все остальные; с тем же успехом можно с пеной у рта требовать доказательства «преимущества» классов, subtyping'а, делегирования, специальных форм, унификации или макросистемы

как минимум - жж thesz и nponeccop из них только и состоят

nponeccop-то каким местом? у него половина постов в бложике - ругань если не GHC, то Haskell; другое дело, что в отличие от статьи по ссылке, ругань у него объективная

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

> Я к тому, что «порождение функций», и вообще, ленивость, чистоте перпендикулярны.

Заблуждение. Чистота дает так называемую ссылочную прозрачность (referencial transparency). Это когда нам все равно, где когда и как вычислять значение. Тогда ленивость становится разумным выбором для стратегии вычисления. Без чистоты нет ссылочной прозрачности, а потому ленивость становится бомбой замедленного действия, поскольку мы не знаем как сработают побочные эффекты, измени мы порядок вычислений. Все взаимосвязано. И продумано уже до нас :)

Если говорить о main, то ленивость позволяет начать выполнение программы (точнее функции, порожденной программой) немедленно. Сборка мусора позволяет делать это без space leaks. Будь хаскель энергичным, все эта схема была бы уродлива и неэффективна. Опять взаимосвязано.

Ладно, хватит мне флеймить. А лисперам могу пожелать поближе познакомится с предметом. Он того стоит.

dave ★★★★★
()
Ответ на: комментарий от login738246

>А почему же никто не может сказать сам

Ага, в пару абзацев волжить лет этак 20 научной мысли... Вообще, я себе никогда не ставил вопрос «ЗАЧЕМ» Сказать к слову, я долгое время в виду карйне дерьмового математического образования в школе и вузе при изучении математики стаивл этот вопрос. Нужно ставить вопрос «КАК».

Монады используются для моделирования вычислений. Тебе от этого легче стало? Лично для меня монады - средство *неявного* управления потоком *вычислений*. Но ведь для меня же. Кто-то может быть монады рассматривает как некий контейнер, внутри которого, как в аналоге проргаммного модуля, можно прятать детали реализации. Может кто-то рассматривает моналы, как способ формаирования цепочки комбинаторов со всемы вытекающими.

Так что читай классиков. Благо в цифровую эпоху они доступны.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> Вообще, я себе никогда не ставил вопрос «ЗАЧЕМ» Сказать к слову, я долгое время в виду карйне дерьмового математического образования в школе и вузе при изучении математики стаивл этот вопрос.

Так ты определись - девочка или мальчик.

И да, математика без «зачем» теряет свой смысл.

LamerOk ★★★★★
()

monads are burritos

anonymous
()
Ответ на: комментарий от dave

>Заблуждение. Чистота дает так называемую ссылочную прозрачность (referencial transparency). Это когда нам все равно, где когда и как вычислять значение. Тогда ленивость становится разумным выбором для стратегии вычисления. Без чистоты нет ссылочной прозрачности, а потому ленивость становится бомбой замедленного действия, поскольку мы не знаем как сработают побочные эффекты, измени мы порядок вычислений. Все взаимосвязано. И продумано уже до нас :)

Это называется путать причину со следствием. Или, как-то так.
Ленивость и чистота никак не связаны, еще раз. Вполне может быть, что побочные эффекты в ленивых функциях не всегда могут вычислиться правильно, но не более.(кстати, на предмет монады IO - забавный момент, в хаскеле монады ввели фактически только для того, чтобы эту вот несостыковку I/O(да и не только I/O, а «вычислений» вообще) и ленивости убрать)

И вот.

Чистота дает так называемую ссылочную прозрачность (referencial transparency)

Что, автоматически? Да как бы не так.

Будь хаскель энергичным, все эта схема была бы уродлива и неэффективна

Опять путание причины со следствием.

А лисперам могу пожелать поближе познакомится с предметом. Он того стоит.

Странно, уже сколько о нем рассуждаем, а, оказывается, и понятия не имеем. Наверное потому, что нас далеко не познавание дзена интересует в программировании.
Btw, Yale Haskell был написал на CL.

Love5an
()
Ответ на: комментарий от jtootf

а какие объективные преимущества макров лиспа? и вообще, преимущества чего над чем? монады - просто инструмент проектирования, такой же, как и все остальные; с тем же успехом можно с пеной у рта требовать доказательства «преимущества» классов, subtyping'а, делегирования, специальных форм, унификации или макросистемы

В этом все и дело, и это, собственно, вопрос топикстартера. Та же макросистема лиспа, к примеру, дает вполне видимые и объективные преимущества, и эти преимущества можно чуть ли не буквально пощупать.

Например, я вот пишу библиотеку-биндинг. Большей частью код у меня там состоит из макросов, по типу такого:

(define-struct (pass-desc :prefix pass-)
        ((name          lpstr)
         (annotations   :uint)
         (signature     shader-signature)         
         (stencil-ref   :uint)
         (sample-mask   :uint)
         (blend-factor  float4)))
Из подобной формы, на основе информации о сишных типах(lpstr, :uint и т.п), во время компиляции генерируется описание сишной структуры, высчитываются оффсеты, выравнивание, генерируются конструкторы структуры в лиспе, функции доступа(например pass-name и (setf pass-name)) и функции для перевода структуры из лиспа в сишную память и обратно, и метаинформация, необходимая другим макросам для генерации кода, занимающегося этим же.

Как это выглядело бы без макросов - я себе представить не могу. Вернее, могу - например, как System.Runtime.InteropServices.Marshal в .NET, т.е. тормозная и ограниченная вещь, но лучше и не представлять.

И по типу такого можно, в принципе, обосновать преимущества всех приведенных фич.

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

Love5an
()
Ответ на: комментарий от jtootf

>nponeccop-то каким местом? у него половина постов в бложике - ругань если не GHC, то Haskell; другое дело, что в отличие от статьи по ссылке, ругань у него объективная

Да ладно, там в стиле «конечно, хаскель - говно, но это лучший яп на сегодняшний день»

Love5an
()
Ответ на: комментарий от Love5an

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

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

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

Ленивость и чистота никак не связаны, еще раз.

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

Странно, уже сколько о нем рассуждаем, а, оказывается, и понятия не имеем. Наверное потому, что нас далеко не познавание дзена интересует в программировании.

Может тебе таки стоит почитать что-то нормальное по монадам в хаскеле?

Btw, Yale Haskell был написал на CL.

Фанатизм? Я так прнимаю в твоем больном воображении это делает хаскель хуже?

ЗЫ. Статья по ссылке плохая. Автор не понимает/плохо понимает монады. По ссылке и так достаточно по этому поводу сказали.

Waterlaz ★★★★★
()
Ответ на: комментарий от Love5an

Та же макросистема лиспа, к примеру, дает вполне видимые и объективные преимущества, и эти преимущества можно чуть ли не буквально пощупать.

а вот нифига. во всяком случае, на ЛОРе ещё не было примеров задач, которые нельзя было бы решить без применения макр как средства проектирования...

большей частью код у меня там состоит из макросов, по типу такого:

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

к слову, в Haskell есть система метапрограммирования - TH, и реализована она с помощью монады QExpr; пример эффективной кодогенерации можно посмотрить здесь:

http://www.cse.unsw.edu.au/~chak/papers/KCCSB07.html

А вот с монадами получается какая-то фигня

потому что тебе они не нужны. для программиста на Haskell, или, скажем, OCaml, таким же образом не нужны макры CL. неужели этот факт так сложно осилить?

Единственное, что можно про них слышать, так это то, что они опупенно круты

единственное, что можно слышать про макры CL, так это то, что они опупенно круты; вот только примеры «немерянной крутости» очень быстро упираются в борьбу с этой самой крутостью - антиквотация, захват имён, unwind-protect (который, внезапно, есть практически в любом современном ЯП), и прочая ахинея. иногда проскальзывает пара компайл-тайм генераторов, вроде твоего

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

что с помощью них можно «познать дзен»

короче, пока здесь не будет примеров такой позиции хаскеллистов про монады, обсуждать этот вопрос бессмысленно

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

Да ладно, там в стиле «конечно, хаскель - говно, но это лучший яп на сегодняшний день»

ну значит ты увидел только то, что захотел увидеть; я тут уже ничем помочь не могу

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

Наверное потому, что нас далеко не познавание дзена интересует в программировании.

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

спрашивается - а нафига?..

jtootf ★★★★★
()
Ответ на: комментарий от Love5an

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

Штудировать «Algorithms: A function programming approach» до просветления. Начальные главы.

(кстати, на предмет монады IO - забавный момент, в хаскеле монады ввели фактически только для того, чтобы эту вот несостыковку I/O(да и не только I/O, а «вычислений» вообще) и ленивости убрать)

А вот монады с ленивостью _не_ связаны. Пример: монады во вполне энергичном F# (aka computation expressions).

Что касается IO, то его можно было сделать без монад. Те же функции f(g(h(x))) тоже связывают код. И нет никаких монад.

Кстати, побочные эффекты действительно можно вызывать из ленивого кода. В том же F# есть lazy, но это - опасная вещь. И это выбивается из парадигмы как исключение. Не для того оно.

Слушай, а это не ты ли сам написал ту опупенную и процитированную тобою статью на lisp-univ-etc? Такое ощущение, что автор того опуса разделяет схожие ошибочные представления о монадах, ленивости, чистоте, энергичных вычислениях и тому подобном. Все-таки до чего вредная и глупая статья! И заразная к тому же! :)

dave ★★★★★
()
Ответ на: комментарий от Waterlaz

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

Автор не понимает/плохо понимает монады.

Я услышу, наконец, конкретику?

Love5an
()
Ответ на: комментарий от jtootf

> http://nponeccop.livejournal.com/156763.html

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от dave

Кстати о ленивости и монадах. Есть такая монада Backwards state. Благодаря ленивости состояние распространяется в обратном порядке относительно следования. Забавный факт, который сам по себе частично опровергает ту галиматью из «статьи».

dave ★★★★★
()
Ответ на: комментарий от jtootf

>а вот нифига. во всяком случае, на ЛОРе ещё не было примеров задач, которые нельзя было бы решить без применения макр как средства проектирования...
Я что-то не понял, я что-то сказал про принципиальную невозможность реализации чего-то без макросов?
Брейнфак то вот тьюринг-полон, кстати, говорят.

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

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

к слову, в Haskell есть система метапрограммирования - TH

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

вот только примеры «немерянной крутости» очень быстро упираются в борьбу с этой самой крутостью - антиквотация, захват имён, unwind-protect

Не понял, опять.
Антиквотация это проблема? А мужики то и не знают!
Проблема захвата имен преувеличена красноглазыми схемерами, очень сильно. WITH-GENSYMS - и проблемы нет.
Unwind-protect к макросам вообще каким боком?

а откуда ты «всё время слышишь» что монады «опупенно круты»?

Да отовсюду - от rsdn до LtU.
http://www.google.ru/search?q=advantages+of+monads

т чтения того же Пола Грэма или LOL от неблыдловости лисперов у меня уши вянут - при том, что сколько-нибудь впечатляющих практических примеров нет ни там, ни там

Пол Грэм это не то чтобы так уж прямо авторитет. LOL аналогично. Хотя, последняя книжка ничего так.
Книжки, в которых преимущества CL подробно описываются - есть: PAIP, AMOP и куча других, по мелочи. Да, ёмое, даже в PCL они неплохо так описываются.

Love5an
()
Ответ на: комментарий от Love5an

>Я услышу, наконец, конкретику?

Конкретика есть в комментариях, но если так хочешь:

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

Это не правда.

Принято говорить, что, в целом, язык ленивый, а вся неленивость/энергичность (eagerness) находится (так и хочется сказать, заточЕна) внутри монад.

Монады не имеют прямого отношения к ленивости. Никакая энергичность не заточена в монадах.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

>Это не правда.
И каким местом? Что-то в итоге должно все-равно быть энергичным, чтобы активировать процесс вычисления.

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

Да ну! А то монада I/O просто так существует.
Монады в хаскеле ввели только для того, чтоб ленивость одолеть. То, что они, м.б. и для других вещей оказались полезны это другой вопрос.

http://www.google.ru/#hl=ru&safe=off&newwindow=1&q=%22monads+were+introduced%...

Love5an
()
Ответ на: комментарий от Love5an

Еще раз. Монада конструирует вычисление. Лениво конструирует вычисление. Которое потом передается в main.

Waterlaz ★★★★★
()
Ответ на: комментарий от Love5an

Вот например код:

makeComp isFinite = do
    putStrLn "Ok, we've entered our monad...\n"
    if isFinite 
        then do putStrLn "This is a finite monadic code\n"
         else do putStrLn "Here we are going to build an infinite monad"
                 mapM_ (\x -> print "lalala") [1..]
				 
main = do
	makeComp True

Если бы монада конструировалась не лениво, то он бы повис.

Waterlaz ★★★★★
()
Ответ на: комментарий от Love5an

>И каким местом? Что-то в итоге должно все-равно быть энергичным, чтобы активировать процесс вычисления.

тем, что если никого энергичного не находится, то результат никому и не нужен

Pi ★★★★★
()
Ответ на: комментарий от Pi

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

А то иначе получается
http://www.linux.org.ru/view-message.jsp?msgid=4288933&page=1&lastmod=1259679...

Love5an
()
Ответ на: комментарий от Love5an

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

При чем тут computational effects к ленивости? Это совершенно разные вещи.

Программа с точки зрения хаскеля - это _ленивая_ функция, возвращающая вычисление.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

>При чем тут computational effects к ленивости? Это совершенно разные вещи.
Действительно разные. В случае с ленивостью вместо computational effects Пустота.

Программа с точки зрения хаскеля - это _ленивая_ функция, возвращающая вычисление.

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

Love5an
()
Ответ на: комментарий от Love5an

>Действительно разные. В случае с ленивостью вместо computational effects Пустота.

Функция main не выполняет никаких computational effects.

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

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

Waterlaz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.