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

ГВ>>Коллизия между вопросами "зачем оно" и "что оно из себя представляет"...
VD>Так. Давай как с чистого листа начнем. ОК?

Попробуем.

VD>Итак. Вот цитата Гапертона относительно ЛИНК:
VD>

VD>LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.

VD>Теперь я задам несколько вопросов, а ты постараешься на них дать честный вопрос и не уйти в сторону. ОК?
VD>Принимаются ответы: "нет", "да" и "не знаю".

VD>1. Можно ли с помощью линк обрабатывать коллекции в памяти.

Да.

VD>2. Можно ли с помощью линка обрабатывать ХМЛ.

Да.

VD>3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?

Я таких не припомню, во всяком случае. Хотя LINQ и получен обобщением проблем взаимодействия с РСУБД. Начиная от использования самого устоявшегося термина "запрос" до Expression Trees, которые хороши для (внимание!) трансляции в SQL-запросы (исчисление кортежей, ограниченные агрегаты). Кроме того, насколько я понимаю, возможности LINQ по обработке агрегатов и вложенных запросов должны быть несколько уже, чем у SQL Server. Но здесь надо покопаться плотнее в способностях самого SQL Server, я уж около года этим не занимался. Возможно, что будут заморочки с having или где-то в районе вложенных запросов.

VD>4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?

По сравнению с какими?

Но. См. ответ на следующий вопрос.

VD>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?

Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?

Вот ещё пара встречных вопросов:

1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?

2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.

Как ты понимаешь, традиционным for обе задачи решаются тривиально.

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

ГВ>Вот ещё пара встречных вопросов:

ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?

int lastNdx = int.MinValue;
var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
        return false;
    } else {
        lastNdx = i;
        return true;
    }
}).Select(i => arr[i]);

ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.

var q2 = arr.Where(n => q1.Contains(n - 1) || q1.Contains(n + 1));

ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.

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

ГВ>Кроме того, насколько я понимаю, возможности LINQ по обработке агрегатов и вложенных запросов должны быть несколько уже, чем у SQL Server.

Шире, Гена, значительно шире.

ГВ>Возможно, что будут заморочки с having или где-то в районе вложенных запросов.

Where либо раскладывается на Having и Where, либо запрос оборачивается в подпзапрос при невозможности это сделать. Linq 2 SQL, например, не заморачивается и всегда идёт вторым путём.

ГВ>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?

ГВ>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.

Ты про это что ли?

var arr  = new[] { 1, 2, 3, 7, 8, 9, 10 };
var list = new List<int>();
Func<int,bool> func = i => { list.Add(i); return true; };

var q1 =
    from a in arr.Select((n, i) => new { i, n })
    let prev = a.i - 1
    where
        prev >= 0 && a.n - 1 == arr[prev] && !list.Contains(prev) && func(a.i)
    select new { a.i, n = arr[a.i] };

foreach (var p in q1)
    Console.Write("{0} ", p.n);

var q2 =
    (from i in q1 select arr[i.i - 1]).
    Union(
    (from i in q1 where i.i + 1 < arr.Length select arr[i.i + 1])).
    OrderBy(i => i);

foreach (var p in q2)
    Console.Write("{0} ", p);

ГВ>Как ты понимаешь, традиционным for обе задачи решаются тривиально.

Да оно и так как бы ничего

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

G>>По-простому, это без ФВП и линков.

IT>Что плохого в ФВП, если они позволяют упрощать и угибчать код?

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

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

ГВ>>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?

L>

L>int lastNdx = int.MinValue;
L>var q1 = Enumerable.Range(1, arr.Length - 1).Where(i => {
L>    if (i == lastNdx + 1 || arr[i] != arr[i - 1] + 1) {
L>        return false;
L>    } else {
L>        lastNdx = i;
L>        return true;
L>    }
L>}).Select(i => arr[i]);
L>

Хорошо, но не надёжно из-за "Enumerable.Range(1, arr.Length — 1)" — свалится при arr.Length == 0;

ГВ>>2) Тот же массив, но нужно извлечь элементы, отстоящие на +/-1 от выбранного. Т.е. результат — {1, 3, 7, 9}.

L>

L>var q2 = arr.Where(n => q1.Contains(n - 1) || q1.Contains(n + 1));
L>

Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.

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

G>>Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.

IT>Я тебе демонстрировал не силу линка, а его использование без БД.

...Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.

IT>Или ты теперь с БД решил переключиться на силу?

Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.

IT>Думаю, в твоём исполнении это уже никому не будет интересно.

А вот твое мнение об этом меня интересует как-то совсем мало. Какая разница, что ты там себе думаешь.

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

[skip]

ГВ>>Как ты понимаешь, традиционным for обе задачи решаются тривиально.
IT>Да оно и так как бы ничего

Кхм. Подожду пока со своим мнением, может, ещё кто что подкинет. Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.

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

Ответа явно не будет. Что и требовалось доказать.
Слив засчитан. Больше я на твой тролинг попадаться не буду.

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

ГВ>Хорошо, но не надёжно из-за "Enumerable.Range(1, arr.Length — 1)" — свалится при arr.Length == 0;

Enumerable.Range(0, arr.Length).Skip(1)

ГВ>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.

Это еще проще.

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

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

VD>Ответа явно не будет. Что и требовалось доказать.
VD>Слив засчитан. Больше я на твой тролинг попадаться не буду.

Влад. Ты сам себе отвечаешь.

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

L>Влад. Ты сам себе отвечаешь.

Естественно. А как еще можно ответить на смайлик вместо ответа?

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

L>>Влад. Ты сам себе отвечаешь.
VD>Естественно. А как еще можно ответить на смайлик вместо ответа?

Да я так, поржать, забей.

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

IT>>Что плохого в ФВП, если они позволяют упрощать и угибчать код?
G>В ФВП, как в выразительном средстве — совершенно ничего плохого. Но решение без ФВП при прочих равных проще понимать. Во многих случаях.

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

Автор: IT
Дата: 22.09.08

я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.

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

IT>>Или ты теперь с БД решил переключиться на силу?

G>Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.

Ещё раз повторюсь. Я тебе демонстрировал не значимость, а возможность использовать Linq без БД, т.е. способности в которых ты очень сильно сомневаешься. На значимость я тебе дал ссылку в предыдущем посте, вот она

Автор: IT
Дата: 22.09.08

ещё раз. Перепиши это на Go ради забавы, а мы все вместе полюбуемся.

IT>>Думаю, в твоём исполнении это уже никому не будет интересно.
G>А вот твое мнение об этом меня интересует как-то совсем мало. Какая разница, что ты там себе думаешь.

Меня мало волнует интересует тебя моё мнение или нет. И мне нет никакой разницы, что ты там себе думаешь о том, что я там себе думаю.

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

ГВ>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.

Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?

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

G>>Я тебе показал, как обозначенная тобой в примере проблема решается без линка, на примере Go. Значимой разницы я не вижу. Пример, я так полагаю, ты выбрал не совсем удачный.

IT>Ещё раз повторюсь. Я тебе демонстрировал не значимость, а возможность использовать Linq без БД, т.е. способности в которых ты очень сильно сомневаешься.

Я не сомневаюсь в возможности использовать Linq без БД. Кстати, твой пример выше мне понравился — он вполне симпатичен. Я правда не понял, зачем огород городить ради такой простой и симпатичной штуки, когда для нее достаточно "ортогональности" системы типов, как в Go.

В чем я действительно сомневаюсь — это в том, что Linq проявляет себя в полную силу в классе приложений, отличном от того, где у тебя в бэкенде стоит реляционная БД. Мне кажется, что его настоящий killing application — это приложения с реляционным источником.

IT>На значимость я тебе дал ссылку в предыдущем посте, вот она

Автор: IT
Дата: 22.09.08

ещё раз. Перепиши это на Go ради забавы, а мы все вместе полюбуемся.

Это по своей природе типичная "реляционная" задача. И это весьма показательно, что силу linq ты предпочел демонстрировать на ней.

Работая с Go, я просто заверну это в хранимую процедуру, как делал еще в 90-х, и выиграю в производительности, одновременно абстрагировавшись от схемы БД. И все.

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

IT>>>Что плохого в ФВП, если они позволяют упрощать и угибчать код?
G>>В ФВП, как в выразительном средстве — совершенно ничего плохого. Но решение без ФВП при прочих равных проще понимать. Во многих случаях.

IT>В данном случае простота напрямую зависит от уровня подготовки. Не секрет, что один и тот же код для одного человека может быть простым, а для другого сложным. Это как раз тот самый случай. Вот тут

Автор: IT
Дата: 22.09.08

я давал пример одного и того же алгоритма на Linq и в императивном стиле. Разница очевидна. ФП привносит в код декларативность, а значит простоту и гибкость. Но всё это требует определённой подготовки.

Этот пример из мира типовых задач, в которых применяют БД. На нем — разумеется, разница очевидна.

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

IT>>>Думаю, в твоём исполнении это уже никому не будет интересно.

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

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

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

IT>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Вторая задача, кстати, тоже не совсем правильно решена — из-за Union могут быть проглочены соседние элементы, например на вот таком массиве { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 } ответ получается {1, 3, 4}, а должен быть как минимум {1, 3, 3, 4}.

IT>Я задачу понял именно так. Для твоего уточнения достаточно заменить Union на Cancat. И что значит выделенное, первая задача решена не правильно?

Первая задача решена может и правильно, но однозначно чудовищно.

Зато вторая — неиллюзорно доставляет. Заставляет меня вспомнить молодые годы, когда мы по неопытности любили использовать SQL весьма необычным способом. Так, что читателей бросало в дрожь. Помню, когда мой первый начальник увидел мой первый "промышленный" SQL-запрос, он после этого наотрез отказался изучать SQL. И никто так и не смог его переубедить.

В общем, так держать!

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

ГВ>>Компактно, но не правильно. Я имел в виду соседей выбранного элемента. В прочем, я не совсем удачно сформулировал вторую задачу.

L>Это еще проще.

Так покажи.

У тебя в целом код лучше, чем у IT. Первый пример, правда, по очевидной причине проигрывает циклу (ибо ты изображаешь цикл), но давай понадеемся на второй.