VD>>Твои "сервисы" не более чем развитие идеи "супер навороченной глобальной переменной"
ANS>Это называется "переменная с динамической областью видимости".
точно, можно и так это сделать. но как я понимаю, ни в одном из рассматриваемых нами языков их нет
(C) lomeo > И второе имхо выглядит весьма достойно и понятно. А это ничто иное > монада List.
Выглядит ни грамма не понятно, и это все та же монада List .
Здравствуйте, palm mute, Вы писали:
PM>Mirrorer wrote:
>> Все три определения равносильны. Просто одни подсахарены больше другие >> меньше. PM>Вот четвертое: PM>
PM>(C) lomeo >> И второе имхо выглядит весьма достойно и понятно. А это ничто иное >> монада List. PM>Выглядит ни грамма не понятно, и это все та же монада List .
это как раз самое понятное, и тип у него на самом деле более общий:
cartesian3 :: Monad m => m a -> m b -> m c -> m (a,b,c)
(впрочем, у остальных вариантов тип такой же)
в данном случае монаду надо представлять как контейнер, а эту операцию — как возврат контейнера, получающего 3 контейнера, содержащие соответственно a, b и с, и возвращаюшего контейнер, содержащий тройку (a,b,c)
если это контейнер — IO, то процелдура просто агрегирует результаты трёх IO операций. если List — то все возможные тройки. если Maybe — то Just (a,b,c) если все контейнеры содержали Just, и Nothing иначе
Здравствуйте, VladD2, Вы писали:
VD>Ответы про монады, как сами монады — аморфны и выскальзают из рук. Никогда не получишь прямого и однозначного ответа. :)
Увы, почему то монады сложны для первоначального понимания (тяжело врубиться, грокнуть). Хотя по сути они просты.
L>> Т.е. говорить об использовании монады без указания конкретной монады, это почти как говорить об использовании паттерна без указания конкретного.
VD>Не совсем. Говорить о паттернах как раз можно. А вот монады снова слишком склизки для этого.
Ну, говорить то можно о чём угодно.
L>> "Почти" — потому что польза от этого всё таки есть. В силу того, что все они подчиняются определенным правилам, т.е. понятие достаточно формализовано.
VD>ОК. Я не хаскель-хакер и многое в нем не понимаю. Опиши эти правила как ты их ивдишь. За одно объясни какой в них смысл в языках где есть классы, объекты, варианты, их методы позволяющие менять их состояние...
Правила — это три закона монад + алгебра монадических функций. Для второго можно хотя бы привести знаменитый и очень полезный пример — m >>= f === join (fmap f m). Правила определяют семантику монад, т.е. у нас есть её явная формализация, а это вещь далеко не бесполезная.
Вопрос про смысл монад в ОО несколько размыт. Я не говорил об их явном использовании. Я говорил о взгляде на некоторое решение, как на использующее монаду. Прочитав первый раз книгу о паттернах проектирования, я подумал — блин, да я же всегда так делал. Однако, формализация (ну, более-менее) и абстракция понятия конкретного паттерна помогли мне в дальнейшей работе, т.к. во-первых, я мог определять условия применения явно, а не интуитивно, как раньше, во-вторых, мог использовать паттерн осознанно, а не тратя время на его очередное изобретение. Ну, все прелести формализации в общем.
L>>Для того, чтобы на некоторое решение можно было бы взглянуть как на монадическое, достаточно, чтобы это решение соотвествовало нескольким правилам.
VD>В эти правла не входит случаяно накомпление/изменение состояния?
В данном случае — это три закона. Так что не входит.
L>>Если не объявлять — мы все равно можем заметить этот интерфейс, если он есть. И сделать для себя определенные выводы.
VD>У меня уже есть интерфейсы и типы. Зачем мне малопонятная сущьность с горой булшита вместо простых и понятных вещей?
Это решать тебе. Видимо, незачем, если судить по тому, что ты считаешь монады сложной, непонятной горой булшита :-)
L>>Для тебя монада — это исключительно IO/State, которые, действительно, эмулируют императив. Эти монады в ИЯ не нужны.
VD>Нет. Для меня монады — это совсем другое. Я вижу монады как подпорку под несостоятельной идеей чистоты. Они просто не нужны в "грязном", но реальном мире — мире где есть состояние и последовательность действий. В мире где прежде чем выпить чай нужно вскипятить воду и заварить заварку, а не где чай кипятится и заваривается когда я опракидываю пустую чашку себе в рот.
Здорово, очень хорошая аналогия :-) Только она подходит к ленивым вычислениям вообще.
Что касается "подпорки под несостоятельной идеей чистоты" — так это то же самое, что сказал я — для тебя монада это IO/State. Реализация императива на чистом языке. Ты говоришь обо всех монадах, а подразумеваешь конкретную.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>это вы рассужаете о своём паттерне. в моём примере использования монад речь шла о другом. есть универсальная процедура сериализации. куда сериализировать — она узнаёт из контекста вызова, т.е. из тех самых параметров. монады позволяют передавать эти паораметры неявно на всю глубину вызовов
Ну а контекст позволяет неявно на всю глубину передавать сервисы. Понимаешь, все равно надо что то сделать явно — передать контекст или использовать монаду. Главное, насколько сложно это все будет поддерживать потом.
BZ>ну а назвать serialization target сервисом и потом говорить, что это часть арзитектуры системы, за которую никак не меньше чем архитектор отвечает — это как раз попытка натянуть какой-нибудь из знакомых паттернов туда, где он похож на нужное только отдалённо
Здравствуйте, VladD2, Вы писали:
VD>Ты просто пришел с тем что тебя волнует.
Про ужасную сложность передачи логгера внутрь кода без монад не я рассказывать начал, так что притензии не ко мне. У меня с логгером никогда никаких проблем не было.
Здравствуйте, Mirrorer, Вы писали:
M>ИМХО. Монады — это паттерн ФП. Я думаю что не единственный. Просто так сложилось что вокруг него больше всего непоняток возникает.. Почему — :xz:
Вот именно этот вопрос — переход от непоняткам к поняткам :-) мне кажется, надо решать исходя из конкретных задач (в этом смысле просмотр parsec'а хорошая идея).
Очень хорошо это сделано у Вадлера в The Essence of Functional Programming.
M>Тут +10 я тоже не очень понимаю почему именно этот интерфейс раскручивается..
В статье рассматривается задача построение интерпретатора, на который навешиваются различные свойства. Показывается, что применение монады делает подобную модификацию удивительно лёгкой. И всё это — следствие выделение интерфейса IMonad ;-)
BulatZiganshin wrote:
> > это как раз самое понятное, и тип у него на самом деле более общий: > > cartesian3 :: Monad m => m a -> m b -> m c -> m (a,b,c) > > (впрочем, у остальных вариантов тип такой же) > > в данном случае монаду надо представлять как контейнер, а эту операцию — > как возврат контейнера, получающего 3 контейнера, содержащие > соответственно a, b и с, и возвращаюшего контейнер, содержащий тройку > (a,b,c) > > если это контейнер — IO, то процелдура просто агрегирует результаты трёх > IO операций. если List — то все возможные тройки. если Maybe — то Just > (a,b,c) если все контейнеры содержали Just, и Nothing иначе
Я-то как раз это понимаю .
В этом форуме часто Хаскель всплывает, его то превозносят, то обзывают
нехорошим словом "булшит", но знает мало кто.
А мое предыдущее сообщение — просто хулиганская выходка.
Здравствуйте, palm mute, Вы писали:
PM>В этом форуме часто Хаскель всплывает, его то превозносят, то обзывают PM>нехорошим словом "булшит", но знает мало кто.
Ну, если быть точным, то Хаскель булшитом не обзывают.
Речь о монадах :-)
BZ>>это вы рассужаете о своём паттерне. в моём примере использования монад речь шла о другом. есть универсальная процедура сериализации. куда сериализировать — она узнаёт из контекста вызова, т.е. из тех самых параметров. монады позволяют передавать эти паораметры неявно на всю глубину вызовов
AVK>Ну а контекст позволяет неявно на всю глубину передавать сервисы. Понимаешь, все равно надо что то сделать явно — передать контекст или использовать монаду. Главное, насколько сложно это все будет поддерживать потом.
Здравствуйте, VladD2, Вы писали:
VD>Это самовнушение. Физически проблем вызова "чистым кодом" "не чистого" нет. Ее придумали пуристы. И доказано это на практике.
Физически проблемы взятия адреса переменной в памяти и доступа к ней по этому адресу тоже нет. И кто тут ругает C++ за такую возможность? А после запрета доступа по адресу наворачиваются всякие value- и ref-типы, boxing и unboxing. Казалось бы, объект — это просто кусок памяти, неважно какой (стек, куча).
Позволь всё-таки существовать функциональным языкам, а не только смешанным.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>там вообще-то и описывается эта "сложность поддержки" в случае монад
AVK>Знаешь, такое ощущение, что я разговариваю с глухим. Где я писал что монады сложно поддерживать?
"Понимаешь, все равно надо что то сделать явно — передать контекст или использовать монаду. Главное, насколько сложно это все будет поддерживать потом."
(а у меня — что с маразматиком ничего личного, просто сначала вы говорите что это закладывается в архзитектуру системы, а потом — что архитектор не при чём, сначала что передавать ничего не нужно, потом — что этот логгер зашивается в параметры процедуры или коснтруктора. думаю, что задача всё же существует, и от того, что её назвали паттерном или частю архзитектуры, она не исчезнет. у вас просто набита рвука в её решении, и поэтому вы не замечаете то, что её можно вообще не решать, встроить это решение в сам язык/библиотеку. всё равно, что фортранщик будет говорить, что рексурсия не нужна, поскольку он её уже привык эмуцлировать, ни о чём не задумываясь)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>"Понимаешь, все равно надо что то сделать явно — передать контекст или использовать монаду. Главное, насколько сложно это все будет поддерживать потом."
Ну и?
BZ>(а у меня — что с маразматиком ничего личного, просто сначала вы говорите что это закладывается в архзитектуру системы,
Естественно.
BZ> а потом — что архитектор не при чём
Я этого не говорил. Архитетктор очень даже причем.
BZ>, сначала что передавать ничего не нужно, потом — что этот логгер зашивается в параметры процедуры или коснтруктора.
Опять я не говорил, что логгер зашивается в параметры процедуры.
BZ> у вас просто набита рвука в её решении, и поэтому вы не замечаете то, что её можно вообще не решать
То есть явное использование монад это "можно не решать"? Опять же, я же ясно написал — контекст сам по себе в вертикально интегрированных системах полезен. Наконец, тебе же сказали, что в ООП есть еще и поля/свойства объекта. Говоря об архитектуре я имел ввиду не то, что тут надо специальную архитектуру делать, а то что конкретный способ воплощения паттерна зависит от остальной архитектуры системы. Есть явно выделенный контекст — удобно сделать иерархию service providers поверх него, нет, значит лучше использовать другие структуры — объектный граф, каналы сообщений и т.п. И никакого преимущества монад я здесь не вижу — их все равно надо явно использовать. Да и не может быть тут никаких преимуществ — проблема вертикальной интеграции слоев это не технологическая проблема и не проблема алгоритмов, это проблема архитектурная, и никакие языковые выверты их легко и просто решить не в состоянии, не тот порядок.
Здравствуйте, VladD2, Вы писали:
VD>Язык должен быть интуитивным, удобным и эффективным. И догматизм не лучший спутник в достижении этих целей. По сему оцениваю Хаскель как изумительную исследовательскую работу, но не как реальный прикладной язык.
Влад, ты таки уловил основные задачи языка. Вот его авторы рассказывают о целях, которые ставились перед языком, при его создании:
The first order of business was to establish the following goals for the language:
1. It should be suitable for teaching, research, and applications, including building large systems.
2. It should be completely described via the publication of a formal syntax and semantics.
3. It should be freely available. Anyone should be permitted to implement the language and distribute it to whomever they please.
4. It should be usable as a basis for further language research.
5. It should be based on ideas that enjoy a wide consensus.
6. It should reduce unnecessary diversity in functional programming languages. More specifically, we initially agreed to base it on an existing language, namely OL.
Т.е. никто и не пытался занять нишу C++/Java/C#.
VD>Его идеи вроде классов типов и ленивости восхитительны. Но вот в таком вот виде, на мой взгляд, они не применимы на практике.
Так он и создавался для того, чтобы быть на переднем краю в исследованиях функциональных языков.
VD>В общем, я прекрасно понимаю суть наших разногласий. Я эдакий романтический програматик. Ине очень интересны красивые решения, но меня при этом еще заботят эффективность и применимость на практике. Ты же любишь чистые решения что бы они не стоили.
VD>Я понимаю и уважаю эту точку зрения, но не разделяю ее.
VD>Я считаю, что пришло время перевести мэйнстрим на языки которые будут мало отличаться от сегодняшних фоваритов (С++, C# и Java) по эффективности, но при этом дадут возможность существенно поднять уровень разработки.
Haskell и есть та экспериментальная площадка, на которой обкатываются идеи, которые попадают в мейнстрим.
На channel9 есть куча интервью с дядками, которые двигают различные исследовательские проекты (LINQ, PLINQ, STM,...),
многое из которых потом пойдёт дальше для простых смертных.
Так вот они постоянно упоминают Haskell как один из основных инструментов.
Здравствуйте, Трурль, Вы писали:
Т>Почему-то этому интерфейсу приписывают какую-то магическую сверхценность. Например, моноид тоже обладает офигительной общностью. Можно было бы сделать унифицированный интерфейс (plus,zero) для Т>чисел plus= +; zero = 0 Т>списков plus= ++; zero = nil Т>функций plus= .; zero = id
Ага, есть такой, MonadPlus называется.
Т>но будет ли от того медведю польза и удовольствие?
Медведу точно будет.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а это не для начинающих для начала удобно как раз считать, что в хаскеле есть императивный и функциональный подязыки. я даже собирался написать "introduction to IO" в этом ключе, без всяких упоминаний о монадах. может, напишу его на русском
Это хорошее начинание. Только сильно запоздалое.
VD>>И все это ради того чтобы не признать правды — мир императивен и "чистоту" надо просто отделять от "императивной грязи".
BZ>я не зря привёл пример с Ньютоном — он тоже отказался признавать, что планеты просто вращаются по эллиптическим орбитам и развёл целый мааппарат, позволяющий свести это к закону притяжения. всё это — лишь концепции. можно было сделать хаскелл двухконцептным языком, введя в него особые правила для записи императивных программ, их трансляции, оптимизации и т.д. а можно было — пользуясь средствами языка, выразить императивное программирование через функции, "преобразующие мир". при этом язык не раздулся как покойник и весь уже наработанный аппарат компиляторов спокойно работает с новой концепцией как частным случаем старой. ортогональность — это ключ к созданию хороших языков. "усложнять просто, упрощать — сложно"
Я знаю одно. Сложность восприятия это крышка гроба для любого языка.
Вообще, мне кажется мы подходим к точки в истории разития языков когда в список обязательных будут влючаться не только то что влючалось по сей день, но и простота, интуитивность, возможность создания для языка качественной IDE и многие другие "потребительские свойства" на которые забивают большинство исследователей.
VD>>Эта концепция проста для понимания.
BZ>всякая концепция, которую ты уже понял, кажется простой для понимания скажем, я считаю функциональный подход более естественным и простым для понимания, нежели императивный
У нас разный подход. Ты говоришь о том, что тебе кажется, а я о том, за чем наблюдал. Мое мнение о простоте и интуитивности основано на наблдении за тем как настоящие новички воспринимают новый язык. Плюс еще одно. Я работаю редактором и в мои обязанности входит выискивать в статьях места которые будут непонятны читателям. И я без ложной скромности скажу, что приуспел в этом. Так вот я довольно быстро могу оценить что то или иное изложение будет непонятно аудитории. Так вот недавно я как раз вычитывал введение в Хаскель и сделал однозначный вывод, что до конца его дочитают только самые стойкие. И это еще очень неплохой варинат. Все что я видел до этого было еще хуже. Причем учти, что я сделал этот вывод прекрасно понимая концепции ФП.
BZ>и для меня такая программа: BZ>
BZ>fac 0 = 1
BZ>fac 1 = n * fac(n-1)
BZ>
BZ>выглядит простой и ясной.
Это детские примеры.
fac(int n)
{
if (n == 0)
return 1;
else
return n * fac(n - 1);
}
это булшит которым пичкуают читателей во всех трудах прославляющих ФП. Но читатель то может и оглох, но не охринел. Он может не всилах понять написанного, но тонко чувствет обман. Ведь когда он видит сложную программу на ФП, то она превращаетя в кашу птичек.
BZ> а большинству людей, обученных императивному программированию, удобней и понятней запись в виде цикла. третьи же предпочитают higher-order funcs и запишут это в виде:
BZ>
BZ>fac n = foldr (*) [1..n]
BZ>
Вот, вот. И при том объяснении которое дают бльшинство книг и статей по ФП никто из новичков не поймет написанного. Растрою тебя, то тут не наберется и десятка прочевших это сообщение кто полностью поняд как эта штука работает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
.
