Спасибо за ваши усилия, интересно будет дальше почитать.
Но здается мне что за подобное надо по рукам бить (я о "вы пишете на ... а в универе установлен ...". Если вы в состоянии осилить кодогенератор пхп - значит можете и сам пхп по-человечески осилить. А превращать процесс дебага из "нашел ошибку -> исправил" в "сгенерировал -> нашел ошибку -> почесал мозг, как ее исправить в кодогенераторе чтоб код другой нормальный сгенерировал -> сгенерировал код" при знаниях пхп - неумно.
Не понял сути вашего поста. Я пока не пишу о преимуществах конкретных. Я пишу о подходах которые существуют и применяются. А они намного более совершенны того, что я написал. Перед нами есть живой пример - LINQ. Но если я приведу исходный и сгенерированный код, то мало кто разберется. Поэтому я стараюсь простыми вещами описывать данную отрасль. Если у вас есть более интересный подход - вы можете написать топик в этом разделе.
Linq типичный кодогенератор. Он генерирует более низкоуровневый код на основе более выоскоуровневого в зависимости от метаданных источника и способа взаимодействия с ним.
Мне кажется, что LINQ, всё-таки, это фреймворк абстракции от БД, наподобие перловых Class::DBI: и DBIx::*. Если нет, может у вас есть ссылки на странички с примерами?
Получается, для того чтобы воспользоваться кодогенераторами, необходимо сначала выучить язык кодогенератора.
1)Не лучше ли это время потратить на изучение того языка, на котором собираешься писать программы
2)Создание некоторого универсального кода, который можно преобразовать в код на любом произвольном языке программирования напоминает поиск философского камня. Не понятно зачем это нужно, зато понятно, что оптимальный код "умный" кодогенератор все равно не сгенерирует.
Раздел про метаданные вы намеренно проигнорировали? Подходов много, на любой вкус. Некоторые требуют знания языков, другие могут генерировать на основе метаданных, явлений, событий и т.п.
Генерация на основе метаданных - отличная абстракция от источника данных. Имея гибкий генератор (либо несколько генераторов) мы можем оптимальный генерировать код для конкретного источника данных и без труда сменить источник перегенерировав код с другой конфигурацией. Кстати, многоуровневая абстракция так же подходит для быстрой смены источников данных. В следующей статье я как раз сравню эти подходы.
Все это конечно красиво, но нужно ли менять источник данных? Если проектируют какую-либо систему, то под конкретные источники данных. Все равно будут проблемы при смене, как бы хороша система ни была. И при использовании минимальных возможностей всех поддерживаемых источников, мы теряем мощь одного определенного (например тот же mysql).
И не лучше ли просто разрабатывать сразу на специализированных системах, навроде Cache', где можно работать напрямую с данными?
Это чего получается тогда по вашим словам не имеет смысла учить C\C++, а учить ассемблер? Язык кодогенератора обычно находится на более высоком абстрактном уровне чем язык на котором генерируется код.
Честно говоря не согласен с LINQ и кодогенерацией... Linq - это расширение языка, которое компилируется в IL код. Если же про LINQ говорить как о кодогенерации, то тогда давайте возьмём все оставшиеся N конструкций языка C#...
Я про то, что смешно как то называвать например свойства, которые тоже генерятся в методы get_ и set_. Или анонимные методы, которые в превращаются в
[CompilerGenerated]
Метод {}
Вобщем считаю это чушью, потому что компиляция С#, VB.NET генерит IL код (ниразу не слышал, чтобы кто то называл это процессом кодогенерации). При компиляции C++, C, геренирует asm код с последующей компиляцией...
Прошу прощенья за сарказм, но, работать - разновидность жизни... А жизнь это разновидность существования. Зачем переходить к астракции без необходимости?
Вы ссылаетесь на источник, но при этом сами НЕ понимаете вопрос. Я бы вам хотел прояснить это, и всем людям, которые тоже ДОВЕРЯЮТ статьям, при этом отключают голову для анализа, и не разбираются в проблеме.
А теперь этапы компиляции:
1) Разбиение на токены
2) Проверка синтаксиса и семантики
3) Кодогенерация (например на asm)
4) Компиляция
И это только с моим скудным познанием компиляторов, который я ещё помню с университета, когда приходилось их писать. Уверен профессионалы укажут больше стадий. Но кодогенерация, как раз является частью процесса компиляции. И тут уже не поспоришь. НО если рассмативать компиляцию в общем виде, как перевод из одного в другой, то да можно так сказать, как написано в английском варианте. Но пожалуйста, голову то используйте, перед тем как давать ссылки на статьи. Их надо ПРАВИЛЬНО читать. Удачи.
Вот в странице Source code generation по вашей ссылке есть чудная цитата: "Parnas concluded that "automatic programming has always been an euphemism for programming in a higher-level language than was then available to the programmer.""
Это не к тому, что ваша тема неинтересна (наоборот очень даже интересует людей с 40х годов), а к теме используемой терминологии...
Господа, я понимаю что автора на хабре надо послать, унизить, обвинить в некомпетентности, но когда вы утверждаете что-то - вы хоть проверяйте в различных источниках это.
Вам наверное стоит просто более четко обьяснить народу о чем Вы собираетесь поведать. Сами ведь признаете, что кодогенерация - ну очень широкое понятие. И зачем Вы стараетесь, если Вам не нравится аудитория?
попробуйте почитать Сибела на http://gigamonkeys.com/book для CL или SICP вообще для всего (по последней, кстати, на itunes-u есть чудный и совершенно бесплатный курс лекций из беркли)
А по поводу статьи - с одной стороны не могу сказать ничего хорошего, потому что в этой части все примеры наиграны и должны решаться совершенно не методом кодогенерации, а с другой не могу сказать ничего плохого, ибо именно такую штуку я написал сам в своё время.
SICP обязательно почитайте. Он, кстати, давно есть на русском.
Если CL учить сложно, начните со Scheme, там очень быстрый вход.
Тема кодогенерации мне очень интересна, потому что сильно пересекается с темой DSL вообще и eDSL в частности. К сожалению, здесь мало об этом говорится.
За статьи спасибо! Они как минимум собирают интересный народ ;-)
Не знаю зачем меня заминусовали, никто мою идею не понял, поэтому объясню ещё раз. Я не придираюсь ко всей статье, я лишь хочу сказать, что это немного некорректно приводить ТАКОЙ пример LINQ как кодогенератора, а потом говорить, что компиляция это часть кодогенерации. Либо автор не совсем понимает и ещё не использовал LINQ в своих проектах. Я бы и слова не сказал, если бы привели пример ДЕЙСТВИТЕЛЬНОЙ кодогенерации например cпециальную утилиту КОДОГЕНЕРАЦИИ SqlMetal.exe. Зачем вводить тут людей в заблуждение, и расказывать какие то левые примеры кодогенерации LINQ, что вот этак конструкция сгенерила этот код, а эта вот этот. Это чушь, самую основную деталь LINQ to SQL автор почему то пропустил, а это самый главный пример, который можно привести если рассматривать LINQ. Я не понимаю также, почему автор выбрал именно LINQ в этом контексте, в котором он его использовал, так как можно было взять ЛЮБУЮ конструкцию любого языка программирования, и показать как она интерпретируется/компилируется в машинный/промежуточный код. В качестве примера указываю источник - Code Generation in LINQ to SQL (http://msdn2.microsoft.com/en-us/library…). Посмотрите на нормальный пример, а не притягивание за уши к статье того, в чём автор НЕ РАЗОБРАЛСЯ но очень бы хотел воткнуть, потому что это наверное модно.
Подходы к кодогенерации