Фидбэк: вы забыли объяснить, зачем это все. Почему для Weather prediction нужен свой язык? Почему не писать сразу на Java?

потому что разработчики готовы пойти на многое, лишь бы не писать на Java?

Ха-ха. :) Да на чем угодно, на Scala, на Clojure...


На практике не встречал случаев, когда оправданно городить свой DSL, обычно все вполне решаемо средствами Domain Driven Design. Разве что декларативные языки, но это скорее конфигурация (из которой генерировать код может быть оправдано из соображений производительности, ога).

Например, потому что можно будет не переписывать код на другой ЯП в зависимости от платформы (на JavaScript, например, а писать на 1 языке и писать для него языки -расширения, которые будут переводить AST Weather в AST другого языка. Также язык нужно писать с расчетом декларативность, лаконичность и расширяемость. Писать языки легко, а время сокращает.

В наше время, когда на JS и языках, компилирующихся в него, можно писать вообще все, это очень вымученный аргумент. Тем более, что DSL не решает проблемы инфраструктурных различий.

Добавьте пожалуйста, зачем мы разрабатываем язык Weather?
Какие «бизнес»-задачи будет решать этот язык?
Через пару дней я дополню пост, где подробно обосную зачем мы пишем Weather и в чем его преимущества.

Совсем непонятно и сумбурно.
Начните статью с того, чего мы хотим добиться.
Покажите язык, который мы хотим разработать, покажите как оно выглядит.
Потом уже можно расписывать как мы этого добиваемся, по пунктам.
Почему мы пишем root: false? Зачем мне знать про все эти properties и классы?
Объяснять надо отталкиваясь от проблемы, и только то, что нужно.
А сейчас выглядит как будто автор открыл новый проект, что-то там потыкал, расставил false/true и вот что-то уже получили, смотрите в конце..

Хорошо, в дополнении поста я постараюсь обосновать.

В каком-то подкасте слышал что какая-то часть YouTrack была написана на MPS,
а потом они переписали на других технологиях, никто не знает так ли это?

У Youtrack был Workflow Editor (по сути скрипты для автоматизации работы с тикетами) на этой штуке. Тот еще ад был на нём что-то писать. Сейчас добавили поддержку обычного Javascript.
Проблема всех подобного рода решений, от кобола и до наших дней в том, что писать код все равно приходится в конечном итоге программистам, а не аналитикам. И программисты получают полный набор костылей, с которыми приходится бороться.

К тому же при создании таких DSL делается двойная работа — сначала под проект делается язык, а потом на языке делается проект. А потом нужно под этот языко-проект готовить программистов, потому что на рынке их не будет — у вас же свой язык. Создать язык для обработки графики или текста это одно, а держать свой доморощенный язык ради одного проекта это уже пустая трата сил.

Как вы сами видите применение своего детища?
сначала под проект делается язык, а потом на языке делается проект

С этой точки зрения, DSL — это как фреймворк, только с более удобным интерфейсом. Ясное дело, под один проект фреймворк делать никто не будет, за исключением совсем уж монструозных случаев. А сделать его под конкретную предметную область — почему бы и нет?..
Ну смотрите, практической пользы от языка Weather не будет, но на работе мы используем несколько языков, написанных в MPS для того, чтобы генерировать django сервер + всякий муторный код для мобильных приложений. Для стандартных вещей наша штучка очень хороша, позволяет концентрироваться на верстке разработчикам приложений и на кастомных endpoint'ах серверникам.Сначала мы использовали костыльный генератор на node.js, но MPS намного удобнее и практичнее, и, естественно, мощнее
Для .net этот инструмент бесполезен?
Сначала нужно сделать реализацию C# для MPS — потом можно будет генерировать C# код. На данный момент ни у кого руки не дошли вроде.

Не знаю, насколько полно получилось реализовать С#, но попытки точно были
MPS C#

А еще, если не хочется писать реализацию C# — можно генерить прямо в текст на C#, без промежуточной модели на C#. Вот тут, например, генерят Java-код без использования промежуточной модели, прямо из DSL

Для .NET должен подойти другой их проект JetBrains Nitra

Nitra — тоже language workbench, но parser-based. Поэтому будет очень сложно, если не невозможно, сделать в своем языке фичи типа этой

На самом деле пытался пощупать это чудо (без шуток), но без туториала не врубился, а туториала толкового не нашел сходу. Хотя когда-то сам на flex/bison языки делал. Вот бы время было бы… и кстати, с JS никак MPS не дружит? Это было бы огонь!
Есть возможность на выходе генерировать любой язык если у вас есть его имплементация для MPS. Для JavaScript вроде была https://github.com/mar9000/ecmascript4mps
Спасибо! На выходе-то у MPS JS (выполняемый на java-машине?), а хотелось бы чтобы какой-то транспайлер из какого-то своего в JS. Ибо JS вездесущ.
Я думаю что это возможно, я просто MPS давненько уже не занимался — сейчас более детально не могу сказать.
Здравствуйте, логика моделей языков в MPS такова, что у языков есть аспекты TextGen — они отвечают за перевод AST в текстовую форму, а аспект Generator отвечает за Model 2 Model перевод. Так что ecmascript4mps транспайлерится в текст js кода ES5
Огонь! :)
Да, я знаю про racket, но в данном случае немного разные задачи: если с racket можно создать язык от 0 до парсера, лексера, интерпретатора и вообще весь, но его нужно писать руками, то MPS позволяет обойтись без парсинга текста. Конечный язык можно экспортировать как плагин на платформу Intellij Idea и писать в ней код, как в MPS.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.