Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 18:14
Оценка: 34 (1)
Здравствуйте, EvilChild, Вы писали:

EC>Если речь о том, что макрос чисто технически это просто класс, то это никак дело не менят.

EC>Речь о другом.
EC>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
EC>Макрос же совсем другое дело.

Т.е. библиотеку, которая решает системы линейных уравнений стабилизированным методом бисопряженных градиентов понять, конечно, легче, да?
Речь идет о том, что библиотека написанная с использованием знакомых программисту средств может иметь произвольно сложную семантику. Когда Вы написали, что мол, неважно, что макрос написан на том же языке, что и обычная библиотека — важно то, что этот макрос делает какую-то сложную работу, Вы в общем-то эту идею и подтвердили.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:33
Оценка:
Здравствуйте, IT, Вы писали:

IT>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

Думаю ты понимаешь о чём я, но делаешь вид, что нет: библиотечные классы и их методы ничего не делают с написанным мной кодом.

IT>Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.

С поскипаной мыслью согласен.

Можешь привести примеры задач, стоящих перед тобой, которые требуют применения макросов?
Помимо приведённого ранее примера про DAL — там выглядит естественно.
Правда в свете LINQ необходимость этой фичи мне кажется менее востребованной.
now playing: Dom & Klute — Maximus
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:42
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

Думаю в этой библиотеке самое сложное будет метод решения и возможно трики ускоряющие код.

K>Речь идет о том, что библиотека написанная с использованием знакомых программисту средств может иметь произвольно сложную семантику.

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

K> Когда Вы написали, что мол, неважно, что макрос написан на том же языке, что и обычная библиотека — важно то, что этот макрос делает какую-то сложную работу, Вы в общем-то эту идею и подтвердили.

Можно перефразировать это предложение? а то так и не понял его смысл.
now playing: Dom & Roland — Sanity
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:49
Оценка:
Здравствуйте, IT, Вы писали:

C>>Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.


IT>Я разве утверждал обратное? Я лишь ответил на вопрос. Может быть не достаточно ясно? Но ты — молодец, безжалостно эту неясность искоренил


Ты считаешь, что реализовать LINQ на макросах было бы идеологически более правильно, чем хардкодить в язык?
Если да, то озвучь плюсы и минусы.
now playing: Dom & Roland — Sanity
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 18:52
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

K>См. выделенное. Я говорил не про pattern-matching вообще — а про pattern-matching, как средство декомпозиции AST в макросистеме.


К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 18:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.


Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 19:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.


Что надо было докрутить в компиляторе?
now playing: Calyx & Ill.Skillz — Thru Your Eyes
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 19:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.


Это пока ещё не 100% факт. Но даже если это так, то изменения в компиляторе потребуются минимальные, чего не скажешь о реализации LINQ для C#.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 19:13
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Что надо было докрутить в компиляторе?


LINQ подразумевает неявное представление лямбды ввиде expression tree или генерации кода в зависимости от ожидаемого типа делегата, а немерлевые макросы вызываются только явно, по атрибуту, псевдофункции или ключевому слову. Все это осложняется extension methods.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 19:50
Оценка:
Здравствуйте, EvilChild, Вы писали:

K>>Речь идет о том, что библиотека написанная с использованием знакомых программисту средств может иметь произвольно сложную семантику.

EC>При использовании макросов эта библиотека сможет воздействовать на клиентский код гораздо более непредсказуемым способом, чем без них.

Библиотека не может воздействовать на пользовательский код, да. Но она может воздействовать на пользовательские данные и состояние системы в целом (для чего она и была написана). И это воздействие имеет всю полноту непредсказуемости. Например — библиотека работы с TCP/IP, вполне может поставить раком всё приложение, вроде его неработоспособности по причине таймаута в DNS, или как место через которое проникает злобный хакер и т.п.

Не думаю, что можно сравнить степень воздействия на программу библиотек и макросов. Библиотеки бывают большие и сложные, а макросы простые. Макросы обычно не пишут так, чтоб они воздействовали на произвольный код, а только на тот, который специально для них отмечен — ключевыми словами, аннотациями и пр. Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 20:04
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.


Мне казалось, что реализация AOP на макросах это самый прямой вариант. Это не так?
now playing: Posthuman — Lagrange Point
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:04
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Библиотека не может воздействовать на пользовательский код, да. Но она может воздействовать на пользовательские данные и состояние системы в целом (для чего она и была написана). И это воздействие имеет всю полноту непредсказуемости. Например — библиотека работы с TCP/IP, вполне может поставить раком всё приложение, вроде его неработоспособности по причине таймаута в DNS, или как место через которое проникает злобный хакер и т.п.

Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.
Sapienti sat!
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:22
Оценка:
Здравствуйте, EvilChild, Вы писали:

M>>Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.


EC>Мне казалось, что реализация AOP на макросах это самый прямой вариант. Это не так?


AOP реализуется через изменение дерева, и умные макросы так-же, и плагины к компилятору тоже через изменение AST реализуются — на этом их сходство и заканчивается. По идеологии — AOP меняет значения стандартных операций. Точнее — любых операций, и это было-бы хорошо для "определённых пользователем операций". А поскольку AOP пока пользуют в языках, где определённых пользователем операций нет — то в настоящее время он модифицирует только стандартные операции. А это и есть диверсия.

С появлением мета-данных (аннотаций) AOP может использоваться значительно более конструктивно. Его можно "натравить" только на операции со специально помеченными данными (полями, классами). С появлением определяемых пользователем операций (операторов в выражениях, statements, инициализаций и пр.) AOP мог бы совсем войти в конструктивное русло. Стать аналогом макроса, альтернативным способом определения как трансформировать дерево. Ему бы ещё отрезать возможность переопределять уже определённые операции (а стандартные мы считаем уже определёнными), и чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 20:26
Оценка: 16 (3) +2
Здравствуйте, EvilChild, Вы писали:

IT>>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

EC>Думаю ты понимаешь о чём я, но делаешь вид, что нет: библиотечные классы и их методы ничего не делают с написанным мной кодом.

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

EC>Можешь привести примеры задач, стоящих перед тобой, которые требуют применения макросов?

EC>Помимо приведённого ранее примера про DAL — там выглядит естественно.
EC>Правда в свете LINQ необходимость этой фичи мне кажется менее востребованной.

Давай возьмём для примера тот же линк и попробуем его применить, допустим, для веб-приложения. У linq есть следующие весьма привлекательные возможности:

— устранение одноразовых структур для ad-hoc запросов;
— устранение pass-through слоёв.

Учитывая, что в большинстве случаев логика веб-приложения диктуется именно UI, у нас вместо трёх слоёв и дополнительной структуры может получится вот такая простая вещь из 3-х строк:

grid.Source = from c in customers   
              join o in orders on c equals o.Customer into oo   
              select new { c.CompanyName, OrderCount = oo.Count()

Пока всё просто замечательно.

Теперь рассмотрим проблемы.

Во-первых, из-за кривой реализации баиндинга в ASP.NET, при работе с навороченными веб-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае мы нарываемся на рефлекшин со всеми вытекающими последствиями. Будут ли анонимные типы реализовывать ICustomTypeDescriptor? У меня есть на этот счёт определённые сомнения.

Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.

В результате, хотя всё и выглядит зашибись, мы уже получили неустранимые проблемы. Точнее первую можно легко устранить, но за счёт отказа от анонимных типов и возврата к одноразовым типам. Второе даже не знаю, разве что написать Linq2Me и огранизовать кешироание запросов самостоятельно.

Поехали дальше.

В-третьих. Обрати внимание вот на этот
Автор: fuurin
Дата: 04.08.07
знаковый топик и особенно на ответ.

Нет, потому что штатно LINQ2SQL этого не поддерживает, а расширять генерацию SQL можно будет только в следующей версии.


Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут.

В-четвётых. Аналогичная проблема возникает при ручном конструировании запросов, что необходимо для реализации всевозможных фильтров. Линк здесь уже никак не поможет и придётся заниматься самой обычной императивщиной.

В-пятых. Предположим, что я захотел добавить кеширование результата запроса в зависимости от параметров. Как мне поможет в этом линк? Да никак. Мне теперь придётся отказаться не только от анонимного типа, но и вернуться к слоям.

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

Что можно было бы сделать на макросах?

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

Второй пункт также решается довольно просто. Раз мы знаем всё о запросе в компайл-тайм, то мы в состоянии сгенерировать наиболее эффективный код.

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

Пятый пункт решается элементарно добавлением атрибута withcache(blah-blah-blah).

Шестой. Тоже ничего невозможного. Более того, в компайл тайм можно было бы генерировать не один запрос, а, например, три. Один для админов совсем без фильтрации, один для пользователей с правами и ещё один для гостей. В рантайм было бы достаточно авторизировать пользователя и решить какой из запросов выполнять.

Что касается сложности написания библиотеки макросов подобной линку. Это не просто ложно, это очень сложно. Но! Кто сказал, что нам нужно писать именно такую библиотеку. Сложность решения напрямую зависит от попытки сделать функциональность универсальной. Например, универсальный качественный генератор SQL довольно сложная задача, которая должна учитывать множество деталей и нюансов. Но достаточно убрать эти детали и нюансы, завязаться на свою собственную специфику и генерация SQL превратится в простую задачу для школьников. И уж точно не придётся править компилятор для того, чтобы повторить возможности линка, т.к. никуда не надо будет проталкивать expression tree. Всё можно будет посчитать в компайл-тайм.

И самое главное, не нужно будет ждать 2-3 года до выхода VS 2008.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 20:29
Оценка: 31 (2) :)
Здравствуйте, AndrewVK, Вы писали:

AVK>К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.


Вообще-то, насколько я знаю, LISP стал таким монстром, в котором как в Греции все есть гораздо позже 70го года. Мне бы очень хотелось посмотреть на этот самый pattern-matching в LISP, если честно. В LISP (в CLOS) есть мультиметоды, которые покрывают ту часть задач, которую с пом. PM решают в Haskell — фактически это обеспечение полиморфизма. Другая часть задач, которую решает PM — а именно декомпозиция сложных структурных типов данных в лиспе нужна примерно также, как и газонокосилка на Марсе, ведь типов данных в нем, по большому счету, аж целых два: список и несписок. Поэтому-то PM-у просто нечего матчить, со всем можно справится стандартными комбинаторами. Что-то я не слышал, чтобы в LISP-овских макросах применялся PM.
Примитивный синтаксис и отсутствие необходимости возиться с типами вообще сильно облегчает создание макросистемы. Поэтому метапрограммирование и получило развитие первоначально в динамических языках. Создание приличной макросистемы в статическом языке — задача гораздо более нетривиальная.
Кроме того, тут ведь речь идет об индустрии, не так ли? Утверждается, что макросы, дескать, опробированы в 70-е годы индустрией, и все с ними теперь ясно. Вот только PL/I и макроассемблеры не имеют никакого отношения к макросам, а LISP не имеет никакого отношения к индустрии.
Динамические языки индустрия вообще не приняла. Единственный индустриальный динамический язык общего назначения, который я могу вот так сходу вспомнить — это Смолток, и нужно ли акцентировать внимание на том, что его судьба по сравнению с другими индустриальными средствами, мягко говоря, печальна?
Казалось бы, если индустрия так хорошо все это опробировала, то можно ведь привести ссылки на исследования. Тот же Gaperton любит приводить исследования, в которых с точностью до процента высчитывается превосходство Erlang над C++ по всем возможным показателям. Абстрагируемся от того, насколько они точны — в данном случае важно, что они есть. И если бы были соответствующие исследования по данной проблеме, он бы их нашел — я в нем не сомневаюсь. Но нет. Он рассказывает про какие-то макроассемблеры, которые не только не родственники, но и не однофамильцы. Все дело в том, что таким исследованиям неоткуда взяться. Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:29
Оценка:
Здравствуйте, mkizub, Вы писали:

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

Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.
Sapienti sat!
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.


А библиотеки как отлаживают? Cверяют ожидаемый выход данных с фактическим.
Так и макросы отлаживают. Сверяют ожидаемый сгенерированный код с фактически сгенерированным. Инструменты для анализа сгенерированого кода — есть. Они появляются вместе с компилятором, поскольку компиляторы отлаживать тоже надо.

По моему опыту — разницы практически никакой. Зато есть большое сходство между отладкой "закрытой" библиотеки (от которой нет исходников) и "закрытого" компилятора — в обоих случаях остаётся только материться
Опыт отладки макросов может дать, например, такая среда разработки как Eclipse. Только там плагины к IDE отлаживаются, а не макросы, но суть процесса та-же самая. Не пробовали к Eclipse плагины писать?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 20:33
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>А вот для макросов у нас отладчиков пока нормальных нет.


Макрос отлаживается тем же отладчиком что и любой другой код.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:36
Оценка:
Здравствуйте, IT, Вы писали:

IT>Во-первых, из-за кривой реализации баиндинга в ASP.NET, при работе с навороченными веб-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае мы нарываемся на рефлекшин со всеми вытекающими последствиями. Будут ли анонимные типы реализовывать ICustomTypeDescriptor? У меня есть на этот счёт определённые сомнения.

Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?

Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.

IT>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.

Кэшируем подготовленные запросы.

IT>В-пятых. Предположим, что я захотел добавить кеширование результата запроса в зависимости от параметров. Как мне поможет в этом линк? Да никак. Мне теперь придётся отказаться не только от анонимного типа, но и вернуться к слоям.

Эээ... А кэшировать на уровне провайдера нельзя?

IT>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.

А на уровне провайдера нельзя?

Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.

Хотя мне LINQ не нравится по другим причинам, но он не оправдание макросам.
Sapienti sat!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.

"Давно" не получится. Аннотации в яве появились считай что вчера
Собственно, именно AspectJ и аннотации я и имел в виду. Просто когда я 6 лет назад работал в AspectJ — аннотаций и в помине не было, и я им говорил, что "надо добавить пользовательские модификаторы/метки, иначе это хак чистой воды". На что мне ответили, что нихрена я не понимаю в крутизне AspectJ. Поэтому у меня очень специфическое отношение к AspectJ вообще, и интеллекту его создателя в частности. Когда они с Чарльзом Симони сделали фирму для продвижения Intentional Programming — я подумал "ну вот, наконец AOP будут применять в качестве определения операций, а не запутывания кода, и станет нормальной технологией". А потом Gregor ушёл из IP — я понял, что он полный даун, вместе с его AspectJ.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.