Здравствуйте, IT, Вы писали:
IT>Это всё цветочки. Настоящие проблемы начинают вылезать при необходимости изменения генератора. Нужно перегенерировать все файлы. А значит вынуть их из VSS.
Это технические трудности которые можно обойти.
1. В системе контроля версий нужно хранить только мета-код и модель. Тогда и вынимать ничего не нужно будет.
2. Генерацию нужно сделать фазой предшествующией компиляции.
Тогда жить станет проще. Ну, а геморой тут в том, что ошибки генерации отлавливаются только при компиляции, а то и при отладке сгенерированного кода и порой бывает не просто найти в каком месте генератора ошибка.
Далее геморой в неуклюжести синтаксисса ХСЛТ и в том что он не заточен под генерацию кода. Ведь код нужно выравнивать и т.п. А ХСТЛ это делать не умеет.
Следующий гимор появляется когда ты хочешь что-то посчитать при генерации (точнее перед ней). Даже банальное формирование имен идентификаторов становится гемороем.
Следующий геморой перекрытие пространств имен. Если ты весь код генерируешь, то еще ничего. Но если ты вынужден вставлять ручные кускти...
Вот тут макросы в стиле Нэмерла рулят страшно. Ведь и контроль выше, и полноценный ЯП в руках, и гигееничность, и блоку рукопашного кода легко вставляются, и анализировать их можно.
В общем, ХСЛТ хорошо до тех пор пока под рукой нет нечто вроде Нэмерла.
IT>...Через месяц понадобилось поменять имя одной таблицы.
Тут оно как. Так если уж ты начал генерировать код, то останавливаться нельзя. Нужно определиться с моделью и пытаться никогда не дублировать ее. Так что если модель у тебя в ХМЛ, то и БД ты обязан генерировать по этому ХМЛ-ю. Иначе такой гимор, что "мама дорогая".
В Нэмерле ты можешь в качестве модели использовать просто БД. Но и в подходе основанном на ХМЛ ты тоже можешь сделать некое приложение которое будет читать модель из БД и генерировать ХМЛ по ней. Ну, а уже по ХМЛ можно будет генерировать код с использованием ХСЛТ. Вот только это лишнии стадии и геморой. Проще уж БД по ХМЛ генерировать.
IT> При настоящей compile-time генерации такого не может случиться в принципе.
Тут ты ошибашся. В данном случае геморой из-за непродуманности вопросов кодогенерации и моделирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Их класть туда не нужно, тогда и проблем не будет.
IT>> Но если кто-то что-то заблокировал, то начинается беготня и выяснение.
AVK>Пользуйтесь кошерными VCS, и ваши волосы (на попе) будут длинными и шелковистыми.
И все же проблем более чем достатчно. Например:
1. Если захчется вставлять рукописыный код, то гемороя сразу становися масса, так как для твоего генератора код является простым текстом.
2. Усложнен поиск ошибок кодогенерации, так как сгенероированный код ничем не связан с шаблонами.
3. ХСЛТ не полноценный ЯП и если что-то нужно посчитать и т.п., то прийдется делат вставке на другом ЯП, что усложняет процесс.
4. Отсуствие связие семантической информации приводит к невозможности выдвавать разумную диагностику ошибки становятся не очевидными и выявляются на более поздних стадиях.
5. Такой подход годится только для генерации обособленных модулей. Он не годится для встраивания микро-DSL-ей в базовый язык. Так например, на макросах Немерла можно встроить в оснвной язык декларативное описание негэкспов, ХМЛ-я и т.п. Ты же вынужден будешь писать такой код на более низком уровне.
Между тем приемуществ у ХСЛТ подхода по сравнению с Нэмероловским я пока не вижу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне применять удавалось. Но это неважно. Проблемы с интеграцией очевидны и столь же очевидно, что Nemerle их способен решить.
+1
AVK>Но это ведь не единственные проблемы. Модели у меня сейчас чаще всего представлены ввиде XML. Под каждую задачку своя модель. Проблема в том, что задачки растут, модельки усложняются. В результате фактически под каждую задачу рождается свой язык. И если я их еще правлю вполне эффективно, то другой народ из команды делает это очень неохотно, чаще просят меня что нибудь подправить.
Дык это очевидное следсвие невыразительности ХМЛ-я. Семантика в твоих ДСЛ-ях хорошая, а синтаксис никакой.
Помнишь ты прикрутил к CodeAnalizer-у в R# генерацию ХМЛ-я по АСТ? Это действительно было здорово, но читать полученный ХМЛ было еще хуже чем АСТ в виде классов C#. Между тем сам C# читать намного проще нежели АСТ. Это потому, что C# намного более выразителен и краток нежели АСТ или ХМЛ.
Так что тебе нужно заменить твой ХМЛ на нечто более выразительное. Ты и сам это пыташся сделать делая визуальные средства редактирования ХМЛ-ей для своих ДСЛ-ей. Так вот Нэмерл позволят как использовать ХМЛ в качестве модели, так и просто опредялять текстовый синтаксис долее выразительный нежели ХМЛ или эмуляция в ООП-виде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, WolfHound, Вы писали:
AVK>>И если я их еще правлю вполне эффективно, то другой народ из команды делает это очень неохотно, чаще просят меня что нибудь подправить. WH>Ибо долбаться с этим угробищем ака XSLT никто не хочет. Немерле в этом плане значительно дружественней.
Ну, надо признать, что возиться то приходится не с ХСЛТ, а с ХМЛ. ХМЛ модели конечно значительно проще нежели ХСЛТ его изменяющий. Но и но не достаточно выразителен, чтобы народ хотел править его руками. Отсюда такая потребность в дизайнерах. А была бы возможность задавать свой синтаксис, то глядишь и ндобности в дизайнерах было бы меньше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
AVK>>Их класть туда не нужно, тогда и проблем не будет.
IT>Если их туда не класть, то студия будет спрашивать при каждом коммите "А может всё-таки покладём?"
Отключи интеграцию, спрашивать не будет (тем паче что в Nemerle интеграция еще нескоро появится). Вобщем все сводится к п.2
AVK>>Пользуйтесь кошерными VCS, и ваши волосы (на попе) будут длинными и шелковистыми.
IT>Это уж что клиент пожелает.
Так тоже не проблема — ставишь себе нормальный и настраиваешь автоматический коммит в VSS.
IT> Объяснить ему, что нас не устраивает стандартный VCS из-за precompile-time генерации можно
VSS угробище не из-за генерации, а по жизни. Проблемы с генераторами не самая мерзкая его особенность.
IT>, но выглядит это не как решение проблемы, а как способ запинать её в угол и завалить старыми тряпками чтобы видно не было.
Ну мучься дальше .
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Помнишь ты прикрутил к CodeAnalizer-у в R# генерацию ХМЛ-я по АСТ? Это действительно было здорово, но читать полученный ХМЛ было еще хуже чем АСТ в виде классов C#. Между тем сам C# читать намного проще нежели АСТ. Это потому, что C# намного более выразителен и краток нежели АСТ или ХМЛ.
VD>Так что тебе нужно заменить твой ХМЛ на нечто более выразительное. Ты и сам это пыташся сделать делая визуальные средства редактирования ХМЛ-ей для своих ДСЛ-ей. Так вот Нэмерл позволят как использовать ХМЛ в качестве модели, так и просто опредялять текстовый синтаксис долее выразительный нежели ХМЛ или эмуляция в ООП-виде.
Насчет выразительности ты возможно и прав. Но я совсем не уверен, что проблема в этом.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>И все же проблем более чем достатчно. Например: VD>1. Если захчется вставлять рукописыный код, то гемороя сразу становися масса, так как для твоего генератора код является простым текстом.
Я тоже раньше так думал. И думал что без парсеров и встраивания в язык нормальная кодогенерация невозможна.
А потом оказалось что потребность руками что то дописывать в автогенеренный код свидетельствует на некачественном разделении на аспекты. К примеру добавлять метод WriteXml к объекту графа не есть правильно, потому что завтра понадобится еще куда нибудь сериализовать — что ж, менять публичный интерфейс и генераторы? Куда разумнее сделать генератор внешним классом, а для классов графа сделать модель, позволяющую сериализовать этот граф некоторому абстрактному сериализатору. В этом случае никакого желания править автогенеренный код сериализатора не возникнет, как не возникает желание править код, который сейчас генерит фреймворковский XmlSerializer.
Disclaimer: все вышесказанное, разумеется, основано на моих задачах. На других задачах все может быть по другому.
VD>5. Такой подход годится только для генерации обособленных модулей. Он не годится для встраивания микро-DSL-ей в базовый язык.
Не годится. Но меня собственно сама идея этих DSL, встроенных в основной языке, смущает.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Я тоже раньше так думал. И думал что без парсеров и встраивания в язык нормальная кодогенерация невозможна. AVK>А потом оказалось что потребность руками что то дописывать в автогенеренный код свидетельствует на некачественном разделении на аспекты.
Дык это потому, что ты чтобы уйти от геморроя сам ограничил себя. Это нормально учитывая скдность средств, но зачем же себя ограничивать если нужные средства таки пояляются?
AVK> К примеру добавлять метод WriteXml к объекту графа не есть правильно, потому что завтра понадобится еще куда нибудь сериализовать — что ж, менять публичный интерфейс и генераторы?
Зависит...
Если сериализация не затрагивает внутреннего представления, то можно сразу организовать ее в виде внешних процедур. Тогда будет достаточно сделать второй генератор. Или вообще сделать исходный генератор универсальным.
Если же сериализовать нужно внутренее представление, то прийдется нарацивать публичные интерфейсы. Но все равно изменять что-то прийдется.
AVK>Disclaimer: все вышесказанное, разумеется, основано на моих задачах. На других задачах все может быть по другому.
Вот именн. Для тебя приемлемо сделать такой публичный интерфейс чтобы с него можно было сериаилизоват и востановить состояние. Но это ведь не всегда возможно. Да и один фиг сама сериализация требует генератора кода или будет не эффективной.
VD>>5. Такой подход годится только для генерации обособленных модулей. Он не годится для встраивания микро-DSL-ей в базовый язык.
AVK>Не годится. Но меня собственно сама идея этих DSL, встроенных в основной языке, смущает.
А меня нет. Погляди примеры Нэмероловцев и сам убедишся. Они уже сделали кучу классных ДСЛ-ей и мелких улучшений языка.
Примерами мелких ДСЛ-ей могут служить ДСЛ-и для работы с рекеспами, БД, строками.
А примерами мелких улучшений операторы вроде <--> меняющих местами значения (причем не только в простых случаях когда значения являются перменными).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
IT>Если их туда не класть, то студия будет спрашивать при каждом коммите "А может всё-таки покладём?"
IT, в данном случае ты прото используешь кривой сорс-контролв. Прямому вообще не нужна поддежка студии. Да и не нужно генерируемый код в него класть. Тебе же студия не предлагает тестовые проекты в сорс-конрол запихнуть?
IT>Это уж что клиент пожелает. Объяснить ему, что нас не устраивает стандартный VCS из-за precompile-time генерации можно, но выглядит это не как решение проблемы, а как способ запинать её в угол и завалить старыми тряпками чтобы видно не было.
И тем неменее это плохой аргумент. Однако и хороших хватает.
Кстати, возмжность получить исходинки по сгенерированному коду очень полезная возможность. Если бы небыло Рефлектора, то я бы настоятельно желал бы получить возможность генерации развернутой версии проекта (т.е. версии после всех мета-преобразований). Это может резко упростить отладку самих макросов. Однако вроде бы в Нэмерле что-то подобное есть. Да и если даже нет, то не трудно сделать макрос который сделает это. Так что тут опасаться нечего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Если XSLT править это понятно, это в любом случае моя зона ответственности. Я про правку XML.
Кстати, думаю, что твое начальство было бы только радо если бы и другие смогли бы если не править, то хотя бы проще понимать что делает код трансформации. Это и тебе жизнь упростило бы. Ведь вместо туманных описаний что не так, ты бы зачастую получал бы информацию о том, в каком месте макроса проблемы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
AVK>>А потом оказалось что потребность руками что то дописывать в автогенеренный код свидетельствует на некачественном разделении на аспекты.
VD>Дык это потому, что ты чтобы уйти от геморроя сам ограничил себя. Это нормально учитывая скдность средств, но зачем же себя ограничивать если нужные средства таки пояляются?
Качественное разделение на аспекты, оно в любом случае рулит. Если средство Х позволяет писать кашеобразный код это совсем не означает, что я не пишу такой код только потому что у меня нет средства Х. Скорее наоборот — автогенерация скрадывает подобные косяки. В рукописном коде подобное сразу же по рукам давать начинает за счет появляющегося объема ручной работы при каждом изменении одного из аспектов.
VD>Если же сериализовать нужно внутренее представление, то прийдется нарацивать публичные интерфейсы.
Но при этом они, в отличие от прямого кода, не будут завязаны на конкретику аспекта. Возьми тот же визитор — ты же не специфицируешь в коде графа заморочки конкретных визиторов.
AVK>>Не годится. Но меня собственно сама идея этих DSL, встроенных в основной языке, смущает.
VD>А меня нет. Погляди примеры Нэмероловцев и сам убедишся.
Да глядел я их, глядел. Не убедило.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Очень понравился мне комментарий одного товарища из ЖЖ на мою публикацию о Nemerle, так понравился, что рука к нагану потянулась:
Кхм... Помню высказывание одно очень умное. Точнее дословно не помню и автора с хожу не назову, но суть такая — чем активнее используются макросы в языке программирования, тем хуже и менее функционален этот язык. Уже из этого следует, что Nemerle — полный отстой! А если вы всё-таки хотите ну совсем другую парадигму, а ещё лучше — программирование без парадигм, то посмотрите в сторону ассемлера! Самый чудесный язык программирования на мой взгляд!
Ей Богу, откуда такие персонажи беруться?
... << RSDN@Home 1.1.4 stable rev. 510>>
ДЭ!
Re[23]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
IT>>Это уж что клиент пожелает. Объяснить ему, что нас не устраивает стандартный VCS из-за precompile-time генерации можно, но выглядит это не как решение проблемы, а как способ запинать её в угол и завалить старыми тряпками чтобы видно не было.
VD>И тем неменее это плохой аргумент. Однако и хороших хватает.
Это — не плохой аргумент. Это — жизнь. В середине проекта, в котором участвует только девелоперов с полсотни, менять VCS из-за проблем с кодогенерацией в одной из шести команд — это безумие. Никто на это не пойдёт. Да и худо бедно до этого работали, пока не начали умничать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
IT>> При настоящей compile-time генерации такого не может случиться в принципе.
VD>Тут ты ошибашся. В данном случае геморой из-за непродуманности вопросов кодогенерации и моделирования.
О продуманности речи не идёт. Там такие баталии на эту тему были, что лучше не упоминать. А вот то, что такое не возможно в случае compile-time генерации — это факт. Проект просто не собрался бы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, little_alex, Вы писали:
_>>Вообще-то такая фукциональность доступна в виде библиотек. Да и в коммерческих реализициях есть подобная фунциональность.
VD>Эти библиотеки должны быть по сложности равноценны компилятору. И это при том, что комапиляторы Лиспа сами не обеспечивают даже простого вывода типов. В общем, это больше похоже на сказку.
_>>Я не утверждал, что Lisp лучше или хуже Нэмерле, но доступ к семантической информации в Lisp точно есть.
VD>Да она сама в Лиспе под большим вопросом. Язык то по сути динамически типизированный. Ну, как ты сможешь определить что некий парамерт это получает INT если в него передано сложное выражение?
(declare (type integer arg)) ?
Re[2]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
IT>Если следовать его логике, то DSL'и — это полный отстой.
Тут же не его логика, тут очень авторитетное и точное высказывание очень известного специалиста: "высказывание одно очень умное. Точнее дословно не помню и автора с хожу не назову".
Вот, только, все на этом форуме и, только на моей памяти, уже не первый месяц DSL'ями страдают и по ним плачут, эх господа, не понимате вы истинной Красоты и Свободы, ай да все на "ассемлер". Back to the primitive! We're back to set it free!!! (C) Soulfly. Я умывю руки. (надо бы себе смайлик специальный вместо этой фразы завести)
Если нам не помогут, то мы тоже никого не пощадим.
