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

VE>Окружающую действительность довольно легко представить в виде объектов, над которыми можно произвести действия, и самих действий, в которых участвуют от 0 до нескольких объектов. Действие меняет состояние этих объектов. Более того, действию как правило нужно какое-то конкретное представление объекта (например телевизор в конкретном действии участвует только как параллепипед с массой).
VE>Но это не ООП.
VE>Тут нет объектов, обменивающихся сообщениями, тут нет наследования и полиморфизма, и даже инкапсуляции.
VE>Тут есть объекты, которые в зависимости от ситуации надо представить так или иначе, а это в чистом виде либо преобразование в другой объект, либо type classes.
VE>Тут есть действия, которые работают с _несколькими_ объектами в общем случае, а это функция от нескольких объектов, возвращающая новые состояния этих объектов, а не метод одного из них.
VE>Я не вижу ООП.
VE>Вот если бы можно было написать (man1, man2).поприветствовать(), тогда другое дело. Это действительно калька с реальности. А man1.поприветствовать(man2), это непойми что. Ну правда. Надо ведь (man1, man2, man3, man4).всем_привет().

Дорогой коллега! Готов подписаться под каждым твоим словом здесь. Я не пропагандирую ООП. И type classes я считаю на порядок более правильной идеей, чем обычные классы.

Я написал, что ООП гораздо ближе к этой модели, чем pure lazy FP. Согласен?

И на этом основано мое мнение, что ООП проще pure lazy FP. Понимаешь?

Ок, извини за мой тон.

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

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

P>Дорогой коллега! Готов подписаться под каждым твоим словом здесь. Я не пропагандирую ООП. И type classes я считаю на порядок более правильной идеей, чем обычные классы.

P>Я написал, что ООП гораздо ближе к этой модели, чем pure lazy FP. Согласен?
Вот ведь и не знаю, возможно.
Знакомый у меня есть, начинает программировать. Я его попросил поучить Хаскель. ООП он не знает. Посмотрим, что он расскажет
Правда это будет нескоро.

P>И на этом основано мое мнение, что ООП проще pure lazy FP. Понимаешь?
Понимаю.

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

P>Ок, извини за мой тон.

Не за что. У меня нет проблем с тоном собеседника — подстраиваюсь под него.


P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.

К сожалению, не могу. Возможно, мне помогут более грамотные и опытные коллеги.

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

В точности так я освоил ФВП. Теперь органически не способен смешивать обход структуры (дерева XML, например) и вычисления. Даже на C#. Активно пользуюсь делегатами.

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

P>Здравствуйте, Mr.Cat, Вы писали:

MC>>Здравствуйте, pgregory, Вы писали:
P>>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
MC>>А тут-то что сложного? Всего лишь побочный эффект cps.

P>Тонкая шутка
P>По слогам: лично мне continuations кажутся сложными. Я не навязываю тебе свою точку зрения. Я пытаюсь донести, почему я так считаю.

А CPS вам кажется сложным?
http://en.wikipedia.org/wiki/Continuation-passing_style

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

T>Здравствуйте, pgregory, Вы писали:
P>>>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
T>>>"Реально прост" чем определяется?
P>>Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение.
T>Выделенное тут всё определяет.

Конечно.

T>Если ты думаешь о чём-то как о сложном, то ты не сможешь его никому просто объяснить.

Конечно.

T>Но ведь ты не единственный кто может кому-то что-то обяснять. :)

Конечно.

Почему-то на РСДН принято считать, что люди на форуме должны изрекать только доказуемые истины. Если бы моя точка зрения была доказуемой истиной, я бы написал, что все остальные — заблуждающиеся идиоты, и опубликовал бы доказательство вместе с набором аксиом. Дискуссия бы на этом закончилась. 2 + 2 = 4. Что здесь обсуждать?

Может, я чересчур наивен, но я считаю, что люди на форуме обмениваются личными мнениями. В идеале — чтобы лучше понять свою и чужую позиции. Иначе — см. предыдущий параграф.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Протестую — если ребенок имеет интерес к математике, то объяснить ФП ему проще, чем ООП, так как оно естественнее для него. Готов проиллюстрировать примером: я был ребенком, учился в 8 классе, когда, читая учебник по C++, был удивлен тем, что можно вызывать метод объекта с одними и теми же аргументами, получать разные значения. Сама возможность побочных действий, такая как изменение private переменной, мне показалось противоестественной и не логичной. Понятие ссылки почти не отделимо от возможности побочных действий, которые противоестественны, а усвоить то, что кажется нелогичным, сложно. Поэтому просто объяснить ссылки тоже трудно, замечу, что в тот момент я не был знаком с функциональной парадигмой, машиной Тьюринга и лямбда исчислением, поэтому пример корректен.

Хорошо написано. Your point taken.

РД>Монада имеет слабое отношение к ФП, поэтому её непонимание не мешает пользоваться haskell, достаточно рассматривать maybe, list и io как фичи языка, и не пытаться найти между ними общую структуру. Достаточно думать, что монада (io) это попытка органично ввести взаимодействие с внешнем миром в haskell.

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

РД>Но если от ФП программистов требовать на пальцах объяснить, что такое монада, то тогда разумно требовать от императивщиков на пальцах объяснить верификацию работы программ.

Не понял аналогии.

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

P>Ок, извини за мой тон.

P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.

Пролистайте Erik Meijer, Confessions Of A Used Programming Language Salesman

This paper is a personal account of my journey to democratize
the three-tier distributed programming problem using
(lazy) functional programming concepts. It starts with my
naive attempt to use Haskell as the language to write threetier
distributed data intensive applications, then continues
with my brief flirtation with designing a series of completely
new languages from scratch including Mondrian, XM, and
C!, and ends when I accidentally discover the Change Function
[37] and finally succeed by incorporating functional
programming and monads into the LINQ framework, C# 3.0
and Visual Basic 9.

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

P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.

Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.

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

РД>>Но если от ФП программистов требовать на пальцах объяснить, что такое монада, то тогда разумно требовать от императивщиков на пальцах объяснить верификацию работы программ.

P>Не понял аналогии.

Существование монад в языке haskell связано не с его функциональной сущностью, а с его строгой системой типов. Вектор развития типизации лежит через зависимые типы к светлому будущему, в котором типизация программы практически совпадает со спецификацией. Такая точка зрения позволяет смотреть на типы как теоремы, а на код как на доказательство; потенциально его можно будет автоматически верифицировать. В общем, за монадами уже идет computer-science-жесть (я в ней понимаю мало, но пытаюсь просматривать статьи, и искать идеи, которые можно применить в заурядном коде), поэтому мне, кажется, что требовать объяснить на пальцах что такое монады и зачем они нужны некорректно.

thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!

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

Z>А CPS вам кажется сложным?
Z>http://en.wikipedia.org/wiki/Continuation-passing_style

В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.

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

Z>Пролистайте Erik Meijer, Confessions Of A Used Programming Language Salesman

Супер!

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

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

Z>>А CPS вам кажется сложным?
Z>>http://en.wikipedia.org/wiki/Continuation-passing_style

P>В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.

Ее редко пишут руками, обычно CPS трансформацию делает компилятор. Но понять просто. Дальше: есть языки, где continuations — первокласная сущность, как int в C, ее можно получить в любом месте, сохранить в переменной, вызвать несколько раз — чего тут понимать?

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

Z>Ее редко пишут руками, обычно CPS трансформацию делает компилятор. Но понять просто. Дальше: есть языки, где continuations — первокласная сущность, как int в C, ее можно получить в любом месте, сохранить в переменной, вызвать несколько раз — чего тут понимать? :)

Понимаешь, мне кажется (зачеркнуто) (черт — достало вставлять эти оговорки везде. Все, что я пишу — личное мнение, если не сказано иное — ок?), 99% случаев применения CPS, call-cc & friends можно переписать, используя более простые понятия. Генераторы, исключения и так далее. И код станет лучше. Я не согласен с тем, что абстракция любой ценой — это хорошо.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Вектор развития типизации лежит через зависимые типы к светлому будущему, в котором типизация программы практически совпадает со спецификацией.

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

РД>Такая точка зрения позволяет смотреть на типы как теоремы, а на код как на доказательство; потенциально его можно будет автоматически верифицировать.

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

РД>В общем, за монадами уже идет computer-science-жесть (я в ней понимаю мало, но пытаюсь просматривать статьи, и искать идеи, которые можно применить в заурядном коде), поэтому мне, кажется, что требовать объяснить на пальцах что такое монады и зачем они нужны некорректно.

Я все равно не понял твоей логики, но давай забъем на это. Типизация и верификация гораздо интереснее :-)

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

P>Понимаешь, мне кажется (зачеркнуто) (черт — достало вставлять эти оговорки везде. Все, что я пишу — личное мнение, если не сказано иное — ок?), 99% случаев применения CPS, call-cc & friends можно переписать, используя более простые понятия. Генераторы, исключения и так далее. И код станет лучше. Я не согласен с тем, что абстракция любой ценой — это хорошо.

Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов).

Есть разные подходы к проектированию языков:

Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear necessary.
R5RS

Типичный негативный пример С++ — там практически нет механизмов — одни фичи — расширять его дальше практически нельзя. Но язык живет долго, никто не может знать заранее какая фича понадобиться лет через 10-15.

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

Z>Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов).

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

Z>Есть разные подходы к проектированию языков:
Z>

Z>Programming languages should be designed not by piling
Z>feature on top of feature, but by removing the weaknesses
Z>and restrictions that make additional features appear necessary.
Z>R5RS

Звучит красиво. Но теория и практика совпадают только в теории. Несмотря на концептуальную простоту, схема не получила распространения, и нет предпосылок к тому, что получит.

Side note: существует Kernel, еще более «суровый», чем схема.

Z>Типичный негативный пример С++ — там практически нет механизмов — одни фичи — расширять его дальше практически нельзя. Но язык живет долго, никто не может знать заранее какая фича понадобиться лет через 10-15.

Я понимаю, о чем ты, но, на самом деле, в плюсах слишком много механизмов и слишком мало фич :-) Поясню. В плюсах нет нормальной системы типов. Зато там есть шаблоны, которые по мощи уделывают типы хаскеля на порядок (другое дело, что воспользоваться этой мощью практически бесконечно трудно :-) Там нет сборки мусора, но есть смарт-поинтеры и RAII. И так далее.

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

Это настраивает на прекрасную мысль о том, что идеальный язык должен быть создан для эволюции. Как лисп, только еще на порядок гибче. И, хотя есть опасность, что он, как схема, будет «jack of all trades, master of none», теоретически, он может быть создан. Я даже пытался думать в этом направлении, но понял, что для этого я слишком глуп.

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

P>>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
MC>>А тут-то что сложного? Всего лишь побочный эффект cps.
P>Тонкая шутка
Честно говоря, я не шутил. Если над кодом произведено cps, то call/cc — можно реализовать в виде обычной функции:

(define call/cc
  (lambda (cont f)
    (f cont (lambda (cont1 result)
              (cont result)))))

P>Not only is the name intimidating, but many introductions to its semantics are as well.
Собственно, тут чувствуется намек на недостатки вводных курсов по scheme.

P>По слогам: лично мне continuations кажутся сложными.
В scheme действительно местами заковыристая семантика континуаций. Но на практике c ней нечасто приходится сталкиваться. Возврат/прием нескольких значений из функции (в scheme это можно делать, не применяя списки/векторы) в библиотеках местами используется. А вот на call/cc можно вообще забить — это все-же низкоуровневая штука, и проще пользоваться высокоуровневыми обертками, реализующими исключения, многопоточность и т.п.

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

P>thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!

жаль, что на rsdn нет награды за дезертирство с Поля Брани