Re[6]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 14:03
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?


Большую часть да, в том числе и с помощью Немерле.

AF>Вах, я потрясен твоим опытом.


Ничего потрясающего в нем нет, чтобы просто побаловаться много времени не нужно. Когда то, несколько лет назад, еще до того как Влад тут всем начал МП пиарить, мне эта тема была интересна. Потом я интерес потерял.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 26.12.08 14:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Большую часть да, в том числе и с помощью Немерле.


Какую часть, и какие точно с Немерле?

AVK>Ничего потрясающего в нем нет, чтобы просто побаловаться много времени не нужно. Когда то, несколько лет назад, еще до того как Влад тут всем начал МП пиарить, мне эта тема была интересна. Потом я интерес потерял.


Побаловаться и использовать в реальной работе — совсем разные вещи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 26.12.08 14:33
Оценка:
Здравствуйте, Andrei F., Вы писали:

L>>Целиком и полностью поддерживаю по всем пунктам!


AF>"А я еще больше люблю господина ПЖ!" (С)

AF>

Кто это?
Re[4]: Что меня не устраивает в МП в Nemerle
От: Gajdalager Украина  
Дата: 26.12.08 14:36
Оценка:
Здравствуйте, Lloyd, Вы писали:

AF>>"А я еще больше люблю господина ПЖ!" (С)

AF>>

L>Кто это?


Можно я скажу? Можно я? http://ru.wikipedia.org/wiki/Кин-дза-дза!_(фильм)
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Porcupine Tree — Way Out Of Here
Re[4]: Что меня не устраивает в МП в Nemerle
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.12.08 14:36
Оценка:
Здравствуйте, Lloyd, Вы писали:
AF>>"А я еще больше люблю господина ПЖ!" (С)
AF>>

L>Кто это?

http://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B4%D0%B8%D1%84%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D1%88%D1%82%D0%B0%D0%BD%D0%BE%D0%B2
и солнце б утром не вставало, когда бы не было меня
Re[5]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 26.12.08 14:42
Оценка: :))
Здравствуйте, Serginio1, Вы писали:

AF>>>"А я еще больше люблю господина ПЖ!" (С)

AF>>>

L>>Кто это?

S>http://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B4%D0%B8%D1%84%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D1%88%D1%82%D0%B0%D0%BD%D0%BE%D0%B2

Не, гипотеза не верна. т.к. из нее с необходимостью следовало бы, что и перед Top 0 rsdn-а я тоже должен был делать "Ку", а это, мягко говоря не совсем так.
Re[6]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 26.12.08 15:03
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Не, гипотеза не верна. т.к. из нее с необходимостью следовало бы, что и перед Top 0 rsdn-а я тоже должен был делать "Ку", а это, мягко говоря не совсем так.


Может потому что он ханудянин а не плюканин?
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[8]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 15:06
Оценка:
Здравствуйте, Andrei F., Вы писали:

AVK>>Большую часть да, в том числе и с помощью Немерле.


AF>Какую часть, и какие точно с Немерле?


Больше всего меня тогда интересовал п. 4. п.1, понятное дело, использует сам Nemerle (его стандартная библиотека макросов). п2 сам, вроде бы, ничего не делал, но смотрел на генератор парсеров, который делал товаришь с ником что то там про консоль. С п.5 в основном баловался без конкретной цели, смотрел, что да как.

AF>Побаловаться и использовать в реальной работе — совсем разные вещи.


Безусловно. Но, уж извини, использовать в реальной работе вещи, которые мне после ознакомления не показались для этого пригодными, я не буду (да и не даст мне этого сделать никто). На свете много всяких интересных штук.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[4]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 17:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


VD>>Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова.

S>Это если не удалось хорошо распилить код при помощи partial классов.

Ага. Только такое распиливание может привести к охринительному геморрою. По сравнению с парметром — это может оказаться оверкилом.

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

VD>>Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).
S>Вот тут (см. выделенное) есть некоторые сомнения. В том смысле, что если у тебя возникает т.н. one-off ситуация, то есть что-то там нужно подшаманить ровно в одном месте, то это проще всего подшаманить ровно в этом одном месте. Подшаманивание генератора рискует дать труднопредсказуемые эффекты в других местах, где поведение уже отлажено.

Сомнениия высасоны из пальца?

S>Я не могу сходу придумать реалистичный пример, но нутром чую, что за ними дело таки не станет — только начни реальное применение. И AVK ровно об этом говорит.


А я нутром не чую. При этом у меня опыт создания макросов довольно большой.

S>Генерировать код — нетривиальная задача.


Это зависит от задачи и инструментов. Генерировать не тривиальные вещи — не тривильно (что в общем-то естественно). Наличие хороших инструментов позволяет простить эту задачу.
Получается, что макры по любому рулят. Или нужно отказываться от генерации кода, как первопричины проблемы. Но при этом скорее всего решение будет во много раз сложнее и уж наверняка его будет тяжело поддерживать и развивать, так как будет куча дублирующегося кода.

S>Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.


Допустим, но это не генерация кода общего назначения. Как раз макросы здесь мало что дают. Разве что сама модель описана с их помощью.

S>И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.


Откровенно говоря — это все не конкретные какие-то рассуждения. Слишком много нюансов. Правильно спроектированный генератор не должен приодить к проблемам при изменении модели или свойств генерируемого кода. Тем более, что конечная модель у такого генератора — это скорее всего текст (или на худой конец какое-то АСТ вроде System.Linq.Expressions.Expression).

В любом случае менять сгенерированный текст — это самое хреновое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 17:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Но с другой стороны возможен компромиссный вариант, когда мы делаем незначительное изменение генератора (например, всего лишь добавляем вызов partial метода) и получаем тем самым возможность сделать ручное изменение, которое не пропадёт после повторной генерации исходников.

S>Речь о том, что это не всегда возможно.

Кто это придумал?

Это невозможно только в одном случае, если у тебя нет исходников макроса. А же фигня будет с мета-программой написанной другими. Тогда прийдется править сгенерированный код. Ну, так можно и сборку подпачить. Но все это уже методы разработки за которые надо бить железной линейкой по пальцам.

Ну, и главное что хочется заметить. Вы придумываете какие-то частные отмазки "а если что?...", чтобы обосновать не желательность применения макросов в общем случае. Мне это кажется просто не разумным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 17:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

AVK>>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


AF>+1, в этом есть смысл


А какой в этом смысл?
Продемонстрируй, плиз, хотя бы один ДСЛ сужающий возможности исходного языка.

ДСЛ — это язык предметной области. Его задача описывать проблему в наиболее подходящих терминах. Например, регулярные выражения — это наиболее компактное (чего нельзя сказать о его понятности) описание грамматики. Вряд ли при этом можно говорить о сужении возможности некого универсального языка. И такая картина наблюдается во многих ДСЛ-я. Обычно встроенный ДСЛ предлагает новый синтаксис или семантику (иную интерпретацию имеющегося синтаксиса), а средства поддержки ДСЛ преобразуют исходных ДСЛ в некоторый набор инструкций универсального языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 17:18
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:


AF>>То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?

AVK>Большую часть да, в том числе и с помощью Немерле.

И не разу ни к кому не обратился с вопросом? Ну, ты просто гений! Я бы так не смог.

AF>>Вах, я потрясен твоим опытом.


AVK>Ничего потрясающего в нем нет, чтобы просто побаловаться много времени не нужно. Когда то, несколько лет назад, еще до того как Влад тут всем начал МП пиарить, мне эта тема была интересна. Потом я интерес потерял.


Казалось бы причем тут Немерле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 17:58
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD> Ну, ты просто гений! Я бы так не смог.


Да, ненадолго тебя хватило.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 18:13
Оценка: 3 (1) +1 -1
Здравствуйте, AndrewVK, Вы писали:

К сожалению, в этом рассказе, я не увидел две вещи которые вроде бы должны были присутствовать в данной теме.
А именно:
1. Я не увидел последовательный анализа проблемы.
2. Я не увидел ни одного конкретного слова про Nemerle (хотя вроде как ему и посвящена тема).
Посему не ясно с чем дискутировать.
Все что я могу — это разобрать разрозненные (на мой взгляд) высказывания и дополнить их или дать свои комментарии.

AVK>1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.


В двух словах этот пункт говорит — "Я против синтаксических расширений потому как людей надо учить".
Сразу возникают два вопроса:
1. А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка? Есть:
* Макросы уровня выражений. Их можно использовать как обычную функцию, но при этом они могут делать значительно больше чем просто фунции, так как выполняются во время компиляции и могут получать доступ как компилируемому коду (и проекту), так и к любым ресурсом в системе. Например, $-строка в Немерле — это макрос который не изменяет синтаксис. Или пример макроса который позволяет в мгновение локализовать локализовать всю программу не возясь при этом с АПИ ресурсов.
* Макро-атрибуты. Это такие же атрибуты как и те что автор темы привык использовать в C#. Только во время компиляции можно вместо них выполнить некоторые действия с проектом или его отдельной частью (например, функцией). Например, макросы из файла DesignPatterns.n: ProxyPublicMembers, AbstractFactory и Aggregate позволяют автоматизировать использование соответствующих паттернов проектирования. Это позволяет не заниматься копипэстом, а декларативно описывать желаемый паттерн и получать его реализацию автоматически. Более подробно об этих макросах можно прочесть здесь. Другими примерами могут служить макро-атрибуты Memoize (позволяющий автоматически кэшировать результаты вычисления для заднных аргументов методов), http://nemerle.org/Record_macroздесь]Record (который позволяет не писать конструкторы вручную).
Создается впечатление, что автор или не знает об этом, или пытается намеренно скрыть такую возможность, так как эта информация вырывается из стройного ряда его изложения.
2. Рассказы о том, что люди плохо учат новый синтаксис — это страшилки для не посвященных. Реально макросы вводящие новый синтаксис упрощают реализацию тех или иных участков программы. Например, такие макросы могут заменять использование громоздкого паттерна на компактный и интуитивно понятный код. Тут даже за примерами ходить не нужно. Конструкции "foreach, using, lock" которые в C# являются встроенными в Немерле являются макросами. Все кто использовал эти конструкции могут представить как было бы неприятно жить без подобных фенечек. Но в языке есть далеко не все, что хочется иметь. Скажем конструкция аналогичная using очень часто нужна когда нужно что-то на время активизировать, а потом, при раскрутке стека отключить. Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.
Где здесь та самая кривая обучения о которой ведет рассуждения автор? Я ее не вижу. Конструкция очевидна, интуитивно понятна и не требует дополнительного описания. А не понятные можно просто не использовать. Это ни чем не отличается от классов и методов с непнятными названиями или от методов с тучей непонятных параметров. Просто там где сейчас уродливый код мы можем написать чистый и понятный код.
Скажу больше. Позиция автора — это чистой воды обман. Не знаю уж осознанный или нет, но обман. Кривая обучения не снизится если в проекте не будут использоваться новые синтаксические конструкции. Она повысится! Почему? Да потому, что обучается человек прикладной логике используемой в программе. А ее тем проще понять чем она проще. И если что-то можно выразить специальным синтаксисом значительно проще чем без него будет проще и понять.

AVK>При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.


Причем тут какой-то конкретный язык я так и не понял.

Времени нет. Так что продолжу разбор полетов позже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 26.12.08 18:23
Оценка:
Здравствуйте, VladD2, Вы писали:

А мой пост
Автор: alvas
Дата: 26.12.08
можешь прокомментировать?
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[2]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 18:28
Оценка: +1 -1 :)
Здравствуйте, VladD2, Вы писали:

VD>1. А автор темы вообще знает


VD>Позиция автора — это чистой воды обман.


Ясно. В лес.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 26.12.08 21:19
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос:

A>>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
Есть даже два.
Почему это не нужно конкретно AVK:

Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Почему этого не стал делать MS, и почему это в принципе может быть не очень здорово:

На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.
При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.
Итого — внесение изменений в компилятор для улучшения языка лично для меня с точки зрения промышленного программирования малополезно (при этом побаловаться для проектов, рассчитаных на одну-две хари фо фан я как бы и не против).

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 26.12.08 22:43
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD> Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.


Например в языках с развитой системой типов это делается обычной функцией. Зачем нужен макрос тут?
Re[9]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 23:30
Оценка: -1 :))
Здравствуйте, AndrewVK, Вы писали:

VD>> Ну, ты просто гений! Я бы так не смог.


AVK>Да, ненадолго тебя хватило.


Ну, вот... и похвалить нельзя.
Сразу ищут в этом подвох. А я искренне восхищаюсь тобой. Вот IT сам справиться не мог. И я не смог. И никто не смог. А ты смог! Причем смог не просто разобраться, но и сделать верные выводы. Это дорогого стоит и позволяет рассуждать о предмете глубоко и интересно.

Да и как по другому? Ведь если не верить твоим словам, то придется подозревать тебя в том, что ты говоришь не правду. А это конечно оскорбительно и безосновательно. Так что приходится только верить и восхищаться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 01:07
Оценка: 1 (1) +1 -2
Здравствуйте, AndrewVK, Вы писали:

Итак, автор темы, как я предполагал, нашел в первом же моем вопросе "А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка?" фатальный недостаток.

Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.
Приношу ему свои извинения. Это было сказано не со зла, а исключительно потому, что этот вопрос бы старательно обойден автором темы стороной. Я думал, что автор не знает данной тонкости, но это
Автор: AndrewVK
Дата: 26.12.08
сообщение меня убедила в обратно.
Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования.


Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
Обратимся за разъяснениями к Википедии.
http://ru.wikipedia.org/wiki/Предметно-ориентированный язык программирования
Предметно-ориентированный язык программирования (англ. domain-specific programming language, domain-specific language, DSL) — язык программирования, специально разработанный для решения определённого круга задач, в отличие от языков программирования общего назначения, например C, или языков моделирования общего назначения наподобие UML. Например языки Postscript, SQL и др.

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

AVK>И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


Продолжим разбираться в терминах. Итак DSL-и делятся на внешние и встроенные.
Пример внешнего ДСЛЯ-я файлы спецификации YACC и LEX. Это независимые DSL-и описывающие грамматику и синтаксис некоторого (конкретного) языка программирования которые превращаются в код (на языке общего назначения) парсера и лексере с помощью отдельной (внешней) мета-программ. Внешним он является, так как не встроен в другой язык, а живет своей отдельной жизнью.
Внутренний DSL (EDSL или DSLE) живет внутри другого языка. Примером внутреннего DSL могут являться: регулярные выражения, LINQ-запросы, $-строки (Nemerle, PHP или Руби), всевозможные спецификации (например, спецификации O/R-отображения на основе пользовательских атрибутов) и многое другое.
Удобстово встроенных ДСЛ-ей заключается в том, что они могут тесно взаимодействовать с языком общего назначения (ЯОН) в который они встроены. Кроме того ЯОН поддерживающие разработку встроены ДСЛ-ей (такие как Немерле) мгоут значительно облегчать создание встроенных ДСЛ-ей.

Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.

Немерел как раз такой язык. Возможность задания нового синтаксиса — одна из базовых фич макросов. Новая же семантика достигается средствами мета-программирования. Макрос принимает в качестве параметров код в виде AST и позволяет сгенерировать код который будет подставлен вместо вызова макроса. При этом макрос может использовать входные параметры как для включения их в выходной код, так и для получения некоторой дополнительной формации. Например, макрос foreach (хотя это по сути не ДСЛ, но он отлично демонстрирует принцип) получает на вход код коллекции, код описывающий переменную в которую будет помещено значение текущего элемента и код тела цикла. Макрос получает информацию о типе коллекции и генерирует специализированный код для массивов, списков, пртерна этумератор и интерфейсов энумератор. Код тела цикла подставляется в генерируемый код. В результате мы имеем высокопроизводительные реализации циклов для часто встречающихся коллекций, плюс понятные сообщения об ошибках и возможность дальнейшего развития этого макроса. Так foreach кроме всего расширен возможностью сопоставления с образцом и фильтрации данных. Что, многие разобравшиеся с языком, находят очень удобным.
Точно так же можно делать и ДСЛ-и. Язык предоставляет исключительную гибкость для их реализации. На сегодня Немерле предоставляет одну из лучших инфрастркутур для создания встроенных ДСЛ-ей в статически типизированных языках. Конкурировать с ним могут только Лисп и Хаскель. Причем у Немерле есть серьезные преимущества перед обоими. В прочем, ТемплэйтХаскель испльзует очень похожий на немерловый подход.

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


Короче не всегда быстрее и уж точно не всегда правильнее.
MPS, DSL Tools, Oslo — это как минимум не конкуренты Немерле хотя бы потому, что это средства создания внешних ДСЛ-ей.

Несомненно каждый подход имеет право на существование. Но только в области своего применения.
Скажем DSL Tools — это по сути средство создания визуальных моделлеров таких как UML, ER или диаграмм классов из VS.
Интересно, что Немерле может весьма эффективно применяться совместно с ним для генерации кода по модели. Обратное не имеет смысла. В общем, это разные инструменты которые можно использовать вместе.
MPS — это отдельная песня. Это RAD-средство создания внешних ДСЛ-ей. По возможностям от оно более ограничено нежели немерловые макросы хоят бы потому, что не может использовать мета-информацию о типах языка для которого производится генерация и тем, что MPS создает только внешние ДСЛ-и.
Но надо признать, что во многом MPS — это конкурент Немерле. Причем в отличии от других данный конкурент предлагает весьма интересные средства и подходы.
Осло — это вообще мутант предлагающий писать внешние ДСЛ-и на основе ХМЛ и весьма странных средств трансформации.

Короче, все перечисленные средства как-минимум не умеют делать то, что умеет делать Немрле. А по жизни являются узко специализированными решениями.

AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


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

Да, несомненно. В визардах используется генерация код. И несомненно она там обычно очень примитивная. Но на визардах свет не закачивается.
Есть куча задач требующих генерации кода. И, кстати — эти задачи называются мета-программированием, как бы автор темы в это не верил.
Более того, зачастую нужда в визардах исчезает если мы имеем в своем арсенале мощные средства мета-программирования.
Так же пропадает и нужда в кодогенераторах.
Например, в проектах C# и VB.NET ресурсные файлы генерируются визуальным интерфейсом встроенным в VS. Он формирует ХМЛ-файл с описанием ресурсов. Но ХМЛ-файл нельзя использовать их программы. В программе нужно иметь код который прочел бы ресурсы из исполняемого модуля и представил бы их в удобном для программы виде. Для этого в VS придумали весьма кривое решение — Custom Tool. Это кодогенератор создаваемый на дотнет-языке и ассоциируемый (в реестре) с расширением файла. Когда Студия производит запись файла, она вызывает ассоциированный с ним компонент и тот генерирует код на нужном языке. Кривость данного решения очевидно. Ведь без студии мы не можем запустить данный генератор. К тому же создание такого генератора весьма не тривиальная задача.
Немерле позволяет создать макрос читающих описание ресурсов в ХМЛ и генерирующий классы-обертки которые становятся доступными даже в во время разработки. Данный макрос одинаково работает как при компиляции, так и в дизайн-тайме. При этом сложность создания такого макроса на порядок ниже нежели генератора на обычном языке, так как при этом используется вся мощь мета-подсистемы Немерле. Описанный макрос создал человек не являющийся гуру в Немерле. При этом ему понадобилось всего пара советов.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.


Этот пункт я вообще понять не могу. С одной стороны требуется генерировать код, но так как это сложнее его написания вручную (кстати — это еще почему?), то мы просто отказываемся от генерации и пишем код вручную. Другими словами мы отказываемся от самой цели. Чудесный пример того как человек заблудился в трех соснах.

Возможно имелось в виду, что проще написать программу которая с помощью какого-нибудь StringBuilder-а и какой-то там матери сгенерирует нетривиальный код в виде строк?
Спешу заверить, что сгенерировать код с помощью квази-цитирования в сто раз проще. При этом доступна декомпозиция кода с помощью квази-цитат и вся мощь ФП, так как од по сути есть набор списков (дерево состоящее из списков).

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле.


Не "неверно", а 100%. Только причем тут АОП? BLToolkit — это типичный пример встроенного DSL предназначенного для описания и организации DAL (уровня абстрагирования доступа к данным) реализованного на основе техники мета-программирования. Только IT использовал не продвинутые средства мета-программирования Немерле, а дико низкоуровневый Sustem.Reflectin.Emit (т.е. генерацию IL-а). Это дико усложнило задачу. Так, что надо отдать должное мастерству и упорству IT который сумел создать такую мощьную библиотеку столь неудобными для этого и низкоуровневыми средствами.
Кстати, BLToolkit отличный пример DSL-я не реализвемого средствами перечисленных автором темы, идеологически более правильных (по его словам) MPS, DSL Tools и Oslo. Все дело в том, что BLToolkit нуждается в информации о типах конкретных структур данных, а это невозможно без специального API данные для которого генерируются компилятором. Для BLToolkit такими данными являются данные рефлексии генерируемые компилятором и доступные в рантайме. В Немерле все те же данные можно получить во время компиялции, что с одной стороны увеличит быстродействие, так как не надо будет компилировать код в рантайме анализируя структуры данных, а с другой стороны его было бы проще реализовать так как генерировать код по средством квази-цитирования в сто раз проще.

AVK> Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню:


Да не стоит. Собственно я знаю, что в задачи автора темы входила генерация типов по описанию хранимому в ХМЛ-файлах которое производилось во время развертывания приложения на сервере.
Это интересный подход, но его тоже можно осуществить на макросах если просто запускать компиляцию прикладных сборок во время развертывания. Точно так же делал и автор. Только он сначала генерировал код с помощью XSLT, а потом компилировал его стандартным компилятором C#.

AVK>инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Если речь идет именно об модификации скомпилированных сборок, то конечно Немерле тут не поможет. Однако, как раз модификация скомпилированых сборок обычно делается от бедности средств времени компиляции. Скажем такие стандартные задачи АОП как логирование, профилирование и добавление аспектов намного удобнее делать во время компиляции.

К тому же никто не запрещает использовать средства инструментирования и вместе со средствами мета-программирования, каковым является Немерле. Зачем же противопоставлять эти подходы?

AVK>P.S. Еще раз, если кто то в корне со мной не согласен, прежде чем бросаться писать возмущенный ответ и разгромить меня в пух и прах, обратите внимание на наличие и содержание дисклеймера.


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

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