Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Например вот это дублирование — 1, 2 — из-за БД? НС>Глупо задавать вопросы, на которые тебе давно уже дали ответы. Это дублирование из-за того, что для ref-типов есть выделенное значение null, а для value его нету.
Глупо отвечать на вопрос, даже не прочитав его.
Придётся разжёвывать: сходи по ссылкам 1 и 2, сравни код и найди одно отличие, а теперь попробуй объясни именно это дублирование наличием ref-типов
НС>для ref-типов есть выделенное значение null, а для value его нету.
Это в том числе тоже является недостатком.
EP>> А может быть вот этот мрак из-за БД? НС>А это для лучшего перформанса.
Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений. Был бы язык/платформа/компилятор мощнее — его бы и не пришлось писать, о чем собственно и речь.
НС>Ну и вообще — это тот самый код, который пишется в универсальных библиотеках и почти не пишется в прикладном коде.
Так я и говорю про алгоритмы, а не какой-нибудь опердень.
НС>Но аналогичная ситуация с чудовищной кашей в твоей шаблонной магии тебя почему то устраивает, а тут прям какая то вселенская проблема и ужас ужас.
Вот что-что, а передёргивать у вас всех здорово получается
Шаблонная магия нужна для реализации EDSL запросов времени компиляции, дающего zero overhead.
Для обсуждаемого простейшего алгоритма поиска минимального/максимального элемента никакой магии не нужно.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это в том числе тоже является недостатком.
Этот "недостаток" есть везде, где есть value типы.
НС>>А это для лучшего перформанса. EP>Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений.
Практические соображения и алгоритмическая выразительность это разные вещи. Алгоритмически все это можно было бы уложить в один небольшой метод.
EP> Был бы язык/платформа/компилятор мощнее — его бы и не пришлось писать, о чем собственно и речь.
Мощность штука не скалярная. Везде есть трейд-офф. Мощность текстовых шаблонов, к примеру, компенсируется отсутствием этих шаблонов в рантайме.
НС>>Но аналогичная ситуация с чудовищной кашей в твоей шаблонной магии тебя почему то устраивает, а тут прям какая то вселенская проблема и ужас ужас. EP>Вот что-что, а передёргивать у вас всех здорово получается EP>Шаблонная магия нужна для реализации EDSL запросов времени компиляции
Далеко не только. Еще недавно она была нужна даже для таких базовых вещей как лямбды. И для плохонького аналога анонимных типов она понадобилась. Причем ее не хватило в итоге, и пришлось допиливать при помощи макросов препроцессора.
EP>Для обсуждаемого простейшего алгоритма поиска минимального/максимального элемента никакой магии не нужно.
Ты обсуждаешь простейший алгоритм на С++ с его конкретной реализацией для дотнета, содержащей кучу подробностей, связанных со спецификой платформы. Это самая натуральная демагогия. Интересно сравнение алгоритмической выразительности — так возьми тогда чистый алгоритм, в чем проблема? Или давай вспомним, что куча плюсовых OR/M вообще не поддерживают NULL в value колонках, видать из-за крутой алгоритмической выразительности.
Re[177]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>> А может быть вот этот мрак из-за БД? НС>>А это для лучшего перформанса.
EP>Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений. Был бы язык/платформа/компилятор мощнее — его бы и не пришлось писать, о чем собственно и речь.
будет одинаков.
Ты так и не нписал аналог на C++.
И посмотрим разницу в 100 раз.
А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы?
и солнце б утром не вставало, когда бы не было меня
Re[178]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А это для лучшего перформанса. EP>>Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений. НС>Практические соображения и алгоритмическая выразительность это разные вещи. Алгоритмически все это можно было бы уложить в один небольшой метод.
Номинально да, на практике же имеем совсем не номинальный boilerplate.
НС>>>Но аналогичная ситуация с чудовищной кашей в твоей шаблонной магии тебя почему то устраивает, а тут прям какая то вселенская проблема и ужас ужас. EP>>Вот что-что, а передёргивать у вас всех здорово получается EP>>Шаблонная магия нужна для реализации EDSL запросов времени компиляции НС>Далеко не только. Еще недавно она была нужна даже для таких базовых вещей как лямбды.
"Недавно" это уже лет шесть как назад. И это всё же передёргивание.
НС>И для плохонького аналога анонимных типов она понадобилась. Причем ее не хватило в итоге, и пришлось допиливать при помощи макросов препроцессора.
Каких конкретно макросов? Тех что используются для определения таблицы? Так там необязательно макросы использовать, можно и текстовую кодогенерацию — всё равно нужно же как-то состоковывать со схемой БД — также как и в Linq2DB
EP>>Для обсуждаемого простейшего алгоритма поиска минимального/максимального элемента никакой магии не нужно. НС>Ты обсуждаешь простейший алгоритм на С++ с его конкретной реализацией для дотнета, содержащей кучу подробностей, связанных со спецификой платформы. Это самая натуральная демагогия.
На C++ из всей "специфики платформы" к этому алгоритму будет несколько десятков строк врапперов для Range интерфейсов, о чём я сразу и сказал. Но это же никак не сотни + текстовая кодогенерация.
НС>Или давай вспомним, что куча плюсовых OR/M вообще не поддерживают NULL в value колонках, видать из-за крутой алгоритмической выразительности.
Причём тут ограничения каких-то левых OR/M и простейший алгоритм?
Re[169]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Есть задача реализовать алгоритм под реальную практическую задачу, при реализации приходится делать много лишних движений, повторятся, генерировать код как текст и т.п. — это плохо, I>>А что плохо ? Код писать твоя работа.
EP>Конечно плохо, но некоторые действительно так и пишут целые простыни, от забора и до обеда
Если твоя работа экономически целесообразна, то пиши хоть сотни миллионов строчек в день.
I>>А вот экономический эффект и показывает, что хорошо, а что плохо.
EP>Это уже передёргивание с алгоритмической выразительности на сферический экономический эффект.
У тебя хорошо-плохо меряется в абстрактных попугаях, поскольку ты смешиваешь целых три аспекта в один — платформу, компилятор и язык. Такая синкретичность хороша для вчерашних студентов, а вот в инженерии принято разделять аспекты. Я, например, твои хорошо-плохо не понимаю.
У меня хорошо-плохо это исключительно экономический аспект.
Вообще, у тебя очень селективный подход. Когда удобно, ты напираешь на чистую математику. А когда удобно другое — подмешиваешь к этому и язык и платформу.
Re[177]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений. Был бы язык/платформа/компилятор мощнее — его бы и не пришлось писать, о чем собственно и речь.
Что надо изменить в языке, какую языковую фичу, что бы решить проблему ?
Re[177]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>для ref-типов есть выделенное значение null, а для value его нету.
EP>Это в том числе тоже является недостатком.
Спасибо, капитан ! Мы не знали, что ты откроешь нам глаза в 2016, обнаружили это на 15 лет раньше.
Re[178]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Serginio1, Вы писали:
S> А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы?
Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо
Re[179]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>> А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы?
EP>Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо
Ты еще на ассемблере пиши. Каждый извращается как хочет. Я же тебя за это не осуждаю. А ты нашел извращенцев и на их извращениях делаешь выводы.
Еще раз напомню тебе про количество 1С ников. Сейчас в основной массе никому не нужны нулевые накладные расходы. Нужна надежность и скорость разработки. А у кого куча свободного времени может извращаться так как ему хочется. Но вот делать выводы на их коде вообще то не стоит.
- Так мне Паваротти не понравился, картавит, в ноты не попадает...
— Вы были на концерте Паваротти?
— Нет, мне Рабинович по телефону напел.
Нужно сначала изучит предметную область, а не просто критиковать, а говорить что и как можно улучшить. Простое критиканство никому не интересно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>А ты нашел извращенцев и на их извращениях делаешь выводы.
Слушай, ты уже в очередной раз наезжаешь на авторов CodeJam — то говоришь что у них "недостаток в мозгах", то "мухи в голове", то вот извращенцами называешь. Делаешь это всё за спиной — твои сообщения в этой теме они могут и не читать. Не хорошо
Ты им это всё в соответствующем подфоруме распиши, я твоё мнение уже услышал, и мне это в общем-то не интересно.
S>Еще раз напомню тебе про количество 1С ников.
Смотри количество продавцов
Re[179]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>> А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы?
EP>Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо
Да можно, только это никому не нужно. Разберись в предметной области.
Еще раз в старых версиях Linq to EF были Скомпилированные запросы. https://msdn.microsoft.com/ru-ru/library/bb896297(v=vs.110).aspx
Класс CompiledQuery обеспечивает компиляцию и кэширование запросов для повторного использования. Концептуально данный класс содержит метод CompiledQueryCompile с несколькими перегрузками. Вызовите метод Compile, чтобы создать новый делегат, для представления скомпилированного запроса. Метод Compile, которому предоставляют контекст ObjectContext и значения параметров, возвращает делегата, который формирует определенный результат (например, экземпляр IQueryable<T>). Компиляция запроса выполняется только один раз во время первого выполнения. Параметры слияния, которые заданы для запроса во время компиляции, далее не могут быть изменены. После компиляции запроса ему можно передавать только параметры примитивного типа, но нельзя заменять части запроса, которые изменят созданный код SQL. Дополнительные сведения см. в разделе Параметры объединения Entity Framework и компилированные запросы
Другое дело, что EF не привязан к конкреьному провайдеру. И инициализация происходит при запуске. Вам же нужно при появлении нового провайдера или при выходе нового провайдера реализующих новые фичи SQL заного все перекомпилировать.
Но вполне возможно, что будет жесткая привязка к провайдеру в EF7 .Net Native.
Если можно динамически скомпилировать, то что мешает это сделать при компиляцмм программмы?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы? EP>>Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо S> Да можно, только это никому не нужно. Разберись в предметной области. S>Еще раз в старых версиях Linq to EF были Скомпилированные запросы. S>https://msdn.microsoft.com/ru-ru/library/bb896297(v=vs.110).aspx S>
S>Класс CompiledQuery обеспечивает компиляцию и кэширование запросов для повторного использования. Концептуально данный класс содержит метод CompiledQueryCompile с несколькими перегрузками. Вызовите метод Compile, чтобы создать новый делегат, для представления скомпилированного запроса. Метод Compile, которому предоставляют контекст ObjectContext и значения параметров, возвращает делегата, который формирует определенный результат (например, экземпляр IQueryable<T>). Компиляция запроса выполняется только один раз во время первого выполнения.
Это нормально.Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>А ты нашел извращенцев и на их извращениях делаешь выводы.
EP>Слушай, ты уже в очередной раз наезжаешь на авторов CodeJam — то говоришь что у них "недостаток в мозгах", то "мухи в голове", то вот извращенцами называешь. Делаешь это всё за спиной — твои сообщения в этой теме они могут и не читать. Не хорошо EP>Ты им это всё в соответствующем подфоруме распиши, я твоё мнение уже услышал, и мне это в общем-то не интересно.
Ну во первых ты на них наехал. И на их коде делаешь свои выводы. И постоянно приводишь эту ссылку. Я их ссылку не привожу. Я просто комментирую твои выводы на основании неоптимального кода. И судишь ты о Паварроти по Рабиновичу. И при этом в это и еще и веришь.
Ну и сам иногда занимаюсь извращениями в том числе и копи-пасте, и изучаю С++, что тоже неимоверное извращение. Это нормально S>>Еще раз напомню тебе про количество 1С ников.
EP>Смотри количество продавцов
То есть продавцы программирут БД? Если бы C++ был самым лучшим языком, то не было бы и 1С ников как класса.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>Ты им это всё в соответствующем подфоруме распиши, я твоё мнение уже услышал, и мне это в общем-то не интересно. S> Ну во первых ты на них наехал.
Я на них не наезжал. Наоборот допускаю что они сделали всё необходимое в заданных языком/платформой рамках
S>Если бы C++ был самым лучшим языком, то не было бы и 1С ников как класса.
А и я не говорю что C++ лучший — это очередные домыслы
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Ты им это всё в соответствующем подфоруме распиши, я твоё мнение уже услышал, и мне это в общем-то не интересно. S>> Ну во первых ты на них наехал.
EP> Я на них не наезжал. Наоборот допускаю что они сделали всё необходимое в заданных языком/платформой рамках
Я тебе показал другие решения. Но ты их игнорируешь. При этом ни разу ни привел аналогичный код на С++.
Где подтверждение твоих слов о 100 кратной разнице в коде.
Не суди о Паваротти по Рабиновичу.
S>>Если бы C++ был самым лучшим языком, то не было бы и 1С ников как класса.
EP>А и я не говорю что C++ лучший — это очередные домыслы
То есть
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Не твои слова?
и солнце б утром не вставало, когда бы не было меня
Re[179]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Практические соображения и алгоритмическая выразительность это разные вещи. Алгоритмически все это можно было бы уложить в один небольшой метод. EP>Номинально да, на практике же имеем совсем не номинальный boilerplate.
На практике такие задачи встречаются крайне редко.
НС>>Далеко не только. Еще недавно она была нужна даже для таких базовых вещей как лямбды. EP>"Недавно" это уже лет шесть как назад.
Меньше 5.
EP> И это всё же передёргивание.
Нет, это все же факт. Причем 5 лет назад мы тут слышали ровно те же самые песни.
НС>>И для плохонького аналога анонимных типов она понадобилась. Причем ее не хватило в итоге, и пришлось допиливать при помощи макросов препроцессора. EP>Каких конкретно макросов?
НС>>Ты обсуждаешь простейший алгоритм на С++ с его конкретной реализацией для дотнета, содержащей кучу подробностей, связанных со спецификой платформы. Это самая натуральная демагогия. EP>На C++ из всей "специфики платформы" к этому алгоритму будет несколько десятков строк врапперов для Range интерфейсов
И? Понимаешь, никто тут не утверждает, в отличие от любителей С++, что С# круче всех и лишен каких либо недостатков. Они у него, разумеется, есть. Один из недостатков — отсутствие арифметики в дженериках (точнее этот недостаток не у него, а у платформы). И именно из-за него пришлось делать ту самую кучу перегрузок.
Это проблему можно частично решить — см. Operators там же, в CodeJam. Но все равно остается некоторый оверхед, поэтому в максимально универсальном коде проще перегрузки сгенеритью.
К счастью, на практике в прикладном коде писать дженерик-арифметику с высокими требованиями к перформансу приходится редко (а там где часто — там .NET не лучший выбор).
В общем, совершенно стандартная ситуация — где то выигрываем, где то проигрываем. И только любители С++ чудесным образом не замечают кучу недостатков любимого языка, и разводят на тему "С++ круче всех" километровые флеймы.
НС>>Или давай вспомним, что куча плюсовых OR/M вообще не поддерживают NULL в value колонках, видать из-за крутой алгоритмической выразительности. EP>Причём тут ограничения каких-то левых OR/M
Re[181]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>> А то, что тебе приходится писать жуткие макросо-шаблоны в которых разбираешься только ты считаешь достоинством платформы? EP>>>Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо S>> Да можно, только это никому не нужно. Разберись в предметной области. S>>Еще раз в старых версиях Linq to EF были Скомпилированные запросы. S>>https://msdn.microsoft.com/ru-ru/library/bb896297(v=vs.110).aspx S>>
S>>Класс CompiledQuery обеспечивает компиляцию и кэширование запросов для повторного использования. Концептуально данный класс содержит метод CompiledQueryCompile с несколькими перегрузками. Вызовите метод Compile, чтобы создать новый делегат, для представления скомпилированного запроса. Метод Compile, которому предоставляют контекст ObjectContext и значения параметров, возвращает делегата, который формирует определенный результат (например, экземпляр IQueryable<T>). Компиляция запроса выполняется только один раз во время первого выполнения.
EP>
Молодец, то что ниже опускаешь. И игнорируешь.
Другое дело, что EF не привязан к конкретному провайдеру. И инициализация происходит при запуске. Вам же нужно при появлении нового провайдера или при выходе нового провайдера реализующих новые фичи SQL заного все перекомпилировать.
Но вполне возможно, что будет жесткая привязка к провайдеру в EF7 .Net Native. Если можно динамически скомпилировать, то что мешает это сделать при компиляцмм программмы?
То есть твое утверждение, что " в рамках непосредственно C# такое и вовсе нереализуемо "
Это ложь. Это не реализуемо в рамках конкретной реализации EF. Но никак не языка.
Еще раз это вполне возможно уже реализовано в EF7 .Net Native.
Про .Net Native я уже давал ссылки.
и солнце б утром не вставало, когда бы не было меня
Re[178]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Так это же для реализации языка запросов времени компиляции с нулевыми накладными расходами — в рамках непосредственно C# такое и вовсе нереализуемо
А оно не особо то и нужно. Компиляции при первом использовании вполне достаточно в 99.99% случаев. Я тебе больше скажу — для bltoolkit, предшественника linq2db, даже была такая тула, которая запускалась в процессе сборки, находила статические запросы и компилировала их. Но для linq2db ее никто воспроизводить не стал за отсутствием особой надобности.
Re[179]: Тормознутость и кривость linq. Compile-time EDSL DB
Я на них не наезжал. Наоборот допускаю что они сделали всё необходимое в заданных языком/платформой рамках 
