S>Это всего лишь способ избавиться от "служебного кода".
При всем уважении к IT, формулировка монады как способ неверна. Монада — это тройка (тип, + пара функций), удовлетворяющая определенным законам. Одним словом — паттерн. Конечно же монаду нужно отделять от синтаксиса, построенном для того, что бы укорачивать код, используя паттерн монады. Синтаксиса может не быть, но монада будет иметь место. Такое вот опровержение тезису "монада = способ избавиться".
Здравствуйте, samius, Вы писали:
S>При всем уважении к IT, формулировка монады как способ неверна. Монада — это тройка (тип, + пара функций), удовлетворяющая определенным законам. Одним словом — паттерн. Конечно же монаду нужно отделять от синтаксиса, построенном для того, что бы укорачивать код, используя паттерн монады. Синтаксиса может не быть, но монада будет иметь место. Такое вот опровержение тезису "монада = способ избавиться".
Именно паттерн. Я когда увидел это объяснение, мне вообще показалось, что это сниппет. Но потом понял, что оченно высокоуровневый сниппет, т.е. именно паттерн.
Я особо над монадами никогда не заморачивался. Лет 10 назад пытался прочеть на этот счет работу Евгения Кирпичева, понял что ничего не понял. Потом осознал, что вероятно и
автор не очень понял (ему было на тот момент лет 20), так и оставил это дело.
Мне всегда казалось, что монады это способ обплясать отсутвивет состоянии в мире фя. Но поскольку суть вычисления в изменении состояния\side effect'ов, вот и ввели монады. Т.е. костыль.
Кодом людям нужно помогать!
Re[14]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Poopy Joe, Вы писали:
S>>Зачем экзамен? Обычно достаточно задать пару наводящих вопросов. Но это хотя бы будет конкретика и толчек для человека, который позволит ему понять действительно ли есть проблема. PJ>Так я тебе и задал. Вместо ответа на него, ты начала разбираться кто должен быть альфой. С тобой все хорошо?
Нет, ты привел фигню. Понять всегда проще на реальных примерах, чем на фигне из картинок. Тот же ассиметричный алгоритм шифрования RSA до конца понял, лишь когда реализовал свою версию, начал читать про малую теорему Ферма. А на картинках — фигня получается.
Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.
S>>Это всего лишь способ избавиться от "служебного кода". PJ>И чем это фраза отличается от дженерики это лишь способ избавиться от служебного кода и интерфейсы это лишь способ избавиться от служебного кода итд?
А тут смотри примеры IT — там все написано.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>При всем уважении к IT, формулировка монады как способ неверна.
S>Там он развернуто написал — прочитай. Суть в этом, а уже детали почитай.
Читал перед тем, как отвечал. Мой аргумент выше и он не изменится от дальнейшего чтения деталей.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Shmj, Вы писали:
S>Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.
Так речь ведь не о том, что это нужно, а о том, что это удобно. Собственно, то, что делает компилятор, когда заменяет короткий монадный синтаксис на функции — он доказывает то, что монада не нужна. Так же, как и цикл for, который заменяется на оператор перехода и набор условий.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Shmj, Вы писали:
S>Ты не задал а отказался задавать — мол не хочешь экзамен устраивать.
Я отказался в том смысле, что меня ответ не интересует, мне уже все понятно. Но что бы понять "если ли проблемы" как ты выразился, ты можешь сам себе ответить.
S>Нет, ты привел фигню.
Ты это понял прочитав главу из книги и запустив пару примеров? Шариковщина, прости господи.
S>Понять всегда проще на реальных примерах, чем на фигне из картинок.
Ну как знаешь, я пытался помочь, хотя подозревал, что ответы на самом деле не интересуют.
S>Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.
Ну это фактически ответ на вопрос, который я тебе и задал — фигня не нужная, костыль. Т.е. основных принципов ты не понял (что совершенно нормально, кстати, для большинства людей). Дальше делай с этим знанием, что хочешь. Можешь дальше копать, можешь забить, это не мое дело.
Re[16]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Poopy Joe, Вы писали:
PJ>фигня не нужная, костыль.
Нет, не костыль а более высокий порядок абстрагирования. В теории это упрощает целый класс задач, но на практике таких задач не так уж много и в том же C#, как заметил IT, уже захардкожено решение для большинства из них.
Re[17]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>фигня не нужная, костыль.
S>Нет, не костыль а более высокий порядок абстрагирования. В теории это упрощает целый класс задач, но на практике таких задач не так уж много и в том же C#, как заметил IT, уже захардкожено решение для большинства из них.
Здесь надо все-таки разобраться, что именно в C# уже было захардкожено, а что именно появилось с помощью "оглядки" на монады.
Итак, до монад было
1) foreach. Честно, к монадам он отношения не имеет вовсе, но имеет к тому, что было до Linq query comprehension syntax, а так же foreach — именно то, чем "едят" построенное с помощью query comprehension или подобного.
2) Nullable<T>, где T — структуры. Очень кривое нечто, что в принципе позволяет на высоком уровне работать с потенциально отсутствующими значениями. А именно, сравнивать, выполнять некоторые арифметические операции. Эта поделка очень сильно не дотягивает до аналога MayBe<T>. Хотя бы уже тем, что ограничена лишь структурами.
3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.
Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.
Когда IT писал что "для монады List в C# уже все есть", он подразумевал то, что это уже есть в Linq-е.
С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.
Так и не знаю причины, почему это реализовано именно так.
В итоге — монады мы имеем, но монадный синтаксис построен на аналоге, не на монаде. Если говорить буквально, то в C# монады языком не поддержаны в чистом виде.
Итак, до Linq ничего годного, похожего на монады в C# не было. С Linq появилось что-то похожее. Да, монаду List можно теперь использовать не напрягаясь, но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.
Re[5]: Реальные проекты на экзотике (Haskell и пр.) - как?
Здравствуйте, Shmj, Вы писали:
A>>Может какие-то работодатели платят за курсы по языку, но я очень сомневаюсь, что это того стоит. Я с таким никогда не сталкивался. И нормальные программисты, когда переходили на другой проект с другим для себя языком, через некоторое время хорошо САМИ изучали новый язык.
S>Зачем курсы? Просто начинают работать и получают зарплату за то что учат язык (по факту).
Для работодателя это глупо. Наберёт всякий шлак, которому не интересно программировать, но они слышали, что хорошо платят.
Это не вопрос денег. Всем моим толковым квалифицированным коллегам нравится программировать. Они сами готовы платить за курсы, они готовы на понижение зарплаты, если можно поменять язык на их любимый. Но тут опять же работодатель, который не хочет увеличивать риски и предпочитает джаву.
Ещё раз — люди готовы сами снизить себе зарплату, чтобы писать проект на Хаскеле (не у всех это Хаскель). И именно работодатель на это не согласен.
Re[6]: Реальные проекты на экзотике (Haskell и пр.) - как?
Работодатели не любят менять технологии, потому что они слабо в них разбираются и, часто, есть обросший мхом местный авторитет, который рассказывает, что в и c# все есть, а чего нет, того и не надо. Но если просто взять и показать разницу в эффективности. Для чего конечно приходится делать дополнительную работу, это верно. То работодатель разумный к команде прислушивается и команду поддерживает, да и курсы оплачивают. Хотя, признаться, чаще самому приходится делать внутреннее обучение. А если он упертый, занимается микро-менеджментом, то зачем там сидеть и фигней страдать?
Здравствуйте, samius, Вы писали:
S>2) Nullable<T>, где T — структуры. Очень кривое нечто, что в принципе позволяет на высоком уровне работать с потенциально отсутствующими значениями. А именно, сравнивать, выполнять некоторые арифметические операции. Эта поделка очень сильно не дотягивает до аналога MayBe<T>. Хотя бы уже тем, что ограничена лишь структурами.
Есть оператор ?. Наверное не сталкивались...
Это я и называю захардкожено.
S>но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.
Здравствуйте, Shmj, Вы писали:
S>Есть оператор ?. Наверное не сталкивались...
Сталкивался, конечно. Забыл о нем. Не так много приходилось пользоваться, не во всех проектах версия языка позволяет его задействовать.
Но опять-таки, похоже на монаду внешне. Но лишь похоже в некоторых обстоятельствах. Когда встает задача типа "заменить в строке a все вложения b если a и b не null", как становится понятно что одним оператором ?. и штатным методом Replace не обойтись.
S>Это я и называю захардкожено.
Здесь я согласен, что это захардкожено. Как раз пример того, что способ избавиться от служебного кода есть, а монады формально нет, т.к. законы выполняются не для всех функций, а лишь для тех, что вызываются у значения через точку.
S>>но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.
S>А кто говорил про "до появления Linq"?
Никто в теме не говорил. Но я работаю с C# начиная с первой беты первой версии и вижу изменения в языке, сделанные благодаря функциональщине, функциональщикам и языку Haskell в частности. Отдельное спасибо Эрику Мейеру за Linq.
Потому и призываю в контексте исторического процесса оценить, чем бы был C#, если бы не влияние Haskell и монад. Что бы там было захардкожено, а что — нет.
Т.е. возвращаясь к фразе
В теории это упрощает целый класс задач, но на практике таких задач не так уж много и в том же C#, как заметил IT, уже захардкожено решение для большинства из них.
осмелюсь утверждать, что если бы не Haskell и монады, скорее всего, этих захардкоженных решений бы не было. Как минимум, не всех.
И конечно, жду, когда же MS захардкодит в C# парсеры. Особо не рассчитываю.
Re[7]: Реальные проекты на экзотике (Haskell и пр.) - как?
Со статистикой всегда надо аккуратно обращаться. Вообще не очень верится, т.к. Хаскель чаще будут использовать в академической среде, где зарплаты в среднем ниже. Может я пропустил широкое внедрение Хаскеля в бизнесе.
Не стоит забывать, что во многих областях наибольшие успехи (и как следствие деньги) будут у тех, кому интересно заниматься этим делом. Они программируют, т.к. любят, а не для того, чтобы заработать деньги. Т.е. в целом деньги мотиватор более слабый, чем интерес. Не знаю, может просто более квалифицированные и заинтересованные люди хотят программировать на Хаскеле, и естественно они получают больше среднего по больнице. Но их коллеги с такой же квалификацией на Java или JavaScript будут зарабатывать больше.
PJ>Работодатели не любят менять технологии, потому что они слабо в них разбираются и, часто, есть обросший мхом местный авторитет, который рассказывает, что в и c# все есть, а чего нет, того и не надо. Но если просто взять и показать разницу в эффективности. Для чего конечно приходится делать дополнительную работу, это верно. То работодатель разумный к команде прислушивается и команду поддерживает, да и курсы оплачивают.
Выбор языка это не микроменеджмент. Если проект будет жить более 3х лет, то язык очень сильно на всё влияет. Это и платформа и ограничения и зависимости, а кроме этого достпуные разработчики. С мейнстримом в целом рисков будет сильно меньше.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
Здравствуйте, Aquilaware, Вы писали:
A>Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.
А волосы станут мягкими и шелковистыми.
Re[8]: Реальные проекты на экзотике (Haskell и пр.) - как?
Здравствуйте, alzt, Вы писали:
A>Со статистикой всегда надо аккуратно обращаться. Вообще не очень верится, т.к. Хаскель чаще будут использовать в академической среде, где зарплаты в среднем ниже. Может я пропустил широкое внедрение Хаскеля в бизнесе.
С верой это к культам и религиям, я лишь привел сухие цифры. И да, на хаскеле зарплата ниже, чем на допустим, f#, который широко используется в банковской среде, где денег больше.
A>Не стоит забывать, что во многих областях наибольшие успехи (и как следствие деньги) будут у тех, кому интересно заниматься этим делом. Они программируют, т.к. любят, а не для того, чтобы заработать деньги. Т.е. в целом деньги мотиватор более слабый, чем интерес. Не знаю, может просто более квалифицированные и заинтересованные люди хотят программировать на Хаскеле, и естественно они получают больше среднего по больнице. Но их коллеги с такой же квалификацией на Java или JavaScript будут зарабатывать больше.
Я не понимаю почему то что нравится не должно еще и доход приносить? Какая тут связь вообще?
A>Выбор языка это не микроменеджмент. Если проект будет жить более 3х лет, то язык очень сильно на всё влияет. Это и платформа и ограничения и зависимости, а кроме этого достпуные разработчики. С мейнстримом в целом рисков будет сильно меньше..
Конечно влияет. Еще ни разу не видел, чтобы решения на императивных языках не превращались в болото говнокода в котором никто не хочет копаться. Когда одно чиниться другое ломается, когда тратятся недели на отлов странных побочных эффектов невинных изменений, обещанные сроки надо умножать pi.
Если это все не создает риски для бизнеса, то у нас явно разное понимание рисков.
Понятно, что в виртуальном мире rsdn все все сдают в срок и с высочайшим качеством, но вот лично мне приходится жить в реальном мире.
Здравствуйте, samius, Вы писали:
S>3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.
Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5
S>Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.
А почему рассмативается List, а не IEnumerable<T>?
S>С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.
А чем так примечателен SelectMany в контексте монад?
S>Так и не знаю причины, почему это реализовано именно так.
А как должно?
Кодом людям нужно помогать!
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.
S>Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5
Верно.
И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.
S>>Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.
S>А почему рассмативается List, а не IEnumerable<T>?
Да просто взял название монады из Haskell.
Сейчас с Linq-ом IEnumerable<T> выглядит монадой с точностью до реализации связывания. Но до Linq-а невзирая на foreach + yield, я бы не говорил о наличии монады IEnumerable<T> в языке. Руками, вероятно, можно было бы запилить ее. Но мы же не об этом все-таки.
S>>С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.
S>А чем так примечателен SelectMany в контексте монад?
диковинной для bind формой
class C<T>
{
public C<V> SelectMany<U,V>(Func<T,C<U>> selector,
Func<T,U,V> resultSelector);
}
return зашит в самом SelectMany, кроме этого у него два аргумента-функции.
S>>Так и не знаю причины, почему это реализовано именно так.
S>А как должно?
Я же написал выше. Связывание вычислений по нескольким контейнерам в Haskell, F#, Scala — вложенное. Есть внешний bind, в который передается функция, использующая следующий bind:
Здравствуйте, samius, Вы писали:
S>>Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5 S>Верно. S>И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.
А в чем проблема вызвать Task.Wait() или Task.ContinueWhen()?
S>>А чем так примечателен SelectMany в контексте монад? S>диковинной для bind формой S>return зашит в самом SelectMany, кроме этого у него два аргумента-функции.
А почему именно две ф-ия аргумента важны? Почему просто Select не подходит. Я реально в этом(монадах) не понимаю ничего, вот и спрашиваю. Тут, вероятно, надо понять как bind работает...
S>>>Так и не знаю причины, почему это реализовано именно так.
S>Я же написал выше. Связывание вычислений по нескольким контейнерам в Haskell, F#, Scala — вложенное. Есть внешний bind, в который передается функция, использующая следующий bind: S>
S>bind(...,x => bind(...))
S>
S>Но в C# мы имеем: S>
S>a.SelectMany(...).SelectMany(...)
S>
Не очень помогло, ибо по-прежнему не пониаю сути bind...
Шариковщина, прости господи. 
