Comments 27
Код читается, как книжка.
«Доменизированные» html-шаблоны, почти как dsl builders в Groovy: оч. клева :)
А вы подсветку и layout прямо из MSP «скриншотали»?
А вы подсветку и layout прямо из MSP «скриншотали»?
Не совсем понятна семантика этих языков. Распишете? (интереса ради)
обалдеть просто =O
а оно за кулисами в Hibernate/EJB3 превращается?
// про guest profiles непонятно. лучше убери вообще тот weakhashmap
а оно за кулисами в Hibernate/EJB3 превращается?
// про guest profiles непонятно. лучше убери вообще тот weakhashmap
Правда ли, что здесь приведены примеры именно использования DSL-языков, и что кроме этого необходимо заранее описать эти DSL языки?
А у меня такой вопрос. После того, как dsl описан и все обработчики определены, что я получу на выходе? Какой-то интерпретатор/машину и все? Есть ли поддержка синтаксиса для таких языков в MPS (или в IDEA), есть ли дебаггер?
Просто сейчас как раз занят разработкой плагина под Eclipse для одного языка, используемого внутри компании, и мне интересно, может быть я вместо этого мог бы использовать MPS. Базовая IDE для нас не так важна, просто выбрали Eclipse, потому щто он у нас для разработки на Java используется.
Просто сейчас как раз занят разработкой плагина под Eclipse для одного языка, используемого внутри компании, и мне интересно, может быть я вместо этого мог бы использовать MPS. Базовая IDE для нас не так важна, просто выбрали Eclipse, потому щто он у нас для разработки на Java используется.
Насколько я понимаю, «на выходе» будет единое абстрактное представление кода проекта, которое может быть конвертировано как в высокоуровневые языки так и в байткод.
Необходимость в дополнительном интерпретаторе таким образом отпадает — хватает jvm.
Необходимость в дополнительном интерпретаторе таким образом отпадает — хватает jvm.
На выходе вы получите язык, который можно использовать в MPS (мы используем проекционный редактор, так что тут есть привязка к нашему IDE). То, как он будет работать зависит от вас. Мы обычно задаем генератор и получаем на выходе код на Java, Javascript, итп. Интерперетатор тоже возможен.
Отладчика сейчас нет, правда в следующей major версии мы планируем сделать отладчик для языков расширяющих/вставляющих Java.
Если вы пишите IDE для существующиего текстового языка, то MPS вам тут слабо поможет. То, что мы редактируем это не текст, а проекция синтаксического дерева.
Отладчика сейчас нет, правда в следующей major версии мы планируем сделать отладчик для языков расширяющих/вставляющих Java.
Если вы пишите IDE для существующиего текстового языка, то MPS вам тут слабо поможет. То, что мы редактируем это не текст, а проекция синтаксического дерева.
Неплохо было бы посмотреть на процесс проектирования какого-нибудь небольшого язычка в этой среде.
Похоже на приемы в Django.
А можно ли, например, сделать так:
Ну или что-то подобное. Т.е. использовать объекты Си++ в шарповом коде и наоборот?
В идеале нужен язык, в котором можно было бы пользоваться всеми наработками. Одну компоненту взять из Java, другую из C#, и чтобы всё прозрачно работало вместе, но мне это кажется утопией. Во что соберётся Java + C + Ruby, например.
public CPPData someCSharpFunction(string filename)
{
CPPLoaderClass c(filename);
c.load();
c.doSomeOtherWork();
CPPData d = c.result();
d += "here is html code";
return d;
}Ну или что-то подобное. Т.е. использовать объекты Си++ в шарповом коде и наоборот?
В идеале нужен язык, в котором можно было бы пользоваться всеми наработками. Одну компоненту взять из Java, другую из C#, и чтобы всё прозрачно работало вместе, но мне это кажется утопией. Во что соберётся Java + C + Ruby, например.
В вашей предыдущей статься сказано: «Широкому использованию DSL-ей мешают 2 проблемы: невозможность их повторного использования в системах на основе текстовых грамматик, и сложность создания интеллектуальных средств работы с ними».
На мой взгляд DSL присущи другие две проблемы, а именно: сложность создания DSL и сложность его изучения.
Эти две проблемы на самом деле существуют и у обычных библиотек — мало того что сложно спроектировать хорошую библиотеку, ей еще надо научиться пользоваться.
Сравните два пути решения задачи:
1. Классика: Разработчик знает «родной» язык (например java) -> изучение предметной области -> выбор (или написание) библиотеки на «родном» языке -> решение
2. DSL: Разработчик -> изучение (или что еще хуже — создание) DSL -> решение
Соответственно возникает вопрос что проще — изучить(разработать) библиотеку на родном языке или изучить(создать) DSL?
PS: Я сам не специалист по DSL(связывался с этим явлением на уровне написания DSL на основе XML), поэтому, возможно, упускаю какие-то важные моменты.
На мой взгляд DSL присущи другие две проблемы, а именно: сложность создания DSL и сложность его изучения.
Эти две проблемы на самом деле существуют и у обычных библиотек — мало того что сложно спроектировать хорошую библиотеку, ей еще надо научиться пользоваться.
Сравните два пути решения задачи:
1. Классика: Разработчик знает «родной» язык (например java) -> изучение предметной области -> выбор (или написание) библиотеки на «родном» языке -> решение
2. DSL: Разработчик -> изучение (или что еще хуже — создание) DSL -> решение
Соответственно возникает вопрос что проще — изучить(разработать) библиотеку на родном языке или изучить(создать) DSL?
PS: Я сам не специалист по DSL(связывался с этим явлением на уровне написания DSL на основе XML), поэтому, возможно, упускаю какие-то важные моменты.
Расширения это не полноценные языки. В них нет новых парадигм программирования, просто удобные и логичные расширения существующих, так что изучение расширения гораздо проще, чем изучение полноценного языка.
Насчет библиотек, вы правы. Наши языки похожи на библиотеки. По нашему опыту, язык выучить проще, чем библиотеку. Те языки, которые представлены на скриншотах, являются частью нашего веб стека, аналогичного J2EE. По нашему опыту, людям проще начать писать на этих языках, чем начать писать на J2EE.
Насчет библиотек, вы правы. Наши языки похожи на библиотеки. По нашему опыту, язык выучить проще, чем библиотеку. Те языки, которые представлены на скриншотах, являются частью нашего веб стека, аналогичного J2EE. По нашему опыту, людям проще начать писать на этих языках, чем начать писать на J2EE.
Наверняка выучить DSL проще чем библиотеку(иначе зачем тогда вообще выдумывать DSL).
С другой стороны J2ЕЕ, Spring, стек Apaсhe и прочие являются отраслевыми стандартами и пока определенным DSL(как в вашем примере) до них еще далеко (точнее их вообще нет или есть только закрытые прототипы). Ведь не все работают в одной компании всю жизнь.
Тем не менее ваш подход кажется мне перспективным и я желаю вам успеха.
С другой стороны J2ЕЕ, Spring, стек Apaсhe и прочие являются отраслевыми стандартами и пока определенным DSL(как в вашем примере) до них еще далеко (точнее их вообще нет или есть только закрытые прототипы). Ведь не все работают в одной компании всю жизнь.
Тем не менее ваш подход кажется мне перспективным и я желаю вам успеха.
Огромный, многословный, непонятный и неинтуитивный язык для создания огромных, многословных, непонятных и неинтуитивных языков… Спасибо за пример, раньше я смотрел презентации и мне казалось, что за этим что-то есть практически полезное. Теперь вижу, что нет — просто очередное java-style нагромождение аббревиатур на пустом месте.
Ну ведь уродливо всё это… откровенно уродливо.
Ну ведь уродливо всё это… откровенно уродливо.
Вообще это не язык, а среда… Согласен, сходу понять и осознать задумку трудновато; советую вам посмотреть статью Language Workbenches: The Killer-App for Domain Specific Languages? — она длинная, но вней раскрывается идея.
Заслоупочил малость, на статью только сейчас наткунлся. По поводу MPS, YT итп — у меня всегда в голове крутился вопрос. Вот вы разработали хороший багтрекер с помощью MPS, форум, возможно ещё что-то. То, что форум и YT похожи — это очевидно. То есть, вы, как и говорили, переиспользовали DSL вашего веб-стека.
Можно ли ожидать, что в какое-то время эти языки станут доступными публике? То есть, реализовать стремление переиспользовать языки. Сейчас стартануть с MPS с нуля для написания приложения сложно в силу того, что нужно будет реализовывать такой же стек самим, и это как-то тормозит.
Нет возможности взять и за пятнадцать минут собрать свой сайт на MPS. А потом расширить его, использовав ещё какой-то язык. Посмотреть — каково это в деле — переиспользование языков — здесь и сейчас?
Можно ли ожидать, что в какое-то время эти языки станут доступными публике? То есть, реализовать стремление переиспользовать языки. Сейчас стартануть с MPS с нуля для написания приложения сложно в силу того, что нужно будет реализовывать такой же стек самим, и это как-то тормозит.
Нет возможности взять и за пятнадцать минут собрать свой сайт на MPS. А потом расширить его, использовав ещё какой-то язык. Посмотреть — каково это в деле — переиспользование языков — здесь и сейчас?
Sign up to leave a comment.
Языко-ориентированное программирование в действии. Примеры реального кода на JetBrains MPS