Comments 42
Вопрос, который задаётся из года в год. Планируется ли поддержка C# хоть когда-нибудь?
Вы имеете в виду, можно ли в MPS реализовать язык, аналогичный C#? Вообще, C# с DSL-ями — это Nemerle. Можно уже брать и юзать. Про него как раз вчера стенограмму постили.
Про Nemerle — вот тут: habrahabr.ru/post/143221/
Вопрос скорее в том, планируется ли официальная реализация C#. Я знаю, что есть вариант от Robert Hencke, и продолжение от mezastel, хотя и не знаю, если честно, насколько они хороши.
Зачем? Для тех же целей вы можете использовать Roslyn, не?
Тут надо призвать собственно автора доклада → smax.
Боюсь, что нами поддержка C# не планируется. По большому счету мы добавляем языки по мере нашей собственной необходимости. То есть те языки, которые необходимы для написания баг-теркера YouTrack и других проектов JetBrains. Поэтому у нас есть поддержка для Java, Javascript, CSS, REST, etc. A для C# — нет.
Хорошая новость состоит в том, что качественную поддержку остальных языков в MPS начали делать люди, не имеющие отношения к JetBrains. Например, компания Realaxy сделала IDE для ActionSctipt на базе MPS. А Markus Völter разрабатывает проект mbedder — Си IDE для встраиваемых систем.
Хорошая новость состоит в том, что качественную поддержку остальных языков в MPS начали делать люди, не имеющие отношения к JetBrains. Например, компания Realaxy сделала IDE для ActionSctipt на базе MPS. А Markus Völter разрабатывает проект mbedder — Си IDE для встраиваемых систем.
Расскажите пожалуйста, когда решение задачи возможно только с применением DSL? Какие типы этих задач?
Пожалуй, не — только, а вместо. Бизнес-приложение, с ясной моделью и изменчивыми требованиями. Вроде учет чего-то.
Нет таких задач. В конце концов все сводится к машинному- или байт-коду, так что все можно написать прямо на нем. :) Вопрос удобства программиста.
вот интересный пример решения задачи:
codefest.ru/program/2012-03/the-practice-of-MPS/
ребята делали реализацию приложения на Java + макросы и затем, при помощи MPS автоматом конвертили полученный код в Object C, который компили уже на iOS
codefest.ru/program/2012-03/the-practice-of-MPS/
ребята делали реализацию приложения на Java + макросы и затем, при помощи MPS автоматом конвертили полученный код в Object C, который компили уже на iOS
Может кто разъяснит, что мешает реализовать модель предметной области (Model Driven Design — техническую часть DDD) средствами самого языка программирования, не прибегая к метапрограммированию?
Просто слишком уж резкий переход от Domain Driven Design (Model Driven Design) к необходимости разширения языка программирования при помощи препроцессинга.
Или DDD подразумевает использовать разширения языка программирования, тогда опять же непонятно зачем, в чем выгода?
Просто слишком уж резкий переход от Domain Driven Design (Model Driven Design) к необходимости разширения языка программирования при помощи препроцессинга.
Или DDD подразумевает использовать разширения языка программирования, тогда опять же непонятно зачем, в чем выгода?
Для ясности, чтобы не отвлекаться на низкоуровневые конструкции, а писать на языке задачи.
Ясность — IMHO вопрос правильной реализации, можно и на вышеупомянутом MPS-е сделать непонятную кашу.
Хотелось бы увидеть результаты анализа, сравнения разных подходов.
А упомянутая конструкция synchronized выглядит не убедительно,
не знаю как на Java, но на C++ это решается средствами языка при помощи RAII.
Хотелось бы увидеть результаты анализа, сравнения разных подходов.
А упомянутая конструкция synchronized выглядит не убедительно,
не знаю как на Java, но на C++ это решается средствами языка при помощи RAII.
В контексте DDD и DSL, лучше смотреть не на пример с synchronized, а на эту картинку:
Хоть и этот пример тоже не совсем показателен, но MPS, помимо расширения Java, предполагает в том числе и создание нового языка, собственного DSL, на котором описывать бизнес-правила модели. При этом сохраняется полная поддержка со стороны IDE.
Вместо того, чтобы оперировать концепциями ООП, вы могли бы оперировать терминами из Ubiquitous Language и это, теоритически, было бы правильнее.
Хоть и этот пример тоже не совсем показателен, но MPS, помимо расширения Java, предполагает в том числе и создание нового языка, собственного DSL, на котором описывать бизнес-правила модели. При этом сохраняется полная поддержка со стороны IDE.
Вместо того, чтобы оперировать концепциями ООП, вы могли бы оперировать терминами из Ubiquitous Language и это, теоритически, было бы правильнее.
Есть мнение, я его целиком не поддерживаю, но склоняюсь всё же к нему. Что если в языке необходимы макросы, то он недостаточно выразителен.
Немало число макросов (типа описанных тут synchronized и read) реализуются на банальных ФВП.
Даже async/await и call-cc можно реализовать без макросов.
Немало число макросов (типа описанных тут synchronized и read) реализуются на банальных ФВП.
Даже async/await и call-cc можно реализовать без макросов.
Я так понимаю, что переход от DDD к DSL — это личное мнение Сергея Полаженко, который опубликовал стенограмму. Но логика тут есть, конечно. Если DDD говорит о том, что программа должна полностью повторять язык проблемной области, то DSL, полностью соответствующий проблемной области — это еще один шаг вперед к полному слиянию в экстазе. :)
Хотя я и не уверен, что это достижимо.
Хотя я и не уверен, что это достижимо.
Ничто не мешает. Но некоторые вещи придется копи-пастить при использовании модели, либо использовать более громоздкие синтаксические выражения. Принципиально нового видимо DSL ничего не принесет, это только оптимизация.
почитайте примеры из статьи про DDD:
habrahabr.ru/post/142491
Суть такая если у вас исходная задача на языке предметной области:
Зарплата сотрудника = отработанное время * нормочас и т.п.
То в случае, если вы пишете чисто на коде, используя конструкции SQL, Linq и т.п. То задачу вы, наверное, решите, но корреляции между вашим кодом и языком предметной области будет очень мало, и в случае если у вас поменяется формулировка задачи (новые термины, связи между ними и т.п.) — то очень высока вероятность, что ваш код придётся очень серьёзно переделывать под нужды новых терминов.
В случае же, если вы имеете свой метаязык, который уже достаточно глубоко эмулирует язык предметной области и вы действительно решаете задачу на этом метаязыке: Salary(Person) ::= WorkedTime * PayPerHour… — то в случае, если задача будет переформулирована, есть вероятность, что вы новое решение запишите просто повторяя формулировку новой задачи при помощи средств метаязыка, без необходимости серьёзной перестройки своей метамодели (ведь она уже эмулирует задачу! только немного расширить надо). Ну и, конечно, чтение кода на метаязыке должно быть практически таким же комфортным, как чтение оригинальной постановки задачи на языке предметной области, т.е. это может делать даже не программист, а эксперт предметной области.
habrahabr.ru/post/142491
Суть такая если у вас исходная задача на языке предметной области:
Зарплата сотрудника = отработанное время * нормочас и т.п.
То в случае, если вы пишете чисто на коде, используя конструкции SQL, Linq и т.п. То задачу вы, наверное, решите, но корреляции между вашим кодом и языком предметной области будет очень мало, и в случае если у вас поменяется формулировка задачи (новые термины, связи между ними и т.п.) — то очень высока вероятность, что ваш код придётся очень серьёзно переделывать под нужды новых терминов.
В случае же, если вы имеете свой метаязык, который уже достаточно глубоко эмулирует язык предметной области и вы действительно решаете задачу на этом метаязыке: Salary(Person) ::= WorkedTime * PayPerHour… — то в случае, если задача будет переформулирована, есть вероятность, что вы новое решение запишите просто повторяя формулировку новой задачи при помощи средств метаязыка, без необходимости серьёзной перестройки своей метамодели (ведь она уже эмулирует задачу! только немного расширить надо). Ну и, конечно, чтение кода на метаязыке должно быть практически таким же комфортным, как чтение оригинальной постановки задачи на языке предметной области, т.е. это может делать даже не программист, а эксперт предметной области.
«Может кто разъяснит, что мешает реализовать модель предметной области (Model Driven Design — техническую часть DDD) средствами самого языка программирования, не прибегая к метапрограммированию?»
То, что вы (обычно) не можетеотдать полнофункциональный язык программирования нетехническому специалисту предметной области.
Но вообще, вопрос поставлен неверно. Для реализации DSL сначала нужна модель предметной области, реализованная любым способом, а потом написанный поверх нее DSL, который будет предоставлять пользователю максимально прозрачный и очевидный способ выражения задач.
То, что вы (обычно) не можетеотдать полнофункциональный язык программирования нетехническому специалисту предметной области.
Но вообще, вопрос поставлен неверно. Для реализации DSL сначала нужна модель предметной области, реализованная любым способом, а потом написанный поверх нее DSL, который будет предоставлять пользователю максимально прозрачный и очевидный способ выражения задач.
Ничего не мешает. Просто появляется возможность наделить IDE дополнительными «знаниями» об элементах вашей программы. Например, если вы пишите на языке Java, то ваша IDE «знает» только о классах, методах, аннотациях и т.п. Соответственно и рефакторинги, навигацию и подсказки она может выполнять только для элементов языка Java. Что происходит, когда в вашей IDE появляется поддержка некоторой технологии, например, Spring? Она «узнает» о дополнительной семантике вашего кода, и получает возможность, например, искать использования класса не только в Java-коде, но и в XML-файлах Spring.
Конечно, вы можете наделить IDE знаниями о дополнительной семантике конструкций вашей программы, самостоятельно написав плагин для Eclipse или IntelliJ IDEA, но в MPS сделать это значительно проще.
Конечно, вы можете наделить IDE знаниями о дополнительной семантике конструкций вашей программы, самостоятельно написав плагин для Eclipse или IntelliJ IDEA, но в MPS сделать это значительно проще.
Ого го, как далеко подкат.
В статье было заявлено, что Lisp не решает проблемы из-за отсутствия языковой инфраструктуры. Можно подробнее об этом? Мне, просто, кажется что Lisp-подобные языки как раз самое лучшее, что придумали для поддержки DSL.
когда речь заходит о DSL'ях, вспоминается байка:
какие KPI можете посоветовать для управления такой разработкой — в каких случаях стоит писать DSL, и это будет оправдано, а в каких нужно сказать «стоп» и тупо кодить?
С востока люди пришли на землю Сеннаар (в нижнем течении Тигра и Евфрата), где решили построить город (Вавилон) и башню высотой до небес, чтобы «сделать себе имя». Строительство башни было прервано Богом, который создал новые языки для разных людей, из-за чего они перестали понимать друг друга, не могли продолжать строительство города и башни и рассеялись по всей земле. [1]как вы считаете, грозит-ли подобная участь многоязыкому YouTrack, и если нет, то — почему? )
какие KPI можете посоветовать для управления такой разработкой — в каких случаях стоит писать DSL, и это будет оправдано, а в каких нужно сказать «стоп» и тупо кодить?
Внедрение DSL становится неоправданным тогда, когда он начинает разрастаться до полноценного языка программирования и становится слишком универсальным и ваш проект начинает превращаться в yet another universal enterprise platform.
А вот когда DSL используется для четко определенной и частой задачи (ETL, например) и не вылазит за ее рамки — все как правило должно окупиться.
А вот когда DSL используется для четко определенной и частой задачи (ETL, например) и не вылазит за ее рамки — все как правило должно окупиться.
с первым пунктом соглашусь не полностью
если у вас очень объёмная задача, то создание своего языка тоже может быть оправданно, язык должен давать:
1. возможность решения задачи на языке предметной области, особенно если требования предметной области часто меняются (вспомните 1С — аля платформа DSL языка для бухгалтеров, согласитесь писать все эти бухгалтерские заморочки на C# или того хуже на С++ было бы куда страшней и менее понятно).
2. универсальность языка — любую задачу можно нарисовать на нём
3. экспресивность языка — вы легко читаете задачу на метаязыке, как-будто задача написана на языке предметной области и т.п.
если у вас очень объёмная задача, то создание своего языка тоже может быть оправданно, язык должен давать:
1. возможность решения задачи на языке предметной области, особенно если требования предметной области часто меняются (вспомните 1С — аля платформа DSL языка для бухгалтеров, согласитесь писать все эти бухгалтерские заморочки на C# или того хуже на С++ было бы куда страшней и менее понятно).
2. универсальность языка — любую задачу можно нарисовать на нём
3. экспресивность языка — вы легко читаете задачу на метаязыке, как-будто задача написана на языке предметной области и т.п.
Тут мы уже начинаем плавно переходить к классическому холивару «универсальная платформа vs специализированная система».
1. Проблема в том, что чем более универсален ваш язык — тем ближе он к тому самому языку на котором вы все пишете изначально и со временем превращается в отдельную платформу. А зачем писать еще одну (скорее всего более кривую) платформу, если она у вас уже есть? Тут уже проще подключить к проекту какой-нибудь скриптовой язык общего назначения типа Lua или Python.
Из личного опыта разработки под 1С 7.7 (слава богу, уже более 10 лет назад ;)) и разработки под .net — под .net пишется лучше. Как минимум за счет инструментария платформы, не говоря уже о выразительности языка.
2. Когда на DSL можно нарисовать любую задачу — это уже не DSL в общем-то ;) Противоречит определению. Во-первых, большой DSL и универсальный DSL долго изучать. Увеличивает порог входа для новых программистов. Во-вторых, у вас в проекте может быть множество маленьких язычков и это вполне нормально, более того, в книжках пишут, что разрастание dsl — это bad smell о том, что задача неправильно декомпозирована и dsl придется бить на несколько отдельных маленьких.
3. Это один из самых больших плюсов DSL, да. Но чтобы так получилось, разработку нужно начинать с определения domain language.
1. Проблема в том, что чем более универсален ваш язык — тем ближе он к тому самому языку на котором вы все пишете изначально и со временем превращается в отдельную платформу. А зачем писать еще одну (скорее всего более кривую) платформу, если она у вас уже есть? Тут уже проще подключить к проекту какой-нибудь скриптовой язык общего назначения типа Lua или Python.
Из личного опыта разработки под 1С 7.7 (слава богу, уже более 10 лет назад ;)) и разработки под .net — под .net пишется лучше. Как минимум за счет инструментария платформы, не говоря уже о выразительности языка.
2. Когда на DSL можно нарисовать любую задачу — это уже не DSL в общем-то ;) Противоречит определению. Во-первых, большой DSL и универсальный DSL долго изучать. Увеличивает порог входа для новых программистов. Во-вторых, у вас в проекте может быть множество маленьких язычков и это вполне нормально, более того, в книжках пишут, что разрастание dsl — это bad smell о том, что задача неправильно декомпозирована и dsl придется бить на несколько отдельных маленьких.
3. Это один из самых больших плюсов DSL, да. Но чтобы так получилось, разработку нужно начинать с определения domain language.
На этот вопрос у меня заготовлен ответ. Отличительное свойство среды MPS — способность расширять языки, а не только писать их с нуля. То есть замена базового языка не предполагается.
Обычно код сколько-нибудь крупного проекта состоит из трех частей: готовые сторонние библиотеки, библиотеки, содержащие связанные с предметной областью проекта классы и функции, и код, реализующий конкретную функциональность. Сторонние библиотеки и библиотеки предметной области могут также навязывать правила написания кода, например, что каждому классу серверного интерфейса соответствует Javascript «класс», или что рядом с классами, работающими с базой данных, должен лежать соответствующий XML-файл.
Для сторонних библиотек вы можете ожидать, что их поддержка со стороны IDE будет написана сторонними же разработчиками. Со своими собственными библиотеками вам никто не поможет.
С помощью MPS вы можете добавить в IDE знания о своих библиотеках предметной области. И проблема «вавилонского столпотворения» угрожает вам в той же мере, что и без использования MPS. Не стоит в своем проекте использовать плохо совместимые технологии, и точно также надо стараться, чтобы код на ваших DSL выглядел единообразно.
Обычно код сколько-нибудь крупного проекта состоит из трех частей: готовые сторонние библиотеки, библиотеки, содержащие связанные с предметной областью проекта классы и функции, и код, реализующий конкретную функциональность. Сторонние библиотеки и библиотеки предметной области могут также навязывать правила написания кода, например, что каждому классу серверного интерфейса соответствует Javascript «класс», или что рядом с классами, работающими с базой данных, должен лежать соответствующий XML-файл.
Для сторонних библиотек вы можете ожидать, что их поддержка со стороны IDE будет написана сторонними же разработчиками. Со своими собственными библиотеками вам никто не поможет.
С помощью MPS вы можете добавить в IDE знания о своих библиотеках предметной области. И проблема «вавилонского столпотворения» угрожает вам в той же мере, что и без использования MPS. Не стоит в своем проекте использовать плохо совместимые технологии, и точно также надо стараться, чтобы код на ваших DSL выглядел единообразно.
тоже интересно было бы посмотреть сравнение решения задачи на классическом языке и на искусственном. что удастся сократить, на сколько и так далее.
спасибо.
спасибо.
никто не программит без использования IDE — личное дело каждого.
у вас просто нет понятия как отказаться от этого говна
у вас просто нет понятия как отказаться от этого говна
Выглядит заманчиво. Но куда интереснее было бы натравить подобную тулзу на существующий проект на той же Java и создавать DSL на основе уже написанного кода.
Отсюда вопрос: в какой степени MPS на данный момент позволяет интегрироваться с существующим жавокодом?
Отсюда вопрос: в какой степени MPS на данный момент позволяет интегрироваться с существующим жавокодом?
К автору. Почему нас нет в списке продуктов на платформе MPS?
www.realaxy.com
www.realaxy.com
Sign up to leave a comment.
Language Oriented Programming (LOP) в действии