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

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

K>>Да и в целом... братья-инжерены, вы что, серьёзно? Корёжить язык ради сиюминутных идей из "шаблонов проектирования"?

R>А впендюренный в язык SQL тебя устраивает? Он ведь тоже ради сиюминутных идей.

Не поверите, но я был и есть ПРОТИВ! Этот маразм не использую практически нигде.

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

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

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

K>>>Да и в целом... братья-инжерены, вы что, серьёзно? Корёжить язык ради сиюминутных идей из "шаблонов проектирования"?

R>>А впендюренный в язык SQL тебя устраивает? Он ведь тоже ради сиюминутных идей.

K>Не поверите, но я был и есть ПРОТИВ! Этот маразм не использую практически нигде.

И зря. Запросы проще писать, дебажить и поправлять именно в LINQ. Кто утверждает обратное вообще не понимает от чего отказывается.

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

R>>А впендюренный в язык SQL тебя устраивает? Он ведь тоже ради сиюминутных идей.

K>Не поверите, но я был и есть ПРОТИВ! Этот маразм не использую практически нигде.
А я очень часто и доволен!
Ибо Sql подобный синтаксис Linq в тех же группировках и соединениях намного удобнее

S>Ибо Sql подобный синтаксис Linq в тех же группировках и соединениях намного удобнее

Не сказал бы, что всегда. Но совсем не использовать — это конечно мазохизм.

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

S>>Ибо Sql подобный синтаксис Linq в тех же группировках и соединениях намного удобнее

Y>Не сказал бы, что всегда. Но совсем не использовать — это конечно мазохизм.

Вот у меня всегда, исключение разве что Pivot/Unpivot. Остальное на linq2db пишется с полпинка и SQL намного лучше ручного.

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


P>А не могли бы подсказать, в NET Core3 есть много полезного, к примеру,поддержка HTTP/2 в HttpClient, вместо class Http2CustomHandler : WinHttpHandler; быстрая встроенная поддержка JSON, т.е. не нужен пакет расширения; новый API System.Math и т.д.. Когда все это добавят в фреймворк, чтобы использовать в приложениях?

Никогда.
https://blog.ndepend.com/4-predictions-for-the-future-of-net/

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

A>>...
A>>2) А возвращаемый тип, который как раз полезен, задвинут куда-то подальше от имени функции, а то и вовсе опционален — иди сам ищи, что она возвращает.
ARK>Опять — типичная математическая нотация. Ну и не всегда возвращаемый тип полезен. Скажем, здесь "function (x: int) => x + 1" он не полезен, а вреден.

Вреден, когда это локальная лямбда какая-нибудь, у которой по окружающему коду понятно, с какими типами она имеет дело.

Когда же это "дикий" метод среди десятка других методов, и код внутри сложнее, чем x+1, то х.з. что он там возвращает и возвращает ли вообще. Писать удобно, читать нет. Затрудняет разбор кода. Хорошо, что указан тип параметра и понятно, что совать туда string нет смысла.

Если код не в сто строк на выброс, то в общем случае, по умолчанию типы параметров и результата у методов должны прописываться. Хорошо бы, чтоб язык к этому подталкивал. Если в каких-то особенных случаях удобнее не прописывать, вот для них можно придумывать особый краткий синтаксис. Так, в C# типы в лямбдах можно не писать и он обходится без двоеточий.

A>>1) Не несущее полезной нагрузки слово function (или его аналог) ставят на самом видном месте и оно обязательно.
ARK>Это слово несет полезную нагрузку — облегчает разбор кода и людьми, и компьютерами (https://stackoverflow.com/questions/15990084/why-does-rust-parser-need-the-fn-keyword).

А отсутствие типов затрудняет разбор кода и людьми, и компьютерам. Стоит ли затруднять разбор кода, убирая полезные типы, чтобы потом возвращать читаемость, добавляя новые ключевые слова?

ARK>Это обычная математическая нотация, поэтому, если возникает такое "ощущение", то это скорее плохо, чем хорошо.

У математиков свой отдельный мир. Там они могут и переменные обозначать одной буквой (а когда букв не хватает, то буквой с индексами в виде числа или другой одной буквы), и оформлять/форматировать как душе угодно, и даже картинки рисовать. Бумага стерпит.

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

D>Вот у меня всегда, исключение разве что Pivot/Unpivot. Остальное на linq2db пишется с полпинка и SQL намного лучше ручного.

Регулярно использую LINQ для обычных коллекций, никогда не использовал его для БД/SQL за отсутствием потребности.

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

S>>Ибо Sql подобный синтаксис Linq в тех же группировках и соединениях намного удобнее

Y>Не сказал бы, что всегда. Но совсем не использовать — это конечно мазохизм.

Есть премущество в let

var query1 = from person in persons
             let age = persons.Min(p => p.Age)
             where person.Age == age
             select person;

var query2 = persons
    .Select(person => new { person, age = persons.Min(p => p.Age) })
    .Where(a => a.person.Age == a.age)
    .Select(a => a.person);

Здравствуйте, Passerby, Вы писали:
P>А не могли бы подсказать, в NET Core3 есть много полезного, к примеру,поддержка HTTP/2 в HttpClient, вместо class Http2CustomHandler : WinHttpHandler; быстрая встроенная поддержка JSON, т.е. не нужен пакет расширения; новый API System.Math и т.д.. Когда все это добавят в фреймворк, чтобы использовать в приложениях?
Нет, это не канал об аниме.

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

S>Есть премущество в let

S>

S>var query1 = from person in persons
S>             let age = persons.Min(p => p.Age)
S>             where person.Age == age
S>             select person;

S>var query2 = persons
S>    .Select(person => new { person, age = persons.Min(p => p.Age) })
S>    .Where(a => a.person.Age == a.age)
S>    .Select(a => a.person);
S>

Делать квадратичную сложность там, где достаточно линейной — плохая демонстрация преимущества.

D>SQL намного лучше ручного.

Механический лучше ручного?
А что мешает ручной написать не хуже, чем механический?

A>Регулярно использую LINQ для обычных коллекций, никогда не использовал его для БД/SQL за отсутствием потребности.

Никогда нет потребности в БД/SQL?

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

A>>Регулярно использую LINQ для обычных коллекций, никогда не использовал его для БД/SQL за отсутствием потребности.
Y>Никогда нет потребности в БД/SQL?

Про энтерпрайз я ничего не знаю, про веб тоже, бэкенд для MMORPG не писал. Разве что, помню, нужно было сделать быстрый отчёт по данным из левой БД, но там была такая стрёмная структура, что было проще прочитать записи за последние N дней и всю логику выполнить на клиенте.

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

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

S>>Есть премущество в let

S>>

S>>var query1 = from person in persons
S>>             let age = persons.Min(p => p.Age)
S>>             where person.Age == age
S>>             select person;

S>>var query2 = persons
S>>    .Select(person => new { person, age = persons.Min(p => p.Age) })
S>>    .Where(a => a.person.Age == a.age)
S>>    .Select(a => a.person);
S>>

S>Делать квадратичную сложность там, где достаточно линейной — плохая демонстрация преимущества.

Ну в SQL ных запросах это как раз самый верный запрос, никакой квадратичности нет и все в одном запросе. Для коллекций тоже не вижу квадратичности ибо
let age = persons.Min(p => p.Age) может вычисляться заранее.

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

D>>SQL намного лучше ручного.

Y>Механический лучше ручного?
Y>А что мешает ручной написать не хуже, чем механический?

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

У вас 10000 записей с двумя или больше полями в классах. Все это в памяти.

class SomeValue
{
    int Id1;
    int Id2;
    int Id3;
}

Теперь нужно выбрать то, что удволетворяет ихнему ключу из реальной базы. Хочется джоин, но на что?
Для этого в linq2db есть срества для создания временных таблиц и очень скоростной вставки в них:

List<SomeValue> someValues = ...
using (var tempTable = db.CreateTempTable("#keys", someValues))
{
    var query = 
        from a in db.GetTable<AnyTable>()
        from t in tempTable.InnerJoin(t => t.Id1 == a.Id && t.Id2 == a.OtherId && t.Id3 == a.ThirdId)
        select a;

    // инкрементировать одно поле и проставить текущую дату изменения
    query.
        Set(q => q.Value,        q => q.Value + 1)
        Set(q => q.ModifiedDate, q => Sql.CurrentTimestamp)
        .Update();

    // или удалить к черту
    query.Delete();
}

Если вы поняли описанное, скажите, вы можете это сделать чистым SQL и сколько будет на это потрачено ресурсов?

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

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

S>>Делать квадратичную сложность там, где достаточно линейной — плохая демонстрация преимущества.

S>Ну в SQL ных запросах это как раз самый верный запрос, никакой квадратичности нет и все в одном запросе.
Это особенности провайдера Linq2Sql

S> Для коллекций тоже не вижу квадратичности ибо
S>let age = persons.Min(p => p.Age) может вычисляться заранее.
В принципе может. Но конкретно Linq2Objects так не умеет и вряд ли когда-нибудь будет уметь.

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

S>Делать квадратичную сложность там, где достаточно линейной — плохая демонстрация преимущества.

И где тут квадратичная вместо линейной?

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

K>Не поверите, но я был и есть ПРОТИВ! Этот маразм не использую практически нигде.

Хорошо, что разработчики языка забили тебя спросить.

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

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

S>>Делать квадратичную сложность там, где достаточно линейной — плохая демонстрация преимущества.

IT>И где тут квадратичная вместо линейной?
Нехитрые правила рассахаривания let помещают вычисления в код Select-а, что заставляет родной Linq to objects выполнять вычисление Min для каждого элемента коллекции persons. Именно это делает сложность вычисления квадратичной (подчеркиваю, в рамках linq to objects).

Получить тот же результат можно с помощью вычисления линейной сложности. Например, с помощью Aggregate. Но это не будет красиво транслироваться в SQL.