Здравствуйте, palm mute, Вы писали:
PM>Ай-ай-ай, бедные-бедные 90% здоровых людей. PM>Злые языки говорят, уровень обсуждения на рсдн начал падать, это правда?
Правда. Стольк содержательные сообщения его сильно портят.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, deniok, Вы писали:
D>Физически проблемы взятия адреса переменной в памяти и доступа к ней по этому адресу тоже нет. И кто тут ругает C++ за такую возможность? А после запрета доступа по адресу наворачиваются всякие value- и ref-типы, boxing и unboxing. Казалось бы, объект — это просто кусок памяти, неважно какой (стек, куча).
Физической проблемой является нарушение типобезопасности. Он приводит к самым что нинаесть реальным проблемам. А вот запрет вызова императивного кода "чистым" и наоборот кроме как пуританством болше оправдать нечем.
D>Позволь всё-таки существовать функциональным языкам, а не только смешанным.
Да, сколько угодно. Пусть толко появится хоть один. А то каждый чистый язык обязательно имеет грязные костыли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>Язык должен быть интуитивным, удобным и эффективным. И догматизм не лучший спутник в достижении этих целей. По сему оцениваю Хаскель как изумительную исследовательскую работу, но не как реальный прикладной язык.
EC>Влад, ты таки уловил основные задачи языка. EC>Вот его авторы рассказывают о целях, которые ставились перед языком, при его создании:
EC>
EC>The first order of business was to establish the following goals for the language:
EC>1. It should be suitable for teaching, research, and applications, including building large systems.
EC>2. It should be completely described via the publication of a formal syntax and semantics.
EC>3. It should be freely available. Anyone should be permitted to implement the language and distribute it to whomever they please.
EC>4. It should be usable as a basis for further language research.
EC>5. It should be based on ideas that enjoy a wide consensus.
EC>6. It should reduce unnecessary diversity in functional programming languages. More specifically, we initially agreed to base it on an existing language, namely OL.
Думаю ты на настолько глуп чтобы думать, что я приписывал эти черты Хаскелю. Авторам этого языка к сожалению не удалось создать язык отвечающий этим требованиям. Хаскель интуитивен только узкому кругу людей с математиким бэкэндом. Меж тем программирование уже давно вышло за рамки математики.
EC>Т.е. никто и не пытался занять нишу C++/Java/C#.
Претендуют, еще как. Только большинству эта ниша просто не позубам.
EC>Так он и создавался для того, чтобы быть на переднем краю в исследованиях функциональных языков.
Это ему удалось.
VD>>Я считаю, что пришло время перевести мэйнстрим на языки которые будут мало отличаться от сегодняшних фоваритов (С++, C# и Java) по эффективности, но при этом дадут возможность существенно поднять уровень разработки.
EC>Haskell и есть та экспериментальная площадка, на которой обкатываются идеи, которые попадают в мейнстрим.
Ты внимательно читал то что я написал прежде чем отвечать? Или у тебя прицип в жизни такой отчечать все что угодно лиш бы оно не имело никакого отношения к словм оппонентов?
EC>На channel9 есть куча интервью с дядками, которые двигают различные исследовательские проекты (LINQ, PLINQ, STM,...), EC>многое из которых потом пойдёт дальше для простых смертных. EC>Так вот они постоянно упоминают Haskell как один из основных инструментов.
И что? Это из серии услышал звон незнаю где он.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кроме слова "бред" у меня других оценок не находится.
Слова "query monad, как в HaskellDB, над которым, кстати, он работал" вообще каша какая-то. Какое отношение "query monad" из HaskellDB имеет к C#. И какое отношение между сравнением чего-то с чем-то из другого языка имеет к наличию этого в другом языке? И соттвественно оправданию лозунгов вроде "LINQ это монады для мейнстрима."?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
M>Вот собственно и все. M>There is no spoon.
Видимо в этом месте все вокруг должны начать хлопать в ладоши и восклицать "ах как это великолепно". Вот только есть только один обрдованный который часто радуется за компанию. Не исключу, что к нему присояденятся разные ИвилЧилды и им подобные.
Но мне что-то не радостно. Я вспоминаю принцип Оккама. И я вижу только одно. Вы пытаетесь объяснить простые вещи введением лишней для императивных ООЯ сущностей.
Я не спорю, в Хаскеле с его догматами монады вещь нужная. Но я так и не услышал разумного обяснения того зачем эту сущность не то что вводить в ООЯ, но даже употреблять для объясениях тех или иных концепций?
M>В качестве примера рекурсии часто используется вычисление факториала. Но без tail оптимизации оно значительно менее эффективно чем императивное решение в лоб. Однако это не значит что сама идея рекурсии ущербна.
Не улавливаю тут логической связи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Про ужасную сложность передачи логгера внутрь кода без монад не я рассказывать начал, так что притензии не ко мне. У меня с логгером никогда никаких проблем не было.
Я тебе еще раз повторяю, что у они себе сами объясняют как боросться с тараканами которых они сами же запустили в свою голову.
Люди принимают догмат "чистоты", но сразу же придумывают другой догамт позволяющий эту чистоту обойти. Казалось бы так все просто. В ФЯ любая функция при одном наборе аргументов обязана вернуть один определенный результат. Это помогает во многих случаях. Там распраллеливание, простота отладки, и еще много чего, но вот увы это не вяжется с реальным миром. В любом ООЯ мы просто создали бы объект в который положили бы ссылку на перменную или, как это предлагаешь ты, на хитрый объект сервис-локатор, но увы у нас догмы. Мы не может это сделать. Тогда мы придумываем хитрую чтоуку называем ее поумнее и вуаля обходим наши же ограничения.
Увы и ах обоход то и дело выливается в кучу противоречий и проблем. Но мы внушаем себе что так и должно быть.
Нам говорят, что бошку можно сломать при попытке понять наши извращения. И мы знаем есть куда более простые сущьности повзоляющие решать проблемы. Они понятны и логичны. Но не в наших правиалх выбирать простые пути. Мы борцы за идею. Идею чистоты. Даешь девственность даже путем операции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>The first order of business was to establish the following goals for the language: EC>>1. It should be suitable for teaching, research, and applications, including building large systems. EC>>2. It should be completely described via the publication of a formal syntax and semantics. EC>>3. It should be freely available. Anyone should be permitted to implement the language and distribute it to whomever they please. EC>>4. It should be usable as a basis for further language research. EC>>5. It should be based on ideas that enjoy a wide consensus. EC>>6. It should reduce unnecessary diversity in functional programming languages. More specifically, we initially agreed to base it on an existing language, namely OL.
VD>Думаю ты на настолько глуп чтобы думать, что я приписывал эти черты Хаскелю.
Будь любезен пиши без ошибок, хотя бы когда пытаешься обсуждать чью-то глупость/неглупость, а то тебя можно неправильно понять.
VD>Авторам этого языка к сожалению не удалось создать язык отвечающий этим требованиям.
Что именно из этого списка не удалось? Можешь аргументировать?
VD>Хаскель интуитивен только узкому кругу людей с математиким бэкэндом. Меж тем программирование уже давно вышло за рамки математики.
Где ты там интуитивность среди целей увидел?
EC>>Haskell и есть та экспериментальная площадка, на которой обкатываются идеи, которые попадают в мейнстрим. VD>Ты внимательно читал то что я написал прежде чем отвечать? Или у тебя прицип в жизни такой отчечать все что угодно лиш бы оно не имело никакого отношения к словм оппонентов?
Давай ты оставишь в покое мои припницы. Почему ты вместо ответа на вопрос постоянно переходишь на личности?
VD>Люди принимают догмат "чистоты", но сразу же придумывают другой догамт позволяющий эту чистоту обойти. Казалось бы так все просто. В ФЯ любая функция при одном наборе аргументов обязана вернуть один определенный результат. Это помогает во многих случаях. Там распраллеливание, простота отладки, и еще много чего, но вот увы это не вяжется с реальным миром. В любом ООЯ мы просто создали бы объект в который положили бы ссылку на перменную или, как это предлагаешь ты, на хитрый объект сервис-локатор, но увы у нас догмы. Мы не может это сделать. Тогда мы придумываем хитрую чтоуку называем ее поумнее и вуаля обходим наши же ограничения.
на момент создания хаскела такой язык уже был — ML более того, как сказано в той самой history of haskell, делая lazy язык, поневоле приходишь к pure языку — эти вещи не строго взаимосвязаны, но иначе получается неудобно. в результате в хаскеле появилось два варианта для организации i/o, затем наконец пришли к третьему — монадам. кстати, статья "Imperative Functional Programming" http://www.haskell.org/ghc/docs/papers/imperative.ps.gz была признана оказавшей наибольшее влияние на всё FP в 90-х годах!
далее. сделав в языке две ипостаси — чистые функции и процедуры, ты должен будешь продумать язык отдельно для каждой из них, продумать их правила взаимодействия и т.п. затем эта удвоенная сложность выльется в компиляторы, в понятия программирования и т.д. почему, думаешь, в С вместо отдельного процедурного типа использовали функции типа void? для концептуальной простоты.
здесь же потери были бы ещё больше. и никакого выигрыша. фактически, сам pure язык позволяет сформулировать концепцию процедуры в нём, используя этот трюк с realworld. и тогда вместо того, чтобы формулировать правила для процедур отдельно, они просто выводятся из общих правил для любых pure функций, становятся их частным случаем. общее кол-во концепций в языке уменьшается, а это не может не радовать
далее. на самом деле отнюдь не монады имитируют императивное программирование. его имитируют фиктивные значения realworld. в некоторых других языках (clean, mercury) такие значения тоже используются. разница только в том, что в тех языках синтаксический сахар был направлен непоредственно на убирание этих мозолящих глаза параметров, а в хаскеле пошли дальше и спрятали их с помощью higher-order функции >>= :
putChar 'a' >>= putChar 'b'
эквивалентно
let (rw1,_) = putChar 'a' rw0
(rw2,x) = putChar 'b' rw1
in (rw2,x)
как видишь, одна эта операция без всяких монад, лёгкой джазовой походкой, избавляется от необходимости явного упоминания фиктивного параметра. и синтаксический сахар в Хаскел генерит не непосредственно фиктивные параметры, как в других языках, а вот эти вызовы >>=
что же касается концепции монад, это это уже было обобщение этого паттерна, использование его в других областях. на данный момент можно сказать, что монады — это стратегия вычислений, определяемая отдельно от самих этих вычислений
VD>Слова "query monad, как в HaskellDB, над которым, кстати, он работал" вообще каша какая-то. Какое отношение "query monad" из HaskellDB имеет к C#. И какое отношение между сравнением чего-то с чем-то из другого языка имеет к наличию этого в другом языке? И соттвественно оправданию лозунгов вроде "LINQ это монады для мейнстрима."?
собственно, LINQ, как и HaskellDB — интерфейс к БД. в HaskellDB для этого использована специальная монада, которая позволяет пошагово уточнить выполняемый запрос, т.е. ты можешь написать что-то вроде:
selectFrom "table" >>= groupBy "order" >>= ...
и >>= будет стратегией вычислений, формирующей из отдельных вызовов выполняемый оператор sql. в linq, вероятно, точно так же
VD>Люди принимают догмат "чистоты", но сразу же придумывают другой догамт позволяющий эту чистоту обойти. Казалось бы так все просто. В ФЯ любая функция при одном наборе аргументов обязана вернуть один определенный результат. Это помогает во многих случаях. Там распраллеливание, простота отладки, и еще много чего, но вот увы это не вяжется с реальным миром. В любом ООЯ мы просто создали бы объект в который положили бы ссылку на перменную или, как это предлагаешь ты, на хитрый объект сервис-локатор, но увы у нас догмы. Мы не может это сделать. Тогда мы придумываем хитрую чтоуку называем ее поумнее и вуаля обходим наши же ограничения.
по-твоему, паттерны проектирования появились потому, что в ООП такие вещи просто сделать?
сам представь, что проще — вызвать одну функцию на верхнем уровне (запустить эту монаду) или добалвять во _все_ объекты то или иное свойство?
Здравствуйте, BulatZiganshin, Вы писали:
VD>>Слова "query monad, как в HaskellDB, над которым, кстати, он работал" вообще каша какая-то. Какое отношение "query monad" из HaskellDB имеет к C#. И какое отношение между сравнением чего-то с чем-то из другого языка имеет к наличию этого в другом языке? И соттвественно оправданию лозунгов вроде "LINQ это монады для мейнстрима."?
BZ>собственно, LINQ, как и HaskellDB — интерфейс к БД. в HaskellDB для этого использована специальная монада, которая позволяет пошагово уточнить выполняемый запрос, т.е. ты можешь написать что-то вроде:
BZ>selectFrom "table" >>= groupBy "order" >>= ...
BZ>и >>= будет стратегией вычислений, формирующей из отдельных вызовов выполняемый оператор sql. в linq, вероятно, точно так же
Насколько я понял именно так и есть, т.е. это адаптация озвученной тобой идеи и решения для VB и C#.
Здравствуйте, VladD2, Вы писали:
L>>Увы, почему то монады сложны для первоначального понимания (тяжело врубиться, грокнуть). Хотя по сути они просты.
VD>Ну, слава богу хоть один из прверженцев пуризма признал этот проской казалось бы факт.
Грязнули наступают?
Кто то здесь говорил, что врубился в монады первый же день? Потом, я не считаю сложность вхождения в язык большой проблемой. Причина проста — я не очень то нуждаюсь в том, чтобы Хаскель стал мейнстримом. А применяю я их очень просто и естественно. Они меня совершенно не напрягают.
VD>А можно ли выразить нужные концепции в языке другими, более легкими для понимания сущьностями?
Если мы говорим об IO/State монаде, то для этого были предложены такие способы, как потоки и продолжения. К сожалению, это слишком частные решение. Они решают только проблему последовательного исполнения, в то время как монада (вообще, а не IO) — более общую. Таким образом, эти способы не могут решить проблемы, которые решают другие монады. Аналог монад — комонады более просты для понимания, и на них тоже можно сделать IO и многое другое (например, Richard B. Kieburtz — Codata and Comonads in Haskell). В реализации, правда, чуть сложнее (правда, это имхо).
Если же под более легкими для понимания сущностями ты имеешь внесение в язык явного императива, то это мы с тобой уже обсуждали: это (минимум) вопросы целей, и цели авторов языка могут не совпадать с твоими.
Здравствуйте, VladD2, Вы писали:
AVK>>Про ужасную сложность передачи логгера внутрь кода без монад не я рассказывать начал, так что притензии не ко мне. У меня с логгером никогда никаких проблем не было.
VD>Я тебе еще раз повторяю, что у они себе сами объясняют как боросться с тараканами которых они сами же запустили в свою голову.
На словах — граница между интерпретацией и фактом очень тонка. Например, эти же самые слова абсолютно применимы к тебе, когда ты пытаешься объяснить появление монад. Ты решил, что мир императивен, и сделал из этого вывод, что императивные конструкции нужны. А когда увидел, что необходимости в них нет, и что все задачи, которые решает императив точно так же решает и другая модель, то ты начинаешь бороться с собственными тараканами, оправдывая лозунг "мир императивен". А всего то и надо, что понять — мир не императивен. Это модель мира, которая у тебя в голове, императивна.
Если принять за основу эту интерпретацию, то тараканы в голове не у нас
А всего то и надо, что оперировать фактами, а не вываливать собственное мнение о мотивах других людей под видом фактов.
VD>Увы и ах обоход то и дело выливается в кучу противоречий и проблем. Но мы внушаем себе что так и должно быть.
Пардон, где противоречия? Где проблемы?
VD>Нам говорят, что бошку можно сломать при попытке понять наши извращения.
Ну не можешь ты понять монады, ну бывает. Неприятно, что ты своё непонимание обращаешь в наше извращение.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>сам представь, что проще — вызвать одну функцию на верхнем уровне (запустить эту монаду) или добалвять во _все_ объекты то или иное свойство?
"Проще", не значит "лучше". Проще натыкать глобальных переменных или еще какую-нить фигню спароть. Но код пишется не для выброса. Его потом читать и поддерживать надо. И тут в первую очередь важна понятность.
По мне так положить ссылку в объект не так сложно и не вызвает никаких проблем.
Кроме того есть такие вещи как замыкания. В том же Немерле я обычно реализую алгоритм в виде логальных функций которые позволют делать замыкания на внешний контекс. Передовать при этом ничего не надо. И выглядит просто и понятно. По сути классы и их поля это тоже замыкания. Так что не вижу надобности в шаманстве.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>сам представь, что проще — вызвать одну функцию на верхнем уровне (запустить эту монаду) или добалвять во _все_ объекты то или иное свойство?
VD>"Проще", не значит "лучше". Проще натыкать глобальных переменных или еще какую-нить фигню спароть. Но код пишется не для выброса. Его потом читать и поддерживать надо. И тут в первую очередь важна понятность.
вот именно! как раз монады и позволяют сделать это прозрачно
VD>По мне так положить ссылку в объект не так сложно и не вызвает никаких проблем.
на каждую операцию, для которой может понадобиться контекст? такое решение быстро вырастает в сложную архитектуру, как раз и описанную Фаулером. монады же позволяют сделать это средтствами самого языка, а не тщательно проработанного и аккуратно выполняемого паттерна дизайна. так что ещё раз повторюсь, паттерны — это разница между выбранной методолгией программирования и средствами, предоставляемыми непосредственно языком. в каких-то языках нужны паттерны рекурсивного вызова, ООП, синхронизации тредов, организации higher-order functions. в каких-то они являются частью языка или бибилиотек
VD>Кроме того есть такие вещи как замыкания. В том же Немерле я обычно реализую алгоритм в виде логальных функций которые позволют делать замыкания на внешний контекс. Передовать при этом ничего не надо. И выглядит просто и понятно. По сути классы и их поля это тоже замыкания. Так что не вижу надобности в шаманстве.
представьте себе сериализатор объекта. он рекурсивно вызывает сериализаторы подобъектов. локальности не получается
Bulat,
BZ>что же касается концепции монад, это это уже было обобщение этого паттерна, использование его в других областях. на данный момент можно сказать, что монады — это стратегия вычислений, определяемая отдельно от самих этих вычислений
Ну что же, спасибо. Наконец, я получил наиболее полный ответ на мой вопрос про
Здравствуйте, BulatZiganshin, Вы писали:
BZ>что же касается концепции монад, это это уже было обобщение этого паттерна, использование его в других областях. на данный момент можно сказать, что монады — это стратегия вычислений, определяемая отдельно от самих этих вычислений
Со всем согласен, кроме последнего утверждения. AFAIK, применять монады для формализации вычислений впервые предложил Moggi в статье: http://citeseer.ist.psu.edu/moggi89computational.html
И уже там говорится, что с помощью монад можно моделировать изменяемое состояние (а не ввод-вывод) и continuations.
Эта статья менее популярна, чем Imperative functional programming (последняя на работу Moggi ссылается), т.к. читателя в ней не жалеют, грузят theoretical computer science по полной программе.
Грязнули наступают?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
