Pull to refresh

Comments 27

«Доменизированные» html-шаблоны, почти как dsl builders в Groovy: оч. клева :)

А вы подсветку и layout прямо из MSP «скриншотали»?
Да, это скриншоты MPS. Не все, что у нас есть можно легко скопировать в текст.
Не совсем понятна семантика этих языков. Распишете? (интереса ради)
обалдеть просто =O

а оно за кулисами в Hibernate/EJB3 превращается?

// про guest profiles непонятно. лучше убери вообще тот weakhashmap
Внутри оно превращается в уровень абстракции, за которым скрывается база данных.
Правда ли, что здесь приведены примеры именно использования DSL-языков, и что кроме этого необходимо заранее описать эти DSL языки?
Да это DSL-и, полученные путем расширения/внедрения языков. Да, язык должен быть описан перед тем как используется, но это не так сложно, как может показаться, поскольку в MPS можно расширять и внедрять языки, и это позволяет делать новые языки на основе существующих.
А у меня такой вопрос. После того, как dsl описан и все обработчики определены, что я получу на выходе? Какой-то интерпретатор/машину и все? Есть ли поддержка синтаксиса для таких языков в MPS (или в IDEA), есть ли дебаггер?

Просто сейчас как раз занят разработкой плагина под Eclipse для одного языка, используемого внутри компании, и мне интересно, может быть я вместо этого мог бы использовать MPS. Базовая IDE для нас не так важна, просто выбрали Eclipse, потому щто он у нас для разработки на Java используется.
Насколько я понимаю, «на выходе» будет единое абстрактное представление кода проекта, которое может быть конвертировано как в высокоуровневые языки так и в байткод.
Необходимость в дополнительном интерпретаторе таким образом отпадает — хватает jvm.
На выходе вы получите язык, который можно использовать в MPS (мы используем проекционный редактор, так что тут есть привязка к нашему IDE). То, как он будет работать зависит от вас. Мы обычно задаем генератор и получаем на выходе код на Java, Javascript, итп. Интерперетатор тоже возможен.

Отладчика сейчас нет, правда в следующей major версии мы планируем сделать отладчик для языков расширяющих/вставляющих Java.

Если вы пишите IDE для существующиего текстового языка, то MPS вам тут слабо поможет. То, что мы редактируем это не текст, а проекция синтаксического дерева.
Неплохо было бы посмотреть на процесс проектирования какого-нибудь небольшого язычка в этой среде.
Так скринкаст на сайте же есть :) Там, правда, кот наплакал (на калькулятор), но тем не менее :)
Скринкаст — совсем не то. Инетерсует весь процесс — от анализа предметной области до реализации в внедрения.
А можно ли, например, сделать так:
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, например.
В принципе можно, но, как сказали комментом ниже, .NET для этого подходит намного лучше.
В вашей предыдущей статься сказано: «Широкому использованию DSL-ей мешают 2 проблемы: невозможность их повторного использования в системах на основе текстовых грамматик, и сложность создания интеллектуальных средств работы с ними».
На мой взгляд DSL присущи другие две проблемы, а именно: сложность создания DSL и сложность его изучения.
Эти две проблемы на самом деле существуют и у обычных библиотек — мало того что сложно спроектировать хорошую библиотеку, ей еще надо научиться пользоваться.
Сравните два пути решения задачи:
1. Классика: Разработчик знает «родной» язык (например java) -> изучение предметной области -> выбор (или написание) библиотеки на «родном» языке -> решение
2. DSL: Разработчик -> изучение (или что еще хуже — создание) DSL -> решение
Соответственно возникает вопрос что проще — изучить(разработать) библиотеку на родном языке или изучить(создать) DSL?

PS: Я сам не специалист по DSL(связывался с этим явлением на уровне написания DSL на основе XML), поэтому, возможно, упускаю какие-то важные моменты.
Расширения это не полноценные языки. В них нет новых парадигм программирования, просто удобные и логичные расширения существующих, так что изучение расширения гораздо проще, чем изучение полноценного языка.

Насчет библиотек, вы правы. Наши языки похожи на библиотеки. По нашему опыту, язык выучить проще, чем библиотеку. Те языки, которые представлены на скриншотах, являются частью нашего веб стека, аналогичного J2EE. По нашему опыту, людям проще начать писать на этих языках, чем начать писать на J2EE.
Наверняка выучить DSL проще чем библиотеку(иначе зачем тогда вообще выдумывать DSL).
С другой стороны J2ЕЕ, Spring, стек Apaсhe и прочие являются отраслевыми стандартами и пока определенным DSL(как в вашем примере) до них еще далеко (точнее их вообще нет или есть только закрытые прототипы). Ведь не все работают в одной компании всю жизнь.
Тем не менее ваш подход кажется мне перспективным и я желаю вам успеха.
Сейчас это уже не прототип, а скорее альфа версия. Кроме харизмы мы успешно делаем и другие, хотя и более мелкие приложения.

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

Ну ведь уродливо всё это… откровенно уродливо.
Заслоупочил малость, на статью только сейчас наткунлся. По поводу MPS, YT итп — у меня всегда в голове крутился вопрос. Вот вы разработали хороший багтрекер с помощью MPS, форум, возможно ещё что-то. То, что форум и YT похожи — это очевидно. То есть, вы, как и говорили, переиспользовали DSL вашего веб-стека.
Можно ли ожидать, что в какое-то время эти языки станут доступными публике? То есть, реализовать стремление переиспользовать языки. Сейчас стартануть с MPS с нуля для написания приложения сложно в силу того, что нужно будет реализовывать такой же стек самим, и это как-то тормозит.

Нет возможности взять и за пятнадцать минут собрать свой сайт на MPS. А потом расширить его, использовав ещё какой-то язык. Посмотреть — каково это в деле — переиспользование языков — здесь и сейчас?
Only those users with full accounts are able to leave comments. Log in, please.