Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Примеры MVC фреймворков: RobyOnRails, CakePHP.
RobyOnRails наше всё!
по-моему компиляция - не то же самое что кодогенерация. генерация хтмл-кода разными языками программирования - тоже очень сомнительно, что этот пример подходит к остальным
общее впечатление - вообще непонятно о какой именно генерации хочет говорить автор, потому как примеры все очень слабо подходят друг к другу.
Кодогенерация многогранна. Я постарался показать ее с разных сторон.
за двумя зайцами :) . примеры написаны с точки зрения многогранности кодогенерации, а цель поставленная - показать полезность кодогенерации как единого целого
Цель именно данной статьи - показать где она используется (читайте заголовок). О полезности будут другие статьи.
1. Спору нет, кодогенерация вещь несомненно полезная по одной простой причине: она позволяет поднять уровень абстракции выше, разрабатывать приложение оперируя моделью в которой меньше технических деталей но больше бизнес логики. То есть так, как лучше понятно людям, а не компьютерам.
2. Но CodeSmith это самый уродливый кодогенератор который можно было придумать. И эта поделка еще стоит денег. Для тех кто не в теме, он использует ASP-подобный язык шаблонов. Представьте себе, что у вас забрали ваш любимый MVC web framework а в замен оставили "старый добрый" PHP, APS или JSP из 90-х, и ваше веб приложение — это каша из HTML фрагментов и скриптлетов. Вот так же выглядят шаблоны CodeSmith — текст в перемешку с C# кодом. Брррр. Если не понятно, то проблема в том, что приходится генерировать структурированный код на языке программирования высокого уровня пользуясь шаблонами написанными на языке в котором нет средств для описания структур.
Оба утверждения основаны на личном опыте, в основном рабочем проекте используется и кодогенерация, и CodeSmith. Первое вызывает положительные эмоции, второе — отрицательные.
Но есть и вполне хорошие, и при этом совершенно бесплатные кодогенераторы, например StringTemplate (http://www.stringtemplate.org) или xPand (http://www.eclipse.org/gmt/oaw/doc/4.1/r20_xPandReference.pdf). Точнее это template engines.
Лично сам я пробовал комбинацию Groovy+StringTemplate — заруливает CodeSmith со страшной силой. В этой комбинации объекты модели описывается на Groovy (или Python, или Ruby, как вам больше нравится), а шаблоны — это набор параметризованых макросов, которые можно влаживать и переопределять для генерации классов, свойств, методов. Вы инстанциируеме модель, отдаете ее шаблонам, на выходе получаете пачку красиво оформленных исходников. Все очень просто и быстро ;)
2. Но CodeSmith это самый уродливый кодогенератор который можно было придумать. И эта поделка еще стоит денег. Для тех кто не в теме, он использует ASP-подобный язык шаблонов. Представьте себе, что у вас забрали ваш любимый MVC web framework а в замен оставили "старый добрый" PHP, APS или JSP из 90-х, и ваше веб приложение — это каша из HTML фрагментов и скриптлетов. Вот так же выглядят шаблоны CodeSmith — текст в перемешку с C# кодом. Брррр. Если не понятно, то проблема в том, что приходится генерировать структурированный код на языке программирования высокого уровня пользуясь шаблонами написанными на языке в котором нет средств для описания структур.
Оба утверждения основаны на личном опыте, в основном рабочем проекте используется и кодогенерация, и CodeSmith. Первое вызывает положительные эмоции, второе — отрицательные.
Но есть и вполне хорошие, и при этом совершенно бесплатные кодогенераторы, например StringTemplate (http://www.stringtemplate.org) или xPand (http://www.eclipse.org/gmt/oaw/doc/4.1/r20_xPandReference.pdf). Точнее это template engines.
Лично сам я пробовал комбинацию Groovy+StringTemplate — заруливает CodeSmith со страшной силой. В этой комбинации объекты модели описывается на Groovy (или Python, или Ruby, как вам больше нравится), а шаблоны — это набор параметризованых макросов, которые можно влаживать и переопределять для генерации классов, свойств, методов. Вы инстанциируеме модель, отдаете ее шаблонам, на выходе получаете пачку красиво оформленных исходников. Все очень просто и быстро ;)
Не думаю, что MVC - лучший подход всех времен и народов. У каждого подхода свои преимущества. Если CodeSmith вам не подходит - это не значит что он плохой, я знаю людей, которые сгенерировали в нем миллионы строк кода и вполне довольны. А используются в нем не "ASP-подобный подход из 90-ых", а разметка ASP.NET, которая сейчас довольно популярна. Разумеется, если вам она не нравится - это опять же не значит что она плохая.
>Не думаю, что MVC - лучший подход всех времен и народов.
Ну это да, смотря для какой цели. Но для кодогенерации — это все таки лучший подход. Особенно когда генерация сложная.
>Если CodeSmith вам не подходит - это не значит что он плохой.
Он нам подходит, но все равно плохой. Есть тулы, которые подошли бы лучше. Но есть задачи более приоритетные задачи чем переписывание legacy кода. Работает, ну и ладно.
> сгенерировали в нем миллионы строк кода и вполне довольны
Это вообще не аргумент. Я знаю людей, которые _не_ генерировали в нем миллионы строк кода и вполне довольны.
> а разметка ASP.NET которая сейчас довольно популярна. если вам она не нравится - это опять же не значит что она плохая.
1. ASP.NET это не "разметка", это нечто болшее чем синтаксис 2. ASP.NET меня вполне устраивает, и даже немного нравится как технология, хотя и не хочу с ней иметь дела. Смотри, в ASP.NET у тебя есть master pages, server controls, page controllers. А что у тебя есть в Codesmith? Правильно, мешанина из C# и текста, гремучая смесь которую трудно поддерживать. Представь себе, что твое веб приложение, использует Codesmith для рендеринга html. Такое возможно, это ведь просто template engine. Но ты ведь не захочешь так делать, ага?
Вывод: Codesmith — полная фигня, более достойные альтернативы я привел.
Ну это да, смотря для какой цели. Но для кодогенерации — это все таки лучший подход. Особенно когда генерация сложная.
>Если CodeSmith вам не подходит - это не значит что он плохой.
Он нам подходит, но все равно плохой. Есть тулы, которые подошли бы лучше. Но есть задачи более приоритетные задачи чем переписывание legacy кода. Работает, ну и ладно.
> сгенерировали в нем миллионы строк кода и вполне довольны
Это вообще не аргумент. Я знаю людей, которые _не_ генерировали в нем миллионы строк кода и вполне довольны.
> а разметка ASP.NET которая сейчас довольно популярна. если вам она не нравится - это опять же не значит что она плохая.
1. ASP.NET это не "разметка", это нечто болшее чем синтаксис 2. ASP.NET меня вполне устраивает, и даже немного нравится как технология, хотя и не хочу с ней иметь дела. Смотри, в ASP.NET у тебя есть master pages, server controls, page controllers. А что у тебя есть в Codesmith? Правильно, мешанина из C# и текста, гремучая смесь которую трудно поддерживать. Представь себе, что твое веб приложение, использует Codesmith для рендеринга html. Такое возможно, это ведь просто template engine. Но ты ведь не захочешь так делать, ага?
Вывод: Codesmith — полная фигня, более достойные альтернативы я привел.
Я очень активно использую codegen, и вывод в общем следующий.
Кодегенерация — штука полезная для того, чтобы определить общую схему приложения и убедиться что любая метаинформация упоминается ровно один раз. Например, если я скажу, что у сущности Person есть Name длиной 50 символов, у меня он будет и в базе, и в C#-коде.
Но кроме такой вот обёртки, кодегенерация высокоуровневого языка создаёт больше проблем, чем решает.
Т.е. инструмент с довольно сильно ограниченной применимостью (но без него тяжело).
Кстати, вот пример сложности. Как только у нас есть сгенерированный код модели, сразу возникает вопрос — а что делать, если эталонная модель изменилась? Если мы автоматически перегенерируем всё (я так делаю), то возникает другой вопрос — как сделать так, чтоб программист всё таки мог что-нибудь поменять, не боясь, что всё затрётся. Он решаем, но не просто (до C# 3.5).
Кодегенерация — штука полезная для того, чтобы определить общую схему приложения и убедиться что любая метаинформация упоминается ровно один раз. Например, если я скажу, что у сущности Person есть Name длиной 50 символов, у меня он будет и в базе, и в C#-коде.
Но кроме такой вот обёртки, кодегенерация высокоуровневого языка создаёт больше проблем, чем решает.
Т.е. инструмент с довольно сильно ограниченной применимостью (но без него тяжело).
Кстати, вот пример сложности. Как только у нас есть сгенерированный код модели, сразу возникает вопрос — а что делать, если эталонная модель изменилась? Если мы автоматически перегенерируем всё (я так делаю), то возникает другой вопрос — как сделать так, чтоб программист всё таки мог что-нибудь поменять, не боясь, что всё затрётся. Он решаем, но не просто (до C# 3.5).
действительно... поправьте пожалуйста RubyOnRails
Простите великодушно, автор, но мне весь ваш цикл статей видится как "Важность английского алфавита для программирования на C++"
Ребят, если бы я откуда-то копировал статьи - то в первой же статье было от начала до конца все. Но так сложилось, что пишу свои статьи я сам, так что наберитесь терпения и подождите новых статей.
Лучше бы ты книжки читал, а не статьи писал.
Может обоснуешь?)
То, что в одной куче оказались такие вещи, как "ООП вообще", генерация HTML для веба, .NET, и MVC свидетельствует о очень поверхностном понимании темы.
Настолько поверхностном, что попытки кому-то что-то об этом рассказать действительно похожи на объяснения полезности знания латиницы для программистов.
Сначала нужно как следует разобраться, а потом уже статьи писать. "Нож - очень полезная вещь, ножом можно резать хлеб, можно делать деревянные поделки. В следующей статье я расскажу вам, как отрезать ножом кусок веревки,"
Настолько поверхностном, что попытки кому-то что-то об этом рассказать действительно похожи на объяснения полезности знания латиницы для программистов.
Сначала нужно как следует разобраться, а потом уже статьи писать. "Нож - очень полезная вещь, ножом можно резать хлеб, можно делать деревянные поделки. В следующей статье я расскажу вам, как отрезать ножом кусок веревки,"
Предлагаю вернуться к началу, чтоб описать более конкретно этот термин, т.к. молодым и зеленым, непонятны принципы Rapid Application Development. В первой статье Вы затронули PHP + MySQL, а где примеры? ;)
Заинтересовался тоже кодогенерацией - как в любой другой технологии, есть как минусы, так и плюсы. Надо уметь использовать.
Кстати, кто что думает про Umbrello?
Кстати, кто что думает про Umbrello?
А вот кстати недавно наткнулся на интересную вещь: dbdesigner2cake
DBDesigner 4 Scaffold Tools for CakePHP, or simply dbdesigner2cake, is a tool which parses fabFORCE's DBDesigner 4 XML file into CakePHP models and controllers files.
It aims to simplify the first two steps in any system development, modelling and model coding.
В C# версии 3 появился LINQ (Language Integrated Query). Это довольно удобное дополнение к C#, которое избавляет программиста от массы рутинной работы.
Не подумайте что просто предираюсь, но LINQ можно использовать во все .NET языках, а не только в C#.
Не подумайте что просто предираюсь, но LINQ можно использовать во все .NET языках, а не только в C#.
Автор, вы уж простите меня, я буду выступать резковато. Но я для этого даже зарегистрировался специально.
Скажите, вы нас за даунов держите? Сначала первая часть с, мягко говоря, сомнительными примерами с для ООП и не для ООП. И то каждый из трех строк. При том, что кодогенерация не имеет к ООП вообще никакого отношения.
Давайте определимся, чтобы не было путаницы, когда каждый о своем - что такое кодогенерация. А то вы своими примерами на генерацию HTML тоже всех путаете.
Кодогенерация - это _автоматическое_ создание одним исполняемым кодом другого _исполняемого_кода_.
Шаблонизаторы, составляющие HTML - это не кодогенерация, в общем случае. Потому что это - создание документа. Можно, конечно, придираться по мелочам, мол HTML - это язык, он выполняется браузером и т.д., но на самом деле если и язык в этом понимании, то недоязык. Нет там ни управляющих конструкций, ни данных, ничего там нет. Хотя тот же Smarty имеет некую кодогенерацию.
А вот компиляторы - это как раз самые что ни на есть кодогенераторы. Это как раз программы, создающие из входных данных (в данном случае - "текстов программ на языке высокого уровня") другой _исполняемый_ код.
Код не обязан быть непосредственно в машинных кодах, естественно. Те же скаффолды создают код на том же языке, что и написаны. А оптимизатор PHP преобразует код в некое внутреннее представление для ускоренного выполнения. Но в любом случае, это - осмысленный полноценный код, способный передать логику и оперировать данными, на некой существующей системе выполнения данного кода.
(Я сразу извиняюсь за некий сумбур в терминологии и определениях, но, я думаю, сама мысль, которую я высказываю, достаточно понятна. Потому не надо придираться к словам вместо смысла. Комментарии приму с благодарностью)
Предлагаю разделить все данные, которые имеются для получения результата, на два больших класса:
1) Логика. Назовем ее так. Для обычного компилятора это - код программы. Однако это могут быть и какие-то другие системы описания.
2) Данные. Конкретно то, что обрабатывается Логикой.
В результате, мы имеем ДВА(!) подхода:
1) Интерпретация. Есть некие входные данные (вся совокупность - Логика и Данные), есть написанный нами код, который на основании этих данных выполняет определенные действия и что-то делает с результатом.
2) Компиляция. Есть некий компилятор, на вход которому подается Логика и он _генерит_исполняемый_код_, и уже подав его на вход некой системы вместе с Данными мы получаем результат.
В чем разница этих двух подходов, в чем их плюсы и минусы.
1) Очевидно, что выполнение после компиляции _быстрее_ (мы пропускаем каждый раз при выполнении один шаг - разбор Логики на входе). Это плюс компиляции.
2) Очевидно, что разработка компилятора - дополнительные затраты, причем зачастую достаточно существенные. Это минус компиляции.
3) Очевидно, что компилятор должен быть сложной и сильно связанной системой, поэтому внесение изменений в него (добавление возможностей для описания Логики) намного сложнее и затратнее, чем добавление возможности обработки этих же возможностей интерпретатором. Это тоже минус компиляции.
Отсюда напрашивается достаточно простой вывод - разработка компилятора обоснована либо в критичной по производительности системе, либо при его (компилятора) _многократном_ применении, когда описание Логики _существенно_ меньше получаемого в результате компиляции объема кода.
Вот в таком русле предлагаю и вести дискуссию и последующих статьях. Плюсы и минусы этих двух подходов (а они есть, разные и много), в каком случае стоит использовать одно, в каком - нет.
Потому что доказывать нам, что скаффолды, сгенерированные автоматически - это круто и полный хайтек, не надо. Я сомневаюсь, что кто-то оставляет их без переработки, почти равной по затратам написанию всего этого с нуля.
Скажите, вы нас за даунов держите? Сначала первая часть с, мягко говоря, сомнительными примерами с для ООП и не для ООП. И то каждый из трех строк. При том, что кодогенерация не имеет к ООП вообще никакого отношения.
Давайте определимся, чтобы не было путаницы, когда каждый о своем - что такое кодогенерация. А то вы своими примерами на генерацию HTML тоже всех путаете.
Кодогенерация - это _автоматическое_ создание одним исполняемым кодом другого _исполняемого_кода_.
Шаблонизаторы, составляющие HTML - это не кодогенерация, в общем случае. Потому что это - создание документа. Можно, конечно, придираться по мелочам, мол HTML - это язык, он выполняется браузером и т.д., но на самом деле если и язык в этом понимании, то недоязык. Нет там ни управляющих конструкций, ни данных, ничего там нет. Хотя тот же Smarty имеет некую кодогенерацию.
А вот компиляторы - это как раз самые что ни на есть кодогенераторы. Это как раз программы, создающие из входных данных (в данном случае - "текстов программ на языке высокого уровня") другой _исполняемый_ код.
Код не обязан быть непосредственно в машинных кодах, естественно. Те же скаффолды создают код на том же языке, что и написаны. А оптимизатор PHP преобразует код в некое внутреннее представление для ускоренного выполнения. Но в любом случае, это - осмысленный полноценный код, способный передать логику и оперировать данными, на некой существующей системе выполнения данного кода.
(Я сразу извиняюсь за некий сумбур в терминологии и определениях, но, я думаю, сама мысль, которую я высказываю, достаточно понятна. Потому не надо придираться к словам вместо смысла. Комментарии приму с благодарностью)
Предлагаю разделить все данные, которые имеются для получения результата, на два больших класса:
1) Логика. Назовем ее так. Для обычного компилятора это - код программы. Однако это могут быть и какие-то другие системы описания.
2) Данные. Конкретно то, что обрабатывается Логикой.
В результате, мы имеем ДВА(!) подхода:
1) Интерпретация. Есть некие входные данные (вся совокупность - Логика и Данные), есть написанный нами код, который на основании этих данных выполняет определенные действия и что-то делает с результатом.
2) Компиляция. Есть некий компилятор, на вход которому подается Логика и он _генерит_исполняемый_код_, и уже подав его на вход некой системы вместе с Данными мы получаем результат.
В чем разница этих двух подходов, в чем их плюсы и минусы.
1) Очевидно, что выполнение после компиляции _быстрее_ (мы пропускаем каждый раз при выполнении один шаг - разбор Логики на входе). Это плюс компиляции.
2) Очевидно, что разработка компилятора - дополнительные затраты, причем зачастую достаточно существенные. Это минус компиляции.
3) Очевидно, что компилятор должен быть сложной и сильно связанной системой, поэтому внесение изменений в него (добавление возможностей для описания Логики) намного сложнее и затратнее, чем добавление возможности обработки этих же возможностей интерпретатором. Это тоже минус компиляции.
Отсюда напрашивается достаточно простой вывод - разработка компилятора обоснована либо в критичной по производительности системе, либо при его (компилятора) _многократном_ применении, когда описание Логики _существенно_ меньше получаемого в результате компиляции объема кода.
Вот в таком русле предлагаю и вести дискуссию и последующих статьях. Плюсы и минусы этих двух подходов (а они есть, разные и много), в каком случае стоит использовать одно, в каком - нет.
Потому что доказывать нам, что скаффолды, сгенерированные автоматически - это круто и полный хайтек, не надо. Я сомневаюсь, что кто-то оставляет их без переработки, почти равной по затратам написанию всего этого с нуля.
"Это и многое другое читайте в будущих топиках" :)
Из теории трансляторов:
Транслятор - обслуживающая программа, преобразующая исходную программу, предоставленную на входном языке программирования, в рабочую программу, представленную на объектном языке.
Ассемблер - системная обслуживающая программа, которая преобразует символические конструкции в команды машинного языка.
Компилятор - это обслуживающая программа, выполняющая трансляцию на машинный язык программы, записанной на исходном языке программирования.
Интерпретатор - программа или устройство, осуществляющее пооператорную трансляцию и выполнение исходной программы.
Эмулятор - программа или программно-техническое средство, обеспечивающее возможность без перепрограммирования выполнять на данной ЭВМ программу, использующую коды или способы выполнения операция, отличные от данной ЭВМ.
Перекодировщик - программа или программное устройство, переводящие программы, написанные на машинном языке одной ЭВМ в программы на машинном языке другой ЭВМ.
Транслятор - обслуживающая программа, преобразующая исходную программу, предоставленную на входном языке программирования, в рабочую программу, представленную на объектном языке.
Ассемблер - системная обслуживающая программа, которая преобразует символические конструкции в команды машинного языка.
Компилятор - это обслуживающая программа, выполняющая трансляцию на машинный язык программы, записанной на исходном языке программирования.
Интерпретатор - программа или устройство, осуществляющее пооператорную трансляцию и выполнение исходной программы.
Эмулятор - программа или программно-техническое средство, обеспечивающее возможность без перепрограммирования выполнять на данной ЭВМ программу, использующую коды или способы выполнения операция, отличные от данной ЭВМ.
Перекодировщик - программа или программное устройство, переводящие программы, написанные на машинном языке одной ЭВМ в программы на машинном языке другой ЭВМ.
Мне,как Oracle DBA, каждый раз, когда я вижу sql-запрос сгенерированный "автомасисисеськи", приходиться сожалеть, что лоботомия не легализована.
Ну, тогда уж стоит вспомнить и шаблонизацию в C++. Тоже, можно сказать, кодогенерация.
Вот есть у меня такой кодогенератор, который из файла txt формирует файл obj. Я потому правлю obj и другим кодогенератором делаю exe. Да, исправленный obj будет затерт следующей кодогенерацией из txt. Кодогенератор в вашем понимании, это недо-транслятор с недо-языка с недо-компиляцией. И зачем нам недо-средства? Вот MS придумала MFC и обделалась, а Дельфи придумала VCL и преуспела, тогда MS придумала c# усердно и методично скопировав VCL, но снова обделалась с DataSet, но решила преуспеть с WPF. Кодогенератор — это квадратура круга, на ограниченных задачах работает, но писать на нем серьезные проги не рекомендуется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Где используется кодогенерация