Здравствуйте, Ikemefula, Вы писали:
I>Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
Чего-чего? ))
А можно попунктно по-русски, чтобы было на что предметно отвечать?
I>Кроме того, лямбда это упрощенный синтаксис и связывание по месту требования.
Только не "требования, связываемые по месту", а переменные или их значения (для иммутабельных языков это одно и то же).
В общем случае это называется замыканием.
Т.е. анонимные лямбды уместы только там, где на такое замыкание не надо ссылаться по имени.
Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными.
Но в C# замыканиям можно давать имя.
Поэтому, Y-костыль в C# не нужен.
I>Есть тут имя или нет, дело абсолютно десятое.
Вообще-то, присвоёние сущностям символических имён времени компиляции — это основа основ языков программирования.
Просто разные языки обладают разными возможностями.
Например, языки, в которых Y-комбинатор необходим, — они обязательно умеют "раскрывать" тела лямбд, иначе вся затея превращается в тыкву.
C# не умеет инлайнить тела делегатов, поэтому для него злоупотребление такой техникой является банальной глупостью. Невежеством.
I>Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.
И вывод типов в C# лучше работает для неаонимных замыканий.
V>>Ты глаза-то открой, все подробности спрятаны за неименованой ламбдой. I>У тебя стейтмент торчит снаружи
Еще раз — стейтмент в том примере спрятан внутри лямбды.
I>а значит надо писать мануал, какие стейтменты можно/нельзя использовать, и отдельно описать присваивания.
Не надо.
I>С экспрешном ничего такого делать не надо.
Глупости.
Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы.
I>>>Зачем же ты раз за разом приводишь примеры тех самых простынь ? V>>Привёди пример короче или слил. I>Алё! С текущей версией языка ничего лучше недоступно — об чем и речь.
Здравствуйте, vdimas, Вы писали:
I>>Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
V>Чего-чего? )) V>А можно попунктно по-русски, чтобы было на что предметно отвечать?
Того-того.
I>>Кроме того, лямбда это упрощенный синтаксис и связывание по месту требования.
V>Только не "требования, связываемые по месту", а переменные или их значения (для иммутабельных языков это одно и то же).
"связывание по месту требования" ты прочел как "требования, связываемые по месту"
V>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными. V>Но в C# замыканиям можно давать имя. V>Поэтому, Y-костыль в C# не нужен.
Попробуй свои примерчики применить на IQueryable.
I>>Есть тут имя или нет, дело абсолютно десятое. V>Вообще-то, присвоёние сущностям символических имён времени компиляции — это основа основ языков программирования.
V>Просто разные языки обладают разными возможностями. V>Например, языки, в которых Y-комбинатор необходим, — они обязательно умеют "раскрывать" тела лямбд, иначе вся затея превращается в тыкву.
V>C# не умеет инлайнить тела делегатов, поэтому для него злоупотребление такой техникой является банальной глупостью. Невежеством.
Ну вот ты сам себе ответил еще раз — C# чего то не умеет. Как следствие — Linq этого тоже умеет.
I>>Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.
V>И вывод типов в C# лучше работает для неаонимных замыканий.
V>>>Ты глаза-то открой, все подробности спрятаны за неименованой ламбдой. I>>У тебя стейтмент торчит снаружи
V>Еще раз — стейтмент в том примере спрятан внутри лямбды.
Раскрой глаза — у тебя стейтмент и внутри, и снаружи.
I>>а значит надо писать мануал, какие стейтменты можно/нельзя использовать, и отдельно описать присваивания. V>Не надо.
Ты попробуй свой вариант для IQueryable применить.
I>>С экспрешном ничего такого делать не надо.
V>Глупости. V>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы.
В огороде бузина, а в Киеве дядька.
I>>Алё! С текущей версией языка ничего лучше недоступно — об чем и речь.
V>Т.е. слил?
Моя цель показать тебе, что все возможные решения приводят к простыням и дополнительным проблемам. Твой код это и есть те самые простыни/проблемы, о которых я говорю.
Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Здравствуйте, Ikemefula, Вы писали:
V>>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными. V>>Но в C# замыканиям можно давать имя. V>>Поэтому, Y-костыль в C# не нужен. I>Попробуй свои примерчики применить на IQueryable.
Выглядит как эпик слив, аднака.
Твои слова:
Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
...
Есть тут имя или нет, дело абсолютно десятое. Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.
?
Разбираем:
— экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены.
Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются;
— транслировать/преобразовывать можно только "чистые" выражения.
Опять ложь, вся исходная информация доступна для анализа и преобразования.
— Попробуй свои примерчики применить на IQueryable.
Манипуляция или безграмотность — на сегодня Linq умеет составлять лишь ограниченный класс Expression, причём, это ограничение связано не с видом выражения (первого вида или второго), а с конкретной реализацией внутри Linq-хелпера в компиляторе.
И даже в таком виде многие реализации Querable-провайдеров "не понимают" и половины выражений, которые для них может составить линк.
Это проблема IQueryable? — нет, это проблема ограничений реализации или принципиальных ограничений конкретных провайдеров.
Можно ли генерить батчи с переменными на Linq, где будут не только запросы, но и манипуляция переменными? — можно запросто.
Можно ли написать провайдер, который будет автоматически преобразовывать рекурсивные запросы в CTE? — ничто не запрещает.
Итого, слабость нынешней реализации подаётся как аргумент в споре о том, что принципиально можно сделать, а что нет.
V>>C# не умеет инлайнить тела делегатов, поэтому для него злоупотребление такой техникой является банальной глупостью. Невежеством. I>Ну вот ты сам себе ответил еще раз — C# чего то не умеет. Как следствие — Linq этого тоже умеет.
Очередной эпик. ))
Linq в варианте IQueryable, напротив, вместо тел делегатов генерит их AST.
V>>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы. I>В огороде бузина, а в Киеве дядька.
Еще и не понимаем, что через "чистый" вызов ф-ии можно делать "грязные" дела.
I>Моя цель показать тебе, что все возможные решения приводят к простыням и дополнительным проблемам.
Не всевозможные, а лишь с учётом некоторых реализованных провайдеров.
Которые, как мы видим, постоянно улучшают свой функционал.
Поэтому, твоя попытка "запретить даже пытаться прыгать выше ягодиц" целиком нелепа.
I>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Э, нет.
Разница в том, что я рассказываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"
Здравствуйте, vdimas, Вы писали:
V>Тем не менее, Синклер вашей братии часто подыгрывает, расплачиваясь за это лишней степенью свободы.
О чем ты? Ты опять про какого-то Синклера в своей голове, который не имеет ничего общего с реальным Антоном
V>В том обсуждении, с которого мы несколько месяцев назад зацепились, я общался более чем нормально.
Вспомнила бабка, как в девках была =) Ты там с таких козырей зашел, что от бана тебя спасло только то что форум флеймовый.
Здравствуйте, IB, Вы писали:
IB>Ты там с таких козырей зашел, что от бана тебя спасло только то что форум флеймовый.
Прямая ложь.
Зашёл я там вполне нормально и несколько твоих некорректных сообщений терпеливо сносил, безуспешно пытаясь вернуть тебя в конструктивное русло.
Поняв, что это невозможно, позволил себе прекратить терпеть выходки взрослого человека с подростковой психикой, бо тому человеку до 50-ти уже недалеко, что всё вместе образует лишь надоедливый сюрр.
Здравствуйте, vdimas, Вы писали: V>Конечно.
Интересно. Я в своё время пробовал залудить аналогичную штуку с linq запросами, нарвался почему-то на замыкание по значению и плюнул.
То есть при попытке сделать классический join с самим собой там всё компилировалось, но при запуске эта штука выдавала честный NullReferenceException, то есть джойнила не с собой, а с тем значением, которым оно проинициализировано в первом стейтменте. Так что я решил, что оно в принципе работает не так, как надо, и забил.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали: V>>Конечно. S>Интересно. Я в своё время пробовал залудить аналогичную штуку с linq запросами, нарвался почему-то на замыкание по значению и плюнул. S>То есть при попытке сделать классический join с самим собой там всё компилировалось, но при запуске эта штука выдавала честный NullReferenceException, то есть джойнила не с собой, а с тем значением, которым оно проинициализировано в первом стейтменте. Так что я решил, что оно в принципе работает не так, как надо, и забил.
V>Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
V>...
V>Есть тут имя или нет, дело абсолютно десятое. Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.
V>?
V>Разбираем:
V>- экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены. V>Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются;
Ты приписал мне какие то слова, которые сам же и опровергаешь. Короткий вариант лямбды не может содержать никаких стейтментов. Это ограничение языка и сделано это намеренно.
V>- транслировать/преобразовывать можно только "чистые" выражения. V>Опять ложь, вся исходная информация доступна для анализа и преобразования.
И это снова ты споришь со своей же интерпретацией. Трудоёмкость анализа АСТ в ограниченном виде и в полном отличается на порядки. В одном случае ты видишь Select, а в другом мешанину стейтментов, из которой даже разработчику может быть трудно понять, про что речь. В одном случае ты генеришь внятный SQL, а вдругом — непойми-что.
V>- Попробуй свои примерчики применить на IQueryable. V>Манипуляция или безграмотность — на сегодня Linq умеет составлять лишь ограниченный класс Expression, причём, это ограничение связано не с видом выражения (первого вида или второго), а с конкретной реализацией внутри Linq-хелпера в компиляторе.
Язык C# имеет определенное ограничение — сокращенная форма лямда-выражений имеет ограниченый синтаксис. Ограничения Linq — следствие.
V>Можно ли написать провайдер, который будет автоматически преобразовывать рекурсивные запросы в CTE? — ничто не запрещает.
Теоретически — можно. На практике тебе надо уметь разобрать все возможные конструкции и правильно соптимизировать.
V>Очередной эпик. )) V>Linq в варианте IQueryable, напротив, вместо тел делегатов генерит их AST.
Именно. Я тебе про это и говорю. Попробуй в IQueryable применить свой подход. Внезапно, от Linq-провайдера понадобится понимание всех возможных обходных путей для рекурсии. Их, вообще говоря, несчетное количество — все зависит от фантазии программиста. Далее, девелоперы любят писать кастомный код — скажем, в один цикл собирать всю логику — проекции, фильтрацию, группирование и тд и тд. Это — норма. И такая же норма, когда этот цикл прибит гвоздями к присваиваниям. Что здесь может сгенерить провайдер — не ясно.
И вот Linq при помощи C# принуждает тебя разделять операции — Select, Where, Join, Group и тд. Соответственно, интерпретатору не надо вычислять намерения разработчика, распутывать всю мешанину, что девелопер напихал в цикл, а можно сразу приступить к оптимизации результирующего дерева.
V>>>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы. I>>В огороде бузина, а в Киеве дядька. V>Еще и не понимаем, что через "чистый" вызов ф-ии можно делать "грязные" дела.
Во-во, бузина и дядька. Я говорю о том, что стейтментами можно писать произвольный код. А в Linq выражениях жестко соблюдается конвеншн — разделение операций, Select, Where и тд.
I>>Моя цель показать тебе, что все возможные решения приводят к простыням и дополнительным проблемам. V>Не всевозможные, а лишь с учётом некоторых реализованных провайдеров.
Простыни — в твоём коде. Это уже проблема — код стал многословным. Гипотетически, провайдер может транслировать всё что угодно. На практике даже серьезные компиляторы умеют ограниченое количество приемчиков, если в коде появляются сайд-эффекты. Вся функциональщина построена на отделении таких эффектов от основной логики.
Тебе не кажется, что превращать Linq-провйдер в компилятор навроде С++ или какой Скалы идея слишком радикальная ?
V>Разница в том, что я рассказываю и показываю — что, почему и как.
А по моему ты споришь со своими же интерпретациями.
Здравствуйте, vdimas, Вы писали:
V>Прямая ложь.
Хорошо, что ты понимаешь, что говоришь не правду, но надо двоеточие ставить для наглядности )
V>Зашёл я там вполне нормально и несколько твоих некорректных сообщений терпеливо сносил, безуспешно пытаясь вернуть тебя в конструктивное русло.
Ты как обычно, вывалил загадочный поток сознания с полунамеками на одному тебе известную истину, ну и обхамил, как вишенка на торте, тем самым определив дальнейший ход дискуссии.
V>Поняв, что это невозможно, позволил себе прекратить
Не придумывай себе оправдания, если ты хамло, то шила не утаишь )
V>терпеть выходки взрослого человека с подростковой психикой, бо тому человеку до 50-ти уже недалеко, что всё вместе образует лишь надоедливый сюрр.
Как верно ты себя охарактеризовал! ))
Здравствуйте, Ikemefula, Вы писали:
V>>- экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены. V>>Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются; I>Ты приписал мне какие то слова, которые сам же и опровергаешь. Короткий вариант лямбды не может содержать никаких стейтментов.
Я тебе привёл пример, когда может.
I>Это ограничение языка и сделано это намеренно.
Я привёл тебе конструкции в иерархии Expression, которые показывают, что потенциально никаких ограничений нет.
V>>- транслировать/преобразовывать можно только "чистые" выражения. V>>Опять ложь, вся исходная информация доступна для анализа и преобразования. I>И это снова ты споришь со своей же интерпретацией. Трудоёмкость анализа АСТ в ограниченном виде и в полном отличается на порядки.
Ага, уже трудоёмкость.
Уже торгуемся. ))
I>В одном случае ты видишь Select, а в другом мешанину стейтментов, из которой даже разработчику может быть трудно понять, про что речь. В одном случае ты генеришь внятный SQL, а вдругом — непойми-что.
В батчах того же T-SQL вполне могут быть стейтменты.
I>Язык C# имеет определенное ограничение — сокращенная форма лямда-выражений имеет ограниченый синтаксис. Ограничения Linq — следствие.
Зашёл на новый круг.
Я же показал уже, как обходить ограничения.
V>>Можно ли написать провайдер, который будет автоматически преобразовывать рекурсивные запросы в CTE? — ничто не запрещает. I>Теоретически — можно. На практике тебе надо уметь разобрать все возможные конструкции и правильно соптимизировать.
Продолжаем торговаться.
А как же "принципиальность"? ))
V>>Очередной эпик. )) V>>Linq в варианте IQueryable, напротив, вместо тел делегатов генерит их AST. I>Именно. Я тебе про это и говорю. Попробуй в IQueryable применить свой подход. Внезапно, от Linq-провайдера понадобится понимание всех возможных обходных путей для рекурсии. Их, вообще говоря, несчетное количество — все зависит от фантазии программиста.
Их как раз мало — сие зависит от конкретного провайдера.
Например, для различных диалектов SQL проблемы возникают даже на вполне "обычных", т.е. ограниченных видах запросов.
Но зато на LinqToXML теоретически нет никаких проблем и для этого провайдера рекурсия смотрелась просто великолепно ввиду иерархической природы самих данных, в отличие от реляционных БД.
I>Далее, девелоперы любят писать кастомный код — скажем, в один цикл собирать всю логику — проекции, фильтрацию, группирование и тд и тд. Это — норма. И такая же норма, когда этот цикл прибит гвоздями к присваиваниям. Что здесь может сгенерить провайдер — не ясно.
Давай конкретный пример, там и разберём.
V>>>>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы. I>>>В огороде бузина, а в Киеве дядька. V>>Еще и не понимаем, что через "чистый" вызов ф-ии можно делать "грязные" дела. I>Во-во, бузина и дядька. Я говорю о том, что стейтментами можно писать произвольный код. А в Linq выражениях жестко соблюдается конвеншн — разделение операций, Select, Where и тд.
А я тебе показал, что присваивание можно делать в телах ф-ий.
I>Гипотетически, провайдер может транслировать всё что угодно. На практике даже серьезные компиляторы умеют ограниченое количество приемчиков, если в коде появляются сайд-эффекты. Вся функциональщина построена на отделении таких эффектов от основной логики. I>Тебе не кажется, что превращать Linq-провйдер в компилятор навроде С++ или какой Скалы идея слишком радикальная ?
Нет, не кажется.
Более того, прямо отсюда хорошо видно, что у него и пути-то другого нет.
Эту часть языка будут дорабатывать и усложнять.
V>>Разница в том, что я рассказываю и показываю — что, почему и как. I>А по моему ты споришь со своими же интерпретациями.
В том сообщении, на которое ты отвечал, я показал, что ты выдаёшь ограничения реализации неких нынешних провайдеров за фундаментальные ограничения линка. Т.е. не способен отделить принципиальные ограничения технологии от де-факто недостаточного покрытия функциональностью на текущий момент. ))
Так и запишем.
Здравствуйте, IB, Вы писали:
V>>Зашёл я там вполне нормально и несколько твоих некорректных сообщений терпеливо сносил, безуспешно пытаясь вернуть тебя в конструктивное русло. IB>Ты как обычно, вывалил загадочный поток сознания с полунамеками на одному тебе известную истину
Судя по подробностям уже этого обсуждения — ты запросто можешь вклиниваться и разговор о вещах, которые НЕ понимаешь.
Одно раздражает — ты всегда сваливаешь своё невладение предметом на окружающих.
Не понятно — спроси.
Но ты не можешь.
Не акцентируясь даже на той истине, что задавать вопросы тоже надо уметь, у тебя и помимо такого неумения еще мешок комплексов сверху: http://www.rsdn.org/forum/dotnet/7200054.1
Твой стиль общения банально омерзителен. Бррр...
По-интернету, разумеется.
Я уверен, что в реальной жизни ты милейшей души человек.
Классика двуличности, аднака.
А тут же все уже давно не школьники, т.е. видят тебя эдакого дёрганного Петрушку насквозь. ))
V>>Поняв, что это невозможно, позволил себе прекратить IB>Не придумывай себе оправдания, если ты хамло, то шила не утаишь )
Я обычный человек.
Когда кто-то берёт на себя больше, чем в состоянии унести, — могу назвать происходящее прямой речью, какие проблемы?
Следи за своими мыслями и языком. Иначе жаловаться потом в стиле "а нас-то за что?" — это эпик фейл аднака.
Назвался груздем — терпи.
V>>терпеть выходки взрослого человека с подростковой психикой, бо тому человеку до 50-ти уже недалеко, что всё вместе образует лишь надоедливый сюрр. IB>Как верно ты себя охарактеризовал! ))
Здравствуйте, vdimas, Вы писали:
V>Судя по подробностям уже этого обсуждения — ты запросто можешь вклиниваться и разговор о вещах, которые НЕ понимаешь.
По подробностям того обсуждения, очень хорошо видно, кто на самом деле не понимает, а когда тебя вывели на чистую воду и носом ткнули, ты весь аж извелся на хамство и оскорбления.
И так ты делаешь каждый раз, вот и в этой ветке ты проигнорировал все вопросы по сути и начал вспоминать кто и где тебе какую мозоль отдавил.
V>Одно раздражает — ты всегда сваливаешь своё невладение предметом на окружающих.
А ты не раздражайся, дыши глубже =)
Меня вот твое неуклюжее хамство только забавляет )
V>Не понятно — спроси.
Так я тебя и спрашиваю, и не только я. Вот рядом есть блестящий диалог, где тебя сообщений десять пытают что же ты имеешь ввиду — ответа так и не случилось.
Антон вот тоже признался, что фиг догадаешься, что ты там себе придумал — примеров больше чем достаточно.
V>Но ты не можешь.
Я — могу, мне не сложно )
V>Не акцентируясь даже на той истине, что задавать вопросы тоже надо уметь, у тебя и помимо такого неумения еще мешок комплексов сверху: V>http://www.rsdn.org/forum/dotnet/7200054.1
По этой ссылке твои комплексы, а не мои, опять промазал? ))
V>В попытке замылить собственные комплексы и недостаток знаний ты часто увлекаешься, берегов не видишь:
Не тебе про берега рассказывать, у тебя их вообще нет =) Но то как тщательно ты следишь за моими постами — очень трогательно ))
V>Твой стиль общения банально омерзителен. Бррр...
Дыши глубже )
V>Я уверен, что в реальной жизни ты милейшей души человек.
Да я и по инету тоже зайка, с адекватными собеседниками )
V>А тут же все уже давно не школьники, т.е. видят тебя эдакого дёрганного Петрушку насквозь. ))
Тебе ли этого не знать
V>Я обычный человек.
Не, ты человек редкой закомплексованности с манией величия — это уникальное сочетание, есть чем гордиться )
V>Когда кто-то берёт на себя больше, чем в состоянии унести, — могу назвать происходящее своей речью, какие проблемы?
Твоя проблема в том, что ты разговариваешь не с реальными людьми, а с теми которых ты сам себе придумал на основе реальных. Весь этот топик, очень характерный тому пример.
V>Следи за своими мыслями и языком. Иначе жаловаться потом в стиле "а нас-то за что?" — это эпик фейл аднака.
А я жалуюсь? Пока жалуешься только ты ))
V>Детсад.
Да, и это тоже ты ))
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>- экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены. V>>>Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются; I>>Ты приписал мне какие то слова, которые сам же и опровергаешь. Короткий вариант лямбды не может содержать никаких стейтментов.
V>Я тебе привёл пример, когда может.
Внутри этих скобок стейтмент — определение функции. А раз так, то провайдер обязан уметь понимать вообще все что угодно, т.е. любые стейтменты. Это, в свою очередь, обязует разработчиков написать компилятор с императивной мешанины в стройный функциональный декларативный код. В противном случае оптимизатор SQL Не поймет намерений разработчика и обвалит перформанс.
I>>Это ограничение языка и сделано это намеренно. V>Я привёл тебе конструкции в иерархии Expression, которые показывают, что потенциально никаких ограничений нет.
Правильнее сказать — гипотетически. Но сложность решения, в котором направо-налево используеются стейтменты, присваивания мягко говоря разная. До сих пор нет ни одного компилятора, который умеет произвольный код транслировать в стройный функциональный декларативный. Вот наоборот, функциональный в императивный — легко. Императивный в функциональный — только частные случаи.
V>>>Опять ложь, вся исходная информация доступна для анализа и преобразования. I>>И это снова ты споришь со своей же интерпретацией. Трудоёмкость анализа АСТ в ограниченном виде и в полном отличается на порядки.
V>Ага, уже трудоёмкость. V>Уже торгуемся. ))
Я и начинал с этого, и продолжаю говорить про это же.
I>>В одном случае ты видишь Select, а в другом мешанину стейтментов, из которой даже разработчику может быть трудно понять, про что речь. В одном случае ты генеришь внятный SQL, а вдругом — непойми-что. V>В батчах того же T-SQL вполне могут быть стейтменты.
Если ты перепишешь SQL на стейтменты, то увидишь, что перформанс будет совсем другим.
I>>Язык C# имеет определенное ограничение — сокращенная форма лямда-выражений имеет ограниченый синтаксис. Ограничения Linq — следствие. V>Зашёл на новый круг. V>Я же показал уже, как обходить ограничения.
Пока что ты показываешь вещи, известные со времён C# 2.0 и делаешь вид, что открыл Америку.
I>>Теоретически — можно. На практике тебе надо уметь разобрать все возможные конструкции и правильно соптимизировать.
V>Продолжаем торговаться. V>А как же "принципиальность"? ))
Лучшие оптимизаторы SQL бессильны, когда им скармливают императивные стейтменты. Ты уверен, что у тебя получится гораздо лучше ?
I>>Именно. Я тебе про это и говорю. Попробуй в IQueryable применить свой подход. Внезапно, от Linq-провайдера понадобится понимание всех возможных обходных путей для рекурсии. Их, вообще говоря, несчетное количество — все зависит от фантазии программиста.
V>Их как раз мало — сие зависит от конкретного провайдера.
В стейтментах можно писать все что угодно и как угодно. И только в рантайме ты получишь ошибку, что де провайдер не умеет разруливать цикл do-while n-кратной вложенности насквозь прошитый присваиваниями и прочими чудесами.
I>>Во-во, бузина и дядька. Я говорю о том, что стейтментами можно писать произвольный код. А в Linq выражениях жестко соблюдается конвеншн — разделение операций, Select, Where и тд.
V>А я тебе показал, что присваивание можно делать в телах ф-ий.
Тогда тебе надо вводить легальные паттерны кода, и нелегальные. Например, foreach можно переписать через for, while, do-while, но из них легальным будет только один, а остальные на совести разработчика.
I>>Тебе не кажется, что превращать Linq-провйдер в компилятор навроде С++ или какой Скалы идея слишком радикальная ?
V>Нет, не кажется.
Ну ок.
V>В том сообщении, на которое ты отвечал, я показал, что ты выдаёшь ограничения реализации неких нынешних провайдеров за фундаментальные ограничения линка.
Ты продолжаешь спорить со своими интерпретациями. Попробуй на досуге уточнять прочитаное, узнаешь много нового.
I>Внутри этих скобок стейтмент — определение функции. А раз так, то провайдер обязан уметь понимать вообще все что угодно, т.е. любые стейтменты. Это, в свою очередь, обязует разработчиков написать компилятор с императивной мешанины в стройный функциональный декларативный код.
С какого пальца насосано это требование?
Пресловутый всуе упоминаемый T-SQL имеет большинство отличий от стандартного SQL как раз в плане императивных конструкций и батчей.
PL/SQL — тем более.
I>В противном случае оптимизатор SQL Не поймет намерений разработчика и обвалит перформанс.
Это проблемы SQL-сервака и мои как разработчика.
Если я пихаю серваку батч, значит мне так надо.
Извольте исполнять, как грится.
(остальное скипнуто, бо ходит вокруг одного и того же по кругу)
Здравствуйте, Sinclair, Вы писали:
S>Интересно. Я в своё время пробовал залудить аналогичную штуку с linq запросами, нарвался почему-то на замыкание по значению и плюнул. S>То есть при попытке сделать классический join с самим собой там всё компилировалось, но при запуске эта штука выдавала честный NullReferenceException, то есть джойнила не с собой, а с тем значением, которым оно проинициализировано в первом стейтменте. Так что я решил, что оно в принципе работает не так, как надо, и забил.
Стоит обратить внимание на используемую сигнатуру Where с индексом, т.е. код перебора по коллекции, который эту же коллекцию и генерирует, должен ограничиваться текущей её длиной, иначе в том коде получается переполнение стека.
Здравствуйте, IB, Вы писали:
V>>Судя по подробностям уже этого обсуждения — ты запросто можешь вклиниваться и разговор о вещах, которые НЕ понимаешь. IB>По подробностям того обсуждения, очень хорошо видно, кто на самом деле не понимает, а когда тебя вывели на чистую воду
Ты лишь показал на весь свет непонимание механизма трансляции РИ в РА, больше там ничего не было.
Само это непонимание не страшно, ес-но.
Страшно когда изо всех сил делают вид, что хоть что-то понимают, а непонимание замыливают через изворачивание и хамство.
Ты ж не понимаешь по этой теме аж ничерта, чего влез-то?
IB>и носом ткнули, ты весь аж извелся на хамство и оскорбления.
Носом тоже никто не ткнул.
Более-менее предметно пытался тыкать Синклер, но лишь показал собственные представления, которые пришлось допиливать до происходящего в нашей реальности. ))
Твоё "пойди почитай" — это не тыканье носом, это маскировка собственной безграмотности, перевод стрелок в хамской манере.
Был бы ты грамотен, ты бы указал конкретно, с чем не согласен и показал бы, что конкретно почитать и почему именно это.
Но ты таки не смог.
Поэтому, болтун.
IB>И так ты делаешь каждый раз, вот и в этой ветке ты проигнорировал все вопросы по сути и начал вспоминать кто и где тебе какую мозоль отдавил.
Кто спрашивал по-сути, тем ответил.
А от тебя что тогда, что сейчас прёт лишь непонимание сути на фоне физической неспособность задавать честные вопросы в духе: "я недопонял конкретно вот этот момент, объясните".
Тебе жмет и это чувство, судя со стороны, для тебя приоритетнее, чем быть адекватным собеседником.
V>>Одно раздражает — ты всегда сваливаешь своё невладение предметом на окружающих. IB>А ты не раздражайся
Дык, мишень со лба сотри и не будет тебе прилетать.
Здравствуйте, vdimas, Вы писали:
V>Ты лишь показал на весь свет непонимание механизма трансляции РИ в РА, больше там ничего не было.
Это ты показал свои подростковые фантазии на предмет этого механизма... Причем такие наивные, что даже не совсем было ясно с какой стороны тебя переучивать, потом стало понятно, что бесполезно =)
V>Страшно когда изо всех сил делают вид, что хоть что-то понимают, а непонимание замыливают через изворачивание и хамство.
Да, и именно этим ты регулярно занимаешься )
V>Носом тоже никто не ткнул.
Да, ты предпочитаешь это игнорировать )
V>Кто спрашивал по-сути, тем ответил.
Ты никому и ничего не ответил, навел тумана и свалил.
V>Дык, мишень со лба сотри и не будет тебе прилетать.
Пока прилетает только тебе, но ты упорно напрашиваешься снова и снова. )
Рад, что ты прекратил хвастаться пониманием нюансов C# 2.0 и 3.0.
I>>В противном случае оптимизатор SQL Не поймет намерений разработчика и обвалит перформанс.
V>Это проблемы SQL-сервака и мои как разработчика. V>Если я пихаю серваку батч, значит мне так надо. V>Извольте исполнять, как грится.
А откуда в твоей такой архитектуре взяться перформасу ? И зачем тогда эта архитетура нужна, собтсвенно, если на ней неоткуда взяться перформансу ? Сам подумай. Ты ведь не один такой девелопер, другие тоже в природе имеются. Им нужет тот самый мануал — как писать быстрый код. Какие конструкции языка транслируются в какие конструкции SQL, как этим управлять и тд. Одна и та же конструкция может быть быстрой, а может быть медленно, в зависимости от того, где выполняется, в процессоре или на сервере БД.
Шансы, что девелоперы напишут быстрый код, стремятся к нулю. Проще запилить БД на джаваскрипте, чем заставить работать эту твою архитектуру
Короче, непонятно, что за разработка такая — если надо думать про каждое присваивание, что оно может поломать план запроса.
Ты точно думаешь, что мир пошел по этому пути ? Сильно вряд ли ты задумываешься о том, в какие команды процессора транслируется код даже в С++, не говоря о дотнете или джаве. Ты не думал, почему ушли от ассемблера ? Скажем, уже лет двадцать никто не пишет вставки ассемблера в сишный код. А до того это было массово, чуть не поголовно.
Здравствуйте, Ikemefula, Вы писали:
I>Рад, что ты прекратил хвастаться пониманием нюансов C# 2.0 и 3.0.
А я не рад, что ты не прекратил про меня фантазировать.
V>>Это проблемы SQL-сервака и мои как разработчика. V>>Если я пихаю серваку батч, значит мне так надо. V>>Извольте исполнять, как грится. I>А откуда в твоей такой архитектуре взяться перформасу ?
А откуда ты вообще взял такую постановку вопроса?
И почему батч обязательно означает отсутствие перформанса?
ИМХО, ровно наоборот, лучше произвести как можно больше вычислений на стороне сервера.
I>Короче, непонятно, что за разработка такая — если надо думать про каждое присваивание, что оно может поломать план запроса.
Пусть сервак думает.
Просто надо знать, что он может и каким именно образом.
Рекламировать мне тут твой любимый вариант из разряда "разработчик не должен ни о чём думать" не надо.
I>Ты точно думаешь, что мир пошел по этому пути ?
Ручками когда? — точно.
Генерят и шлют батчи на "ту" сторону аж бегом.
Linq призван автоматизировать всё то, что "ручками"... ну и вот.
I>Сильно вряд ли ты задумываешься о том, в какие команды процессора транслируется код даже в С++
Кто не задумывается, тот на С++ не пишет.
Кто не задумывается, что происходит на стороне ДБ, тот тоже пусть под ДБ не пишет, какие проблемы?
Пусть этим занимаются более квалифицированные коллеги.
Здравствуйте, IB, Вы писали:
V>>Ты лишь показал на весь свет непонимание механизма трансляции РИ в РА, больше там ничего не было. IB>Это ты показал свои подростковые фантазии на предмет этого механизма...
IB>Причем такие наивные, что даже не совсем было ясно с какой стороны тебя переучивать, потом стало понятно, что бесполезно =)
Еще ни разу на моей памяти тебе ничего не стало понятно, если речь о чём-то сложнее, чем инструкция для пользователя.
Лень ума.
V>>Страшно когда изо всех сил делают вид, что хоть что-то понимают, а непонимание замыливают через изворачивание и хамство. IB>Да, и именно этим ты регулярно занимаешься )
Я готов обсуждать предметно и обсуждаю.
Ты не способен.
Ты даже задавать вопросы еще не научился.
V>>Носом тоже никто не ткнул. IB>Да, ты предпочитаешь это игнорировать )
На любые твои азбучные истины были даны ответы.
Они тебе не понравились и твой анус заполыхал.
V>>Кто спрашивал по-сути, тем ответил. IB>Ты никому и ничего не ответил, навел тумана и свалил.
Еще и врать изволим.
Ветка на месте, мои ответы на месте.
V>>Дык, мишень со лба сотри и не будет тебе прилетать. IB>Пока прилетает только тебе, но ты упорно напрашиваешься снова и снова. )
Да ладно.
Твой анус всегда полыхает по одной и той же причине — ты не можешь смириться с наличием коллег, умнее тебя.
Шумишь, дёргаешься, вешаешь себе мишень на лоб. ))
Но это твои проблемы.
Мы уже победили, просто это еще не так заметно...
