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

M>>О чём я имею "весьма смутное и отдалённое понятие"?

VD>О LINQ.

VD>Подписываюсь под каждым словом IT.

VD>Несешь полную чушь и еще сейчас спорить начнешь.

С тобой спорить не буду, ибо полезной информации из спора с тобой круглый ноль, зато оскроблений целая куча.

VD>И ладно бы спорили и несли чушь ламеры. Так даже, казалось бы, весьма продвинутые товарищи вроде Гапертона в этот процесс включаются.

VD>Господа. Не выставляйте себя на людях ламерами. Изучайте то что пытаетесь обсуждать!

Господин, читай посты на которые пытаешься отвечать!

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

VD>>Несешь полную чушь и еще сейчас спорить начнешь.

M>С тобой спорить не буду, ибо полезной информации из спора с тобой круглый ноль, зато оскроблений целая куча.

И тем не менее, он прав, вы даже поверхностно не знакомы с LINQ-ом.

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

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

M>>О чём я имею "весьма смутное и отдалённое понятие"? О промышленной разработке "типичных" проектов? Не соглашусь. О LINQ? Пожалуй да. Ну дык в том виде в каком её подают я не вижу ей применения для своих задач. Ниже типичный пример использования LINQ. Вот скажите, вам в самом деле часто приходится работать с такими ArrayList'ами? Как правило же все эти данные лежат в БД и дергаются либо тем же SQL, либо HQL.
0>Вот у меня совсем недавно был свой "пример использования linq" — я писал свой кастомный XML-сериализатор для одного проектика. Итерирование по метаданным, их обработка и так и сяк, отображение самих данных объектов — все это типичные задачи для Linq, и, заметь, с СУБД рядом не лежат.
И получилось сильно проще чем с помощью XPath? Или это рассчет на будущий переезд на СУБД?

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

M>И получилось сильно проще чем с помощью XPath? Или это рассчет на будущий переезд на СУБД?
Хм.
Стояло две задачи:
1. Из графа объектов произвольных классов, отдекорированных правильными атрибутами, построить дерево однотипных Data-Transfer-Object`ов. Основная засада, понятное дело, в разруливании циклических ссылок.
2. Сброс полученного дерева в поток. Сейчас реализован XML, но это, собственно, деталь реализации.
И потом в обратном порядке.

XPath применим только для п.2 при загрузке данные. Маппинг данных из объектов в дерево DTO и обратно не имеет никакого отношения к XML. Там стояла другая задача: рекурсивно обойти граф объектов, вытащить их каждого объекта метаданные по полям/свойствам, сами данные, метаданные, руководящие порядком отображения, и все это благолепие отобразить в дерево. В классе, который этим знанимается из 13 методов 11 — инкапсулированные linq-выражения.

Но это половина истории. Дело в том, что код в подобном виде у меня получился только после двух рефакторингов. Первоначально этот же код был написан в более традиционном духе, с foreach`ами, ручным перекладыванием объектов из коллекции в коллекцию и т.п. Сравнение первоначального варианта и конечного однозначно говорит в пользу реализации на linq, поскольку она получилась короче и прозрачнее (для тех, конечно, кто linq знает).

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

T>Вы имели в виду иное, но получилось очень точно. Супер-пупер-опупенную фиговину надо подавать, да. Потому что она даже называется сложно, очевидно, что объяснение "зачем она нужна" займёт уйму времени. Простые в использовании вещи, которые просто упрощают жизнь, не требуя ничего взамен, не требуют и рекламы. Например, оптимизации компилятора, вывод типов, лямбды.
Если оптимизацию люди еще понимают то вывод типов и лямбды приходится объяснять.
Можешь поискать в форуме .NET там были войны на тему того что var (это такой недоделанный вывод типов) испортит читаемость кода на корню...
А если вывод типов хотябы как у немерле то там народ просто впадает в ступор и не понимает как это может работать.

А что с народом происходит при виде мощьных макросов

А сколько сил понадобится на то чтобы объяснить массам зависимые типы я и представить боюсь. У народа они просто в голове не удерживаются причем даже если объясняешь без матана.

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

T>SQL провалился?

Это скорее декларативное программирование.

T>>SQL провалился?

V>Это скорее декларативное программирование.

Да, ваша правда. А вы можете провести чёткую грань между функциональным и декларативным программированием?

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

M>Я в промышленном программировании уже 2 года как не появлялся, так что мои представления могут быть несколько устаревшими. Но если взять "типичный" проект с SQL БД, то действительно не очень понятно зачем мне ещё и LINQ. Ведь практически все объекты с которыми я работаю, лежат в БД и оттуда их можно спокойно выдернуть SQL запросом, который отработает на сервере, который всё соптимизирует, закэширует и т. д. Зачем мне самому держать коллекции, к которым потом обращаться через заново изобретенный SQL и не забывать синхронизировать с базой? Нет, конечно иногда приходится, но не так часто, и этого лучше избегать.

То, что вы хотите сказать вполне разумно, но. Не базой данных единой жив программист. Я не буду строить из себя мега-математика и эксперта по теории множеств, а скажу с точки зрения обычного разработчика. LINQ это мега удобно при работе с коллекциями. Например, там где обычно надо написать несколько вложенных циклов и задействовать несколько промежуточных переменных LINQ позволяет обойтись одним запросом или простой цепочкой вызовов (кому как нравится).
Код получается короче и понятней (проверено). Свободы больше: хочу циклы пишу, хочу запросы. Как проще и понятней получается тот способ и выбираю.

Примерно так. Никакого фанатизма, чистый прагматизм.

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

0>Добрый день.

0>По опыту своих бесед с программистами, не знакомыми с linq, я собрал ряд стереотипных заблуждений и проблем с пониманеим linq, которые у них встречаются. В целом среди них преобладает такое мнение "это убогий SQL в С#, зачем он нужен?". Все попытки объяснить, что linq является воплощением аппарата операций над множествами, который ортогонален языку, и с необходимостью которого никто не спорит, сталкиваются с такой стеной непонимания. Это приводит меня к мысли, что linq подан неудачно. Его SQL-подобный синтаксис вызывает затруднения и у тех кто не знаком с SQL (выглядит больно непривычно) и у тех, кто знаком (не совсем понимают, что SQL делает в языке и сталкиваются с тем, что синтаксис всего лишь похож, а не повторяет SQL). Мое мнение по этому поводу: Linq — хорошая штука, но неудачно подан. Ваши мнения?

А вот встречный вопрос: владея примитивами compose/map/fold/filter/zip/cons я могу прекрасно (и достаточно компактно) решить встающие задачи (в т.ч. и те, что были указаны в топике — про графы, коллецкии и циклы) без применения linq, причем начиная с рамок .net 2.0. Стоит ли мне этот самый linq использовать или даже изучать? В чем профит (м.б., кроме расхода железных ресурсов), так сказать?

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

M>О чём я имею "весьма смутное и отдалённое понятие"? О промышленной разработке "типичных" проектов? Не соглашусь. О LINQ? Пожалуй да. Ну дык в том виде в каком её подают я не вижу ей применения для своих задач. Ниже типичный пример использования LINQ. Вот скажите, вам в самом деле часто приходится работать с такими ArrayList'ами? Как правило же все эти данные лежат в БД и дергаются либо тем же SQL, либо HQL.

public class Student
{
    public int    StudentID { get; set; }
    public string FirstName { get; set; }
    public string LastName  { get; set; }

    [Association(ThisKey = "StudentID", OtherKey = "StudentID")]
    public Score[] Scores { get; set; }
}

public class Score
{
    public int StudentID { get; set; }
    public int Value     { get; set; }
}

public class StudentDB : DbManager
{
    public Table<Student> Student { get { return GetTable<Student>(); } }
}

static void Test()
{
    using (var db = new StudentDB())
    {
        var query =
            from Student student in db.Student
            where student.Scores.FirstOrDefault().Value > 95
            select student;

        foreach (Student s in query)
            Console.WriteLine(s.LastName + ": " + s.Scores[0]);
    }
}

Генерируемый SQL (Sybase):

SELECT
    [student].[StudentID],
    [student].[FirstName],
    [student].[LastName]
FROM
    [Student] [student]
WHERE
    (
        SELECT
            [t1].[Value]
        FROM
            [Score] [t1]
        WHERE
            [student].[StudentID] = [t1].[StudentID]
    ) > 95

Ещё вопросы?

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

IT>Генерируемый SQL (Sybase):

IT>

IT>SELECT
IT>    [student].[StudentID],
IT>    [student].[FirstName],
IT>    [student].[LastName]
IT>FROM
IT>    [Student] [student]
IT>WHERE
IT>    (
IT>        SELECT
IT>            [t1].[Value]
IT>        FROM
IT>            [Score] [t1]
IT>        WHERE
IT>            [student].[StudentID] = [t1].[StudentID]
IT>    ) > 95
IT>

IT>Ещё вопросы?

Без TOP 1?

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

IT>>

IT>>SELECT
IT>>    [student].[StudentID],
IT>>    [student].[FirstName],
IT>>    [student].[LastName]
IT>>FROM
IT>>    [Student] [student]
IT>>WHERE
IT>>    (
IT>>        SELECT
IT>>            [t1].[Value]
IT>>        FROM
IT>>            [Score] [t1]
IT>>        WHERE
IT>>            [student].[StudentID] = [t1].[StudentID]
IT>>    ) > 95
IT>>

IT>>Ещё вопросы?

L>Без TOP 1?

Он в Sybase в подзапросах не поддерживается (будет ошибка сервера). Для вменяемых провайдеров будет, конечно, TOP 1.

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

L>>Без TOP 1?

IT>Он в Sybase в подзапросах не поддерживается (будет ошибка сервера). Для вменяемых провайдеров будет, конечно, TOP 1.

Гм. А какой результат будет, если записей вернется больше 1-й.
SQL Server вроде как ругается.

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

L>>Без TOP 1?

IT>Он в Sybase в подзапросах не поддерживается (будет ошибка сервера). Для вменяемых провайдеров будет, конечно, TOP 1.

За что оценка-то? Я баг что-ли нашел?

T>>Вы имели в виду иное, но получилось очень точно. Супер-пупер-опупенную фиговину надо подавать, да. Потому что она даже называется сложно, очевидно, что объяснение "зачем она нужна" займёт уйму времени. Простые в использовании вещи, которые просто упрощают жизнь, не требуя ничего взамен, не требуют и рекламы. Например, оптимизации компилятора, вывод типов, лямбды.
WH>Если оптимизацию люди еще понимают то вывод типов и лямбды приходится объяснять.
WH>Можешь поискать в форуме .NET там были войны на тему того что var (это такой недоделанный вывод типов) испортит читаемость кода на корню...

Чёрт знает. Лично я вижу даже убогий var примерно так:
было (забиваем деревянные гвозди руками) "Map <String, ClientInfo> found = (expr)",
стало (взяли в руки киянку) "var found = (expr)".

Т.е. просто бесплатное улучшение жизни. Как это работает объяснять не надо.

Если люди уж и в этом видят проблемы да препятствия и при этом они не тролли, не PHP-шники в душе, то, видимо, вывод типов ещё пока не относится к общепризнанным благам. Увышка.

В любом случае, неблагодарное это дело — объяснять что-то массам. По-моему, пусть лучше 10 человек понимают и используют LINQ, чем тысяча будет ворчать, что это недоSQL и он не нужен.

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

T>Чёрт знает. Лично я вижу даже убогий var примерно так:
T>было (забиваем деревянные гвозди руками) "Map <String, ClientInfo> found = (expr)",
T>стало (взяли в руки киянку) "var found = (expr)".

T>Т.е. просто бесплатное улучшение жизни. Как это работает объяснять не надо.

Это улучшения для разработки, но ухудшения для поддержки. А поддержка, как известнно, занимает гораздо больше времени и денег. И где тогда выигрышь?

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

L>Гм. А какой результат будет, если записей вернется больше 1-й.
L>SQL Server вроде как ругается.

Sybase тоже заорёт. Здесь вопрос в принципе заключается не в Linq, а в сервере БД. Если есть способ сгенерировать рабочий SQL для данного запроса для Sybase, то мы можем это сделать.

На самом деле здесь ещё под вопросом сам пример. Может лучше написать так:

var query =
    from Student student in db.Student
    where student.Scores.Max(s => s.Value) > 95
    select student;

Тогда получится вполне рабочий SQL даже для Sybase;

SELECT
    [student].[StudentID],
    [student].[FirstName],
    [student].[LastName]
FROM
    [Student] [student]
WHERE
    (
        SELECT
            Max([t1].[Value])
        FROM
            [Score] [t1]
        WHERE
            [student].[StudentID] = [t1].[StudentID]
    ) > 95

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

L>За что оценка-то? Я баг что-ли нашел?

За меткий глаз

T>>Чёрт знает. Лично я вижу даже убогий var примерно так:
T>>было (забиваем деревянные гвозди руками) "Map <String, ClientInfo> found = (expr)",
T>>стало (взяли в руки киянку) "var found = (expr)".

T>>Т.е. просто бесплатное улучшение жизни. Как это работает объяснять не надо.

L>Это улучшения для разработки, но ухудшения для поддержки. А поддержка, как известнно, занимает гораздо больше времени и денег. И где тогда выигрышь?

Допустим, что это упрощение разработки, но я продемонстрировал в чём именно улучшение.
Если без демонстрации, то хотя бы объясните в чём ухудшение поддержки?

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

L>>Это улучшения для разработки, но ухудшения для поддержки. А поддержка, как известнно, занимает гораздо больше времени и денег. И где тогда выигрышь?

T>Допустим, что это упрощение разработки, но я продемонстрировал в чём именно улучшение.
T>Если без демонстрации, то хотя бы объясните в чём ухудшение поддержки?

Это же очевидно: меньше информации выражено явно => сложнее разбираться.