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

S>Ну так внутри кондома-то всегда находится весьма небезопасный х. Это не делает секс в кондоме небезопасным.

...хватит уже умничать, Рваная резинка! Маленьким мальчикам пора спать!!!

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

S>Здравствуйте, D. Mon, Вы писали:

DM>>Т.е. это все же safePerformIO, а не unsafe.
S>Ну так внутри кондома-то всегда находится весьма небезопасный х. Это не делает секс в кондоме небезопасным.

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

Возвращаясь от метафоры обратно, если у нас есть такой условно код:

x = readInt();
y = readInt();
return f(x,y);

То в ленивом языке порядок вычисления x и y крайне сложно предсказуем (зависит от того, как они будут использованы в f), и если readInt() читает числа извне, то что окажется в x, а что в y — не угадаешь. Т.е. просто так пользоваться IO в ленивом языке нельзя. А вот если обернуть его в монаду, она заставляет выполняться все IO операции в четко определенном порядке, что даже в условиях ленивости делает IO безопасным — разумным и предсказуемым. Проблема с unsafePerformIO в том, что она прячет IO операцию в чистое значение, что приводит опять к непредсказуемому порядку выполнения таких операций, отсюда и небезопасность. Т.е. проблема не в самом х IO, а в беспорядочном неупорядоченном его применении.

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

I>Вы можете объяснить что такое монады, используя базовую терминологию языков типа C++/C#/Java? (можно вводить новые понятия, но каждое понятие должно быть подкреплено реальными практическими примерами)

Я начну с примеров.

int x,y;
x = 1;
y = x;
x = 2;
return x + y;

Вот это была монада State.

string s = readLine();
writeLine(s);

Вот это была монада IO.

int x,y;
x = 1;
string s = readLine();
y = x;
x = 2;
writeLine(s);
return x + y;

А тут был применен трансформер монад StateT, соединивший две монады в одну.


В языках вроде C++ и Java ряд монад уже встроены. А хаскель просто такой примитивный и бедный язык, что там их забыли включить, приходится библиотечно решать те же задачи.

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

DM>В языках вроде C++ и Java ряд монад уже встроены. А хаскель просто такой примитивный и бедный язык, что там их забыли включить, приходится библиотечно решать те же задачи.

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

Например, Sharepoint. Порой кажется, что его писала команда шизофреников, к-рым поставили задачу повыделываться.

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

S>Например, Sharepoint. Порой кажется, что его писала команда шизофреников, к-рым поставили задачу повыделываться.

Все проще
1) Писали индусы. Реально видел фотку Office Team в 2009 году — одни индусы.
2) Очень древний код. Некоторые вещи достались в наследство с 1998-2001 года.
3) У руля Product Group с 2003 года стоят маркетологи, поэтому качество и полезность уступают "потенциальной продаваемости".

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

DM>В языках вроде C++ и Java ряд монад уже встроены. А хаскель просто такой примитивный и бедный язык, что там их забыли включить, приходится библиотечно решать те же задачи.

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

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

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

S>>Например, Sharepoint. Порой кажется, что его писала команда шизофреников, к-рым поставили задачу повыделываться.

G>Все проще
G>1) Писали индусы. Реально видел фотку Office Team в 2009 году — одни индусы.
G>2) Очень древний код. Некоторые вещи достались в наследство с 1998-2001 года.
G>3) У руля Product Group с 2003 года стоят маркетологи, поэтому качество и полезность уступают "потенциальной продаваемости".

Только как понятийный аппарат (все эти service applications и services, SPSite к-рый называется site collection, а SPWeb — это сайт и т.п. муть ЛСДшная) влияет на продаваемость? Я вот ника кне догоню, нафига вводить раздельно понятия сервисов и приложений, когда сам ASP.NET прекрасно и без этого огорода слов живет и работает?

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

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

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

S>>>Например, Sharepoint. Порой кажется, что его писала команда шизофреников, к-рым поставили задачу повыделываться.

G>>Все проще
G>>1) Писали индусы. Реально видел фотку Office Team в 2009 году — одни индусы.
G>>2) Очень древний код. Некоторые вещи достались в наследство с 1998-2001 года.
G>>3) У руля Product Group с 2003 года стоят маркетологи, поэтому качество и полезность уступают "потенциальной продаваемости".

S>Только как понятийный аппарат (все эти service applications и services, SPSite к-рый называется site collection, а SPWeb — это сайт и т.п. муть ЛСДшная) влияет на продаваемость?
Никак, этого всего пользователь (покупатель) не видит. Пользоватаель как раз видит то, что разработчику очень сложно использовать. Например в 2013 friendly-urls требуют десятки приседаний/

S>Я вот ника кне догоню, нафига вводить раздельно понятия сервисов и приложений, когда сам ASP.NET прекрасно и без этого огорода слов живет и работает?
Service Applications позволяют частями масштабировать функциональность. например на серваках A и B работает excel services, а на B и C поиск. ASP.NET не позволяет все это делать, увы.

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


S>>Я вот ника кне догоню, нафига вводить раздельно понятия сервисов и приложений, когда сам ASP.NET прекрасно и без этого огорода слов живет и работает?
G>Service Applications позволяют частями масштабировать функциональность. например на серваках A и B работает excel services, а на B и C поиск. ASP.NET не позволяет все это делать, увы.

Я про services и service applications. Нафига их вводить как отдельные понятия и иметь для них разный UI для запуска/останова — вот чего я никак не догоняю.

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

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


S>>>Я вот ника кне догоню, нафига вводить раздельно понятия сервисов и приложений, когда сам ASP.NET прекрасно и без этого огорода слов живет и работает?
G>>Service Applications позволяют частями масштабировать функциональность. например на серваках A и B работает excel services, а на B и C поиск. ASP.NET не позволяет все это делать, увы.

S>Я про services и service applications. Нафига их вводить как отдельные понятия и иметь для них разный UI для запуска/останова — вот чего я никак не догоняю.

Вкратце так:
Сервис (SPService) — некоторый модуль функциональности типа "профили пользователей", "поиск" или "хранилище метаданных", то есть тип функциональности.
Сервис-приложение (SPServiceApplication) — логический экземпляр функциональности — конкретное хранилище метаданных, обычно имеет свою БД (разные ServiceApplication одного типа — разные БД).
Экземпляр сервиса (SPServiceInstance) — физический экземпляр функциональности на конкретном сервере. При этом "запуск" экземпляра на сервере создает веб-сервисы (реальные webapp на iis) для всех service applications данного типа.
Прокси сервис приложения (SPServiceApplicationProxy) — конкретный класс для обращения к service application, промежуточный класс нужен в первую очередь чтобы делать балансировку нагрузки, так как физически каждый service app имеет несколько экземпляров на разных серверах.


Вся эта кухня нужна для масштабирования, мультитенантности и изоляции. Реально переусложнено очень сильно, оправдано такое усложнение в очень малом количестве случаев.
Как раз у МС и была цель продать эту кухню хостерам и поднять свое облако. Но вся эта сложность ложится на разработчиков, даже готовые шаблоны\генераторы не сильно помогают.

Кстати в 2013 уже как-бы не очень рекомендуется создавать по несколько ServiceApp, а пользоваться так называемым partitioning.

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

G>Реально переусложнено очень сильно

Я про то и говорю — шизофреники придумывали для других шизиков, а не для людей.

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

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

G>>Реально переусложнено очень сильно

S>Я про то и говорю — шизофреники придумывали для других шизиков, а не для людей.

Ты же не все процитировал. Есть сценарии в которых такой уровень сложности является адекватным.
Если это проблема для твоего понимания, то это лишь твоя проблема.

Кстати тебя никто не заставляет все это использовать.

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

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

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


S>>>>Я вот ника кне догоню, нафига вводить раздельно понятия сервисов и приложений, когда сам ASP.NET прекрасно и без этого огорода слов живет и работает?
G>>>Service Applications позволяют частями масштабировать функциональность. например на серваках A и B работает excel services, а на B и C поиск. ASP.NET не позволяет все это делать, увы.

S>>Я про services и service applications. Нафига их вводить как отдельные понятия и иметь для них разный UI для запуска/останова — вот чего я никак не догоняю.

G>Вкратце так:
G>Сервис (SPService) — некоторый модуль функциональности типа "профили пользователей", "поиск" или "хранилище метаданных", то есть тип функциональности.
G>Сервис-приложение (SPServiceApplication) — логический экземпляр функциональности — конкретное хранилище метаданных, обычно имеет свою БД (разные ServiceApplication одного типа — разные БД).
G>Экземпляр сервиса (SPServiceInstance) — физический экземпляр функциональности на конкретном сервере. При этом "запуск" экземпляра на сервере создает веб-сервисы (реальные webapp на iis) для всех service applications данного типа.
G>Прокси сервис приложения (SPServiceApplicationProxy) — конкретный класс для обращения к service application, промежуточный класс нужен в первую очередь чтобы делать балансировку нагрузки, так как физически каждый service app имеет несколько экземпляров на разных серверах.

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

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

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

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

G>>>Реально переусложнено очень сильно

S>>Я про то и говорю — шизофреники придумывали для других шизиков, а не для людей.

G>Ты же не все процитировал. Есть сценарии в которых такой уровень сложности является адекватным.
G>Если это проблема для твоего понимания, то это лишь твоя проблема.

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

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

I>Для этого нужно знать (и судя по всему весьма неплохо знать) SML, Haskell и т.д. Причем, как я понимаю, мало прочитать книжку — нужно на нем что-то написать реальное.

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

Просто вопрос был "что такое монады понятно, не понятно зачем они нужны" — вот я и ответил.

I>Вы можете объяснить что такое монады, используя базовую терминологию языков типа C++/C#/Java? (можно вводить новые понятия, но каждое понятие должно быть подкреплено реальными практическими примерами)

Попробую. Допустим, код в основном состоит из методов, возвращающих результаты, у которых — в свою очередь — вызываются методы, в которые передаются другие результаты и т.д.

foo.Where(pred).Select(f).ToBar()

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

foo?Where(pred)?Select(f)?ToBar()

Но если подумать, вариантов проблемы может быть сколько угодно. Можно возвращать перечисление простых результатов, можно либо простой результат, либо объяснение, почему он не может быть получен, можно обещание вычислить простой результат в будущем, можно результат и какое-то промежуточное состояние, можно простой результат и недообработанные данные.
Вещи вроде бы разные и их обработка реализуются разными способами вроде вложенных if-ов, вложенных циклов, ожидания завершения всех потоков и т.д. но есть в них и что-то общее.
Короче говоря, есть группа функций такого вот общего вида

Func<Легко, НеВсеТак<Просто>>

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

Func<НеВсеТак<Легко>, НеВсеТак<Просто>>

и

Func<НеВсеТак<Легко>, Просто>

Производить методы первого вида из методов вида Func<Легко,Просто> можно единообразно, с помощью функторов, а собирать в конвееры методы второго вида можно с помощью комонад. Комонады не так популярны, как монады, потому, что практических применений у методов вида

Func<НеВсеТак<Легко>, Просто>

меньше, чем у

Func<Легко, НеВсеТак<Просто>>

Почему так происходит, думаю, понятно:
Из ЧтоТоПолезное всегда можно сделать ЧтоТоПолезное
либо Бесполезное (null) или СписокЧегоТоПолезного.
Но из Бесполезное Полезное всегда не сделать, как не всегда можно сделать его из пустого списка с полезным.

Короче говоря, для того, чтоб обобщенно работать со случаями Func<Легко, НеВсеТак<Просто>> нужно уметь писать функции с сигнатурой вида

НеВсеТак<Легко> СейчасВсеБудет<Легко, Просто, НеВсеТак>(this Легко x, Func<Легко, НеВсеТак<Просто>> f)

Камень преткновения здесь в выделенном. Такого система типов C# не позволяет. Для чего нам параметр типа, можно ведь унаследовать не все такое от НеВсеТак? Но это неудобно. Абстрагирование от конкретного "не всего такого" нам нужно только для устранения из кода обвязки, но сам код работает с конкретным не всем таким и пользуются конкретными свойствами и методами, которые для всех монад вовсе не общие. Т.е. мы абстрагировались как раз от того, что должно быть в основном коде — ради чего мы все и пишем. Следовательно, нам нужно обратно кастить вниз, к конкретному типу да еще и, чтоб не получить вместо лифта — гроб, а вместо холодильника — духовку, проверять каст в рантайме. Таким образом, мы снова получаем "обвязку", опутывающую код, на котором нам хотелось бы сконцентрироваться, иногда еще и похуже той, от которой только что избавились. Спрашивается, за что боролись?
В С# есть синтаксис для маскировки обвязки from x in xs from y in ys select f(x, y) , но особо значимого повторного использования кода тут не получить, ведь выделить такое выражение в обобщенную функцию нельзя:

?<ПрощеПростого> Lift<Легко, Просто, ПрощеПростого>(?<Легко> xs, ?<Просто> ys, Func<Легко, Просто, ПрощеПростого> f)
{
    from x in xs from y in ys select f(x, y)
}

Что мы тут вместо вопросительных знаков напишем?
Вот потому найти применение для монад в гибридных языка вполне можно, вот только широко использовать их на практике — нельзя.

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

K>Ну, это, по-моему, серьезное преувеличение. Ни серьезного знания этих языков, ни, тем более, серьезного опыта их применения тут не требуется.

K>Просто вопрос был "что такое монады понятно, не понятно зачем они нужны" — вот я и ответил.

Шота не понял твой предыдущий ответ

В той части, что я скипнул, понятно еще меньше чем в предыдущем ответе

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

P.S. В C# и jS применяю эти монады, а твои объяснения совершенно непонятны

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

DM>>В языках вроде C++ и Java ряд монад уже встроены. А хаскель просто такой примитивный и бедный язык, что там их забыли включить, приходится библиотечно решать те же задачи.

I>Ну вы же сами прекрасно понимаете что это не монады
I>Ладно, на следующей неделе я постараюсь собрать всю инфу по монадам и сделаю отдельную тему, в которой изложу свое (возможно ошибочное) видение. А вы, если захотите, меня поправите

Ну что, где эта следующая неделя ?

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

I>Шота не понял твой предыдущий ответ

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

I>P.S. В C# и jS применяю эти монады, а твои объяснения совершенно непонятны

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

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

K>Просто вопрос был "что такое монады понятно, не понятно зачем они нужны" — вот я и ответил.

Пока реального ответа на это не было. ) И кстати мне бы тоже хотелось увидеть хоть один реальный пример...

K>Попробую.
K>...

Жуть какая непонятная. ) Можно же гораздо проще. ))) Например если на C++:

Предположим что у нас есть 3 классические функции обычного вида:

bool read(string& s);
bool parse(const string& s, int& v);
void write(int v);

Мы можем написать классический код вида:

string s;
int v;
if(read(s)&&parse(s, v)) write(v);

И он будет отлично работать. Но можно попробовать намутить всякой фигни в функциональном стиле. Например взяв boost.optional в качестве структуры данных. Тогда добавив немного сахара типа:

template<typename R>
optional<R> F2O(bool (*f)(R& r))
{
    R r;
    return f(r)?optional<R>(r):optional<R>();
}
template<typename T, typename R>
optional<R> operator>>(optional<T> o, bool (*f)(const T&t, R& r))
{
    R r;
    return o&&f(*o, r)?optional<R>(r):optional<R>();
}
template<typename T>
void operator>>(optional<T> o, void (*f)(T))
{
    if(o) f(*o);
}

Мы сможем записать тот же самый тривиальный код в виде:

F2O(read)>>parse>>write;

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

Да, и пока это у нас ещё не монады, а просто функторы. Чтобы потребовались монады, у нас например функция parse должна оказаться изначально написанной под boost.optional. Т.е. иметь прототип вида:

optional<int> parse(const string& s)

Чтобы наш код продолжил работать и с такой функцией, нам надо будет добавить (хотя в данном случае можно и заменить им старый вариант) ещё один вариант оператора>>:

optional<R> operator>>(optional<T> o, optional<R> (*f)(const T&))
{
    return o?f(*o):optional<R>();
}

Это и будет та самая монада... Причём как видно, она даже проще чем обычные функторы.


K>Вот потому найти применение для монад в гибридных языка вполне можно, вот только широко использовать их на практике — нельзя.

Да легко оно всё делается на практике и здесь. Вот только польза крайне сомнительна...