Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).
Проблема начинается с невнятности терминологии. Примеры заблуждений и их обсуждение:
1. DSL — это любой ЯП (язык программирования) использованный в некотором приложении которое специализируется на какой-то предметной области. Примеры: VBA, 1С-язык. По этому же определению получается, что JavaScript-это тоже DSL, если его используют, например, в броузере. Все здорово ребята, но такое широкое трактование делает термин DSL бессмысленным, так как делает термины DSL, и ЯОН (язык программирования общего назначения) близнецами братьями. Стало быть смысл в использовании термина DSL просто исчезает. Или становится зависимым от контекста в кортом применяется язык. Типа LISP в Автокаде — это ДСЛ, а в командной строке — это ЯОН. Чушь!
2. Все на свете языки DSL по сравнению с менее мощными. Очевидно, что такая трактовка опять таки делает термин DSL бессмысленным. Разница с п.1 только в том, что в этот раз DSL-ем подменяется понятие мощность (которое и само плохо детерминировано).
3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык. С моделью можно работать через API. А DSL как раз и предназначен для того, чтобы корявое и не имеющее четких границ API заменить на четкий язык позволяющий заполнить эту модель конкретными данными. Простой пример — реализация КА (конечного автомата) — это модель. А язык позволяющий описывать состояния и переходы КА — это DSL.
4. DSL могут придумывать (выделять) только избранные. Это очень сложно и дано не каждому. В DSL самое важное — это модель. Хороший программист придумывая реализацию задачи разрабатывает модель. Если модель есть, то придумать для нее DSL уже не является сложной задачей. Тут нужно перейти психологический барьер, и дальше будет все довольно просто.
5. Есть мало задач для которых можно придумать DSL. Опять же (см. п.4), если вы можете придумать модель для описания задачи (объектную модель), то можно придумать и DSL.
6. DSL ничего не дает по сравнению с библиотеками. Дает и, порой, очень много. Причем бенефитов получается сразу несколько:
* DSL-и проще изучать и использовать.
* DSL позволяют оградить программистов от ошибок. Синтаксис + проверки в компиляторе/интерпретаторе DSL-я могут исключить целые классы ошибок. Сообщения об ошибках в DSL-ях могут быть значительно более информативными.
* Код на DSL будет всегда компактнее чем если аналогичный код писать вручную. Иногда компактнее на порядки.
* Использование DSL позволяет применять генерацию кода. Это позволяет использовать техники которые вы никогда не стали бы применять при написании кода вручную. Вы можете генерировать тупой но быстрый код. Или можете произвести проверку модели еще во время компиляции, что невозможно при применении библиотек, так как модели в них создаются исключительно в рантайме.
7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.
8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.
9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность). Это прозрачно намекает на то, что есть ряд задач для которых создавать DSL-и бессмысленно. Кроме того DSL-и частенько надо склеивать вместе. ЯОН может сделать это встраивая конструкции DSL-я в себя. Так же имеет место и обратный процесс. Некоторые DSL-и используют вхождения ЯОН для организации вычислений внутри себя (например, ASP). Я, правда, считаю это ошибкой дизайна, так как это легко превращает такие DSL в Тьюринг-полные языки, что плохо для DSL-ей. Но все же иногда без этого нельзя. Еще один аргумент — DSL-и на чем-то нужно писать. И последний аргумент — по DSL-ям (моделям лежащим под ними) частенько генерируется код. Для генерации проще всего использовать ЯОН. В прочем, можно использовать и другой DSL (более низкоуровневый и более универсальный), но его все равно надо будет так же во что-то преобразовывавший.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность).
Ох. Это ты себе нафантазировал.
ДСЛность языка можно определить только относительно домена конкретной задачи.
Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи.
ЯОН это язык в качестве целевого домена, которого использована не конкретная задача, а некая абстрактная хрень. ООП, ФП итп.
Бывают случаи, когда домен задачи является поддоменом некоторого ЯОН. В этом случае этот ЯОН становится ДСЛем для этой задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).
Здравствуйте, WolfHound, Вы писали:
VD>>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность). WH>Ох. Это ты себе нафантазировал.
Или ты.
WH>ДСЛность языка можно определить только относительно домена конкретной задачи.
Нет никакой ДСЛности. Есть ДСЛ и не ДСЛ. ДСЛ — это определение языка, а не свойство измеряемое в процентах.
WH>Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи.
Заблуждение 2:
2. Все на свете языки DSL по сравнению с менее мощными. Очевидно, что такая трактовка опять таки делает термин DSL бессмысленным. Разница с п.1 только в том, что в этот раз DSL-ем подменяется понятие мощность (которое и само плохо детерминировано).
ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.
WH>ЯОН это язык в качестве целевого домена, которого использована не конкретная задача, а некая абстрактная хрень. ООП, ФП итп.
От повторения одних и тех же заблуждений эти заблуждения не становятся истиной. ЯОН не имеет предметной области. Он универсален. Использование ЯОН в рамках прикладной задачи не меняет универсальную природу ЯОН.
ЯОН тем и отличается, что может сформировать модель для любой предметной области. А ДСЛ всегда имеет одну предопределенную модель которую и описывает этот ДСЛ. Именно привязка языка к конкретно модели и делает ДСЛ дслем. Погляди теорию моделей. Она как раз эти привязки и рассматривает.
WH>Бывают случаи, когда домен задачи является поддоменом некоторого ЯОН. В этом случае этот ЯОН становится ДСЛем для этой задачи.
Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
VD>>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).
N>Так что же такое DSL в твоём понимании?
Язык описывающий одну конкретную модель одной конкретной задачи. Например, грамматика описывает модель парсера. Или SQL описывает модель запроса, или регулярное выражение описывает модель конечного автомата распознающего строку.
По сути ДСЛ — это всегда конфигурационный файл для модели которую он описывает.
По сему 1С и VBA не ДСЛ-и, так как позволяют описать произвольные модели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.
SQL и XSLT позволяют решать задачи из любой предметной области (так как они тьюринг-полны). Являются ли они DSL-ями?
Здравствуйте, VladD2, Вы писали:
WH>>ДСЛность языка можно определить только относительно домена конкретной задачи. VD>Нет никакой ДСЛности. Есть ДСЛ и не ДСЛ. ДСЛ — это определение языка, а не свойство измеряемое в процентах.
Ты еще не дал ни одно определения, которое бы не развалилось от одного плевка.
WH>>Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи. VD>Заблуждение 2:
И причем тут это?
VD>ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.
Или ДСЛ должен быть полным по Тьюрингу и приехали.
С его помощью вдруг стало возможно решать любые задачи.
И ДСЛ превратился в ЯОН.
VD>От повторения одних и тех же заблуждений эти заблуждения не становятся истиной.
В зеркало посмотри.
VD>ЯОН не имеет предметной области. Он универсален. Использование ЯОН в рамках прикладной задачи не меняет универсальную природу ЯОН.
Это как это не имеет? Еще как имеет. От того что ты это отрицаешь C# не перестает быть языком поддерживающим работу с объектами. Это и есть его домен.
VD>ЯОН тем и отличается, что может сформировать модель для любой предметной области.
Не может.
Человек трансформирует модель предметной области в модель ЯОН.
Скажем если ты попытаешься закодировать ПЕГ на C# то тебе придется переводить термины ПЕГ в термины C#.
В ПЕГ нет ни классов, ни методов, ни виртуальных вызовов...
В C# нет ни приоритетного выбора, ни откатов, ни предикатов...
И как бы ты ни крутился, ты не сможешь ввести в C# термины ПЕГ. Что бы ты не делал. Какую бы ты архитектуру не наворачивал. Всё равно все сведется к классам, методам, циклам,...
VD>А ДСЛ всегда имеет одну предопределенную модель которую и описывает этот ДСЛ. Именно привязка языка к конкретно модели и делает ДСЛ дслем. Погляди теорию моделей. Она как раз эти привязки и рассматривает.
Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет.
Ибо у ЯОН есть своя модель и свой синтаксис.
VD>Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь.
Очень даже можно.
А вот твоим нельзя. Ибо если ДСЛ оказывается полным по Тьюрингу, то он уже и не ДСЛ получается. Даже не смотря на то, что задача решается в его терминах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nikov, Вы писали:
N>SQL и XSLT позволяют решать задачи из любой предметной области (так как они тьюринг-полны).
Начнем с того, что из гипотетической тьюринг-полноты не следует "позволяют решать задачи из любой предметной области". К примеру, отформатируй винт на ANSI SQL или XSLT. Или попробуй на том же ANSI SQL написать мало-мальски серьезное приложение. Если ты и сможешь это сделать (в чем я сильно сомневаюсь), это превратится в ад.
Так что практически эти языки невозможно использовать как ЯОН. Их модель слишком сложно использовать для эмуляции других моделей.
N>Являются ли они DSL-ями?
Являются. Но несомненно тюринг-полнота — это ошибка дизайна. Или, по крайней мере, не самая лучшая черта языка.
Кстати, и без тьюринг-полноты можно успешно использовать вещи не по назначению. Скажем на регулярных выражениях гипотетически можно решать некоторые логические задачи. Но попробуй сделать это на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По сему 1С и VBA не ДСЛ-и, так как позволяют описать произвольные модели.
Я в ту тему не решился влезать (сообщений слишком много, еще и ругаетесь там между собой ), поэтому возможно эту мысль уже кто-то высказал... ИМХО, проблема недопонимания тут в том, что многие путают DSL с DSF (domain specific framework). 1С, VBA, javascript — это ЯОП к прикрученными к ним DSF'ами. Т.е. их предметно-ориентированность определяется именно наличием наглухо встроенных библиотек, объектных моделей и тому подобной радости, не имеющей прямого отношения к этим языкам. Вместо любого из них можно воткнуть произвольный ЯОП и "степень предметно-ориентированности" от этого не изменится, т.к. определяется внешними по отношению к языку средствами.
DSL'ем же язык является тогда, когда его дизайн исключает необходимость использования внешних DSF и не требует их разработки на этом языке для решения задач предметной области.
Здравствуйте, WolfHound, Вы писали:
VD>>ЯОН тем и отличается, что может сформировать модель для любой предметной области. WH>Не может. WH>Человек трансформирует модель предметной области в модель ЯОН. WH>Скажем если ты попытаешься закодировать ПЕГ на C# то тебе придется переводить термины ПЕГ в термины C#.
Мне придется описать на шарпе модель ПЕГ-а. Только и всего. Ты зделал это на Немерле. Это же можно сделать и на шарпе. Сложнее, но можно. ЯОН есть ЯОН.
WH>В ПЕГ нет ни классов, ни методов, ни виртуальных вызовов...
В Н тоже нет сущностей ПЕГ-а. Но тебе это не помешало создать вот эту модель.
WH>В C# нет ни приоритетного выбора, ни откатов, ни предикатов...
И не нужно. Зато в нем есть все чтобы воспроизвести любую модель! А модель уже можно заполнить (грамматикой, например, через АПИ) и интерпретировать или компилировать (в те же экспрешон-три, например).
WH>И как бы ты ни крутился, ты не сможешь ввести в C# термины ПЕГ. Что бы ты не делал. Какую бы ты архитектуру не наворачивал. Всё равно все сведется к классам, методам, циклам,...
И не надо вводит. ЯОН может создать модель не вводя в своей лексикон термины модели.
WH>Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет.
ДСЛ частный случай языка. Теория не может быть завязана на частные случаи.
WH>Ибо у ЯОН есть своя модель и свой синтаксис.
Ну, да. Только для ЯОН — это модель Фон Нэймана. А у этой модели есть одна характерная черта — она позволяет решать любые задачи, в том числе и формировать модели.
Вот в этом и отличие ДСЛ от ЯОН. ЯОН может все так как его модель универсальна. ДСЛ может только то, что позволяет его модель.
VD>>Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь. WH>Очень даже можно. WH>А вот твоим нельзя. Ибо если ДСЛ оказывается полным по Тьюрингу, то он уже и не ДСЛ получается. Даже не смотря на то, что задача решается в его терминах.
Я уже отвечал на этот вопрос много раз. Читай что я писал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мне придется описать на шарпе модель ПЕГ-а. Только и всего. Ты зделал это на Немерле. Это же можно сделать и на шарпе. Сложнее, но можно. ЯОН есть ЯОН.
Ты можешь ее описать на шарпе. Но не добавить в C#.
Ибо, какие бы ты классы не описывал на C#, ты всё равно будешь использовать классы и методы, а не правила ПЕГ.
VD>В Н тоже нет сущностей ПЕГ-а. Но тебе это не помешало создать вот эту модель.
Так она не в Н. А сама по себе. От того что я описал на Н модель ПЕГ в самом Н она не появилась.
VD>И не нужно. Зато в нем есть все чтобы воспроизвести любую модель! А модель уже можно заполнить (грамматикой, например, через АПИ) и интерпретировать или компилировать (в те же экспрешон-три, например).
Нет. Что бы ты ни делал, ты всё равно будешь на C# работать в терминах C#.
WH>>Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет. VD>ДСЛ частный случай языка. Теория не может быть завязана на частные случаи.
Вот и не приплетай теорию просто так.
WH>>Ибо у ЯОН есть своя модель и свой синтаксис. VD>Ну, да. Только для ЯОН — это модель Фон Нэймана.
Тут ты не прав. Тот же C# не имеет ничего общего с моделью Фон Нэймана. И может с тем же успехом транслироваться в Гарвардскую архитектуру.
VD>А у этой модели есть одна характерная черта — она позволяет решать любые задачи, в том числе и формировать модели.
Она не позволяет решать любые задачи в терминах предметной области.
Она позволяет перевести в нее любой домен.
Руками или компилятором не важно.
Но всегда есть процесс превращение терминов предметной области в термины целевой вычислительной модели.
То, что ты в своей голове научился делать прямой и обратный перевод совершенно не означает, что в C# вдруг появились термины предметной области.
VD>Вот в этом и отличие ДСЛ от ЯОН. ЯОН может все так как его модель универсальна. ДСЛ может только то, что позволяет его модель.
Любой полный по Тьюрингу язык может все.
Это доказано строго математически.
VD>Я уже отвечал на этот вопрос много раз. Читай что я писал.
Ничего ты не ответил.
Твое определение разбивается о вычислительную полноту.
А так как ДСЛи бывают и полными по Тьюрингу то твое определение неприемлемо.
Оно вообще содержит слишком много субъективности.
Мое же определение объективно. И для него даже при желании метрику придумать можно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL.DSL, уважаемые, это в первую очередь ЯЗЫК.Модель ни разу не язык.
Любая модель — язык, и при этом модель ни разу не язык
Язык это в основном синтаксим синтаксис, а модель в основном семантика. Вот так всё становится на свои места.
VD>4. DSL могут придумывать (выделять) только избранные. Это очень сложно и дано не каждому. В DSL самое важное — это модель. Хороший программист придумывая реализацию задачи разрабатывает модель. Если модель есть, то придумать для нее DSL уже не является сложной задачей. Тут нужно перейти психологический барьер, и дальше будет все довольно просто.
Для того, что бы выяснить, где же сложность и чем она обсуловлена, нужно четко разделить понятия модель и язык. Судя по противоречию которое ты выдал, ты сам плохо понимаешь, в чем причина барьеров.
VD>7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.
См, выше — у тебя путаница между моделью и дсл. Изучать нужно в первую очередь модель, то есть, семантику. Понять её по ДСЛ часто не только сложно, но и вообще невозможно.
VD>8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.
Вот бы кто выдал формулу нахождения границы разумности-неразумности.
И мифы про ДСЛ : "Если модель есть, то придумать для нее DSL уже не является сложной задачей."
Придумать язык не сложно. Сложно придумать язык, который будет легко поддерживаться, расширяться, будет легок в изучении. А еще трудно придумать язык в котором на раз будут решаться проблемы с производитеностью. Глядя на известные ДСЛ совершенно не очевидно, что второе и третье это легко.
Здравствуйте, Ikemefula, Вы писали:
VD>>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL.DSL, уважаемые, это в первую очередь ЯЗЫК.Модель ни разу не язык.
I> Любая модель — язык, и при этом модель ни разу не язык
Ну, вот и представитель этого заблуждения появился.
I>Язык это в основном синтаксим синтаксис, а модель в основном семантика. Вот так всё становится на свои места.
Ага. И язык без синтаксиса не бывает. Без семантики тоже не бывает, так что модель должна быть у любого языка. Но наличие модели не создает автоматом язык. Для одной модели можно придумать большое количество синтаксисом.
I>Для того, что бы выяснить, где же сложность и чем она обсуловлена, нужно четко разделить понятия модель и язык. Судя по противоречию которое ты выдал, ты сам плохо понимаешь, в чем причина барьеров.
в зеркало посмотри. Ты отрицаешь очевидное. У тебя возможен язык без синтаксиса.
Короче, как всегда обсуждать с тобой особо не чего. Сори, дальше читать не стал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>См, выше — у тебя путаница между моделью и дсл. Изучать нужно в первую очередь модель, то есть, семантику. Понять её по ДСЛ часто не только сложно, но и вообще невозможно.
DSL это всего лишь способ упростить код. Код проще для понимания будет проще и для поддержки. Вот смотри, есть задача для маппинга RESTful урлов. Если ты сталкивался, то знаешь, что в ASP.NET MVC замапить контроллер ресурсов так достаточно неудобно.
Если бы была возможность сделать нормальный DSL, код превратился бы в:
Resources Stories
{
Member
{
Except new, edit, index;
Put ChangePosition, Bind, Unbind;
Resources StoryBlocks;
}
Collection
{
Get Feed, GetIndependent, SearchIndependent, Search;
}
}
Гораздо приятнее в поддержке, ключевые слова будут подсвечены, обеспечит контроль контроллеров и их методов на этапе компиляции. На этапе выполнения тоже есть плюсы, выполняться будет код создания маршрутов, а не код их конфигурации, а потом уже создания по ней.
И, самое главное по теме, сложность разработки и поддержки этого DSL будет ниже чем сложность разработки eDSL приведенного выше. Все кто писал более менее сложные fluent DSL меня поймут. Сложность использования у нас тоже не всегда в пользу первого, а уж в N2, где можно будет обеспечить свой автокомплит вообще сравнивать не приходится.
Здравствуйте, VladD2, Вы писали:
VD>>>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL.DSL, уважаемые, это в первую очередь ЯЗЫК.Модель ни разу не язык. I>> Любая модель — язык, и при этом модель ни разу не язык VD> Ну, вот и представитель этого заблуждения появился.
Я вообще то сказал, что ДСЛ и модель это совершенно разные вещи. раз ты считаешь, что это заблуждение, то с тобой не о чем говорить.
кодом проекта.
VD>8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.
VD>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность). Это прозрачно намекает на то, что есть ряд задач для которых создавать DSL-и бессмысленно. Кроме того DSL-и частенько надо склеивать вместе. ЯОН может сделать это встраивая конструкции DSL-я в себя. Так же имеет место и обратный процесс. Некоторые DSL-и используют вхождения ЯОН для организации вычислений внутри себя (например, ASP). Я, правда, считаю это ошибкой дизайна, так как это легко превращает такие DSL в Тьюринг-полные языки, что плохо для DSL-ей. Но все же иногда без этого нельзя. Еще один аргумент — DSL-и на чем-то нужно писать. И последний аргумент — по DSL-ям (моделям лежащим под ними) частенько генерируется код. Для генерации проще всего использовать ЯОН. В прочем, можно использовать и другой DSL (более низкоуровневый и более универсальный), но его все равно надо будет так же во что-то преобразовывавший.
Я тут давно предлагаю вариант унивесального языка с единым синтаксисом и на нем можно строить другие языки со своими терминами, но правила синтасиса остается теми же. Но надо кое-что в голове изменить. Потому я не согласен что ЯОН дожен умереть. Предметные языки само собой буду развиваться. Причины очевидны.
Здравствуйте, Ziaw, Вы писали:
Z>Гораздо приятнее в поддержке, ключевые слова будут подсвечены, обеспечит контроль контроллеров и их методов на этапе компиляции. На этапе выполнения тоже есть плюсы, выполняться будет код создания маршрутов, а не код их конфигурации, а потом уже создания по ней.
Это пример дсл который вобщем то и не нужен. Написать хороший интерфейс для мапинга урлов и дело в шляпе.
Z>И, самое главное по теме, сложность разработки и поддержки этого DSL будет ниже чем сложность разработки eDSL приведенного выше. Все кто писал более менее сложные fluent DSL меня поймут.
Эх, если бы все было так прекрасно...
VD>6. DSL ничего не дает по сравнению с библиотеками. Дает и, порой, очень много. Причем бенефитов получается сразу несколько: VD>* DSL-и проще изучать и использовать. VD>* DSL позволяют оградить программистов от ошибок. Синтаксис + проверки в компиляторе/интерпретаторе DSL-я могут исключить целые классы ошибок. Сообщения об ошибках в DSL-ях могут быть значительно более информативными. VD>* Код на DSL будет всегда компактнее чем если аналогичный код писать вручную. Иногда компактнее на порядки. VD>* Использование DSL позволяет применять генерацию кода. Это позволяет использовать техники которые вы никогда не стали бы применять при написании кода вручную. Вы можете генерировать тупой но быстрый код. Или можете произвести проверку модели еще во время компиляции, что невозможно при применении библиотек, так как модели в них создаются исключительно в рантайме.
1. Увы, не всегда. Изучение новой грамматики очень часто (на опыте) ухудшает процесс написания. Именно из-за этого DSL на основе XML зачастую лучше, чем с более естественной для области грамматикой (хотя и выглядит ужасно).
2. Делать DSL с хорошим описанием ошибок заметно сложнее, чем API с таким же описанием ошибок
3. Вообще, многие библиотеки вполне себе создают код в рантайме, делов-то
VD>7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.
Увы, увеличивает. Программисту нужно изучить DSL, каркас для создания DSL, конкретный код. Если DSL генерит код — то еще и сгенеренный код.
Вообще, основная проблема с DSL в данный момент — полное отсутствие нормальных подходов (с библиотеками, примерами, грамматиками и т.п.) для их создания.
PEG не позволяет описывать некоторые примитивные конструкции, всяческие наследники lexx требуют отслеживания нежелательных рекурсий, и все они требуют слишком много разных специфических знаний.
Тогда как на практике нужен один! простой способ записи грамматики языка с возможностью потом _легко_ работать с построенным AST-деревом или просто деревом разбора.
При этом, например, комментарии должны поддерживаться из коробки.
Эх, пустое это дело — спор о терминах, но все же доавлю свои пять копеек.
1) Понятие DSL — оно не абсолютное. Ну то есть, если взять конкретный язык в отрыве от обстоятельств, даже подразумеваемых, то вряд ли можно будет четко сказать — DSL это или нет. Язык становится DSL только в рамках его разработки и применения. Т.е. если язык создан и применяется только для разработки в определенном домене, то это DSL. Если он применяется для решения широкого спектра задач — не DSL.
2) Второй важный момент, вытекающий из определения DSL — терминология (first clas citizens) языка должна быть увязана с терминологией какой то конкретной области.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>1. Увы, не всегда. Изучение новой грамматики очень часто (на опыте) ухудшает процесс написания. Именно из-за этого DSL на основе XML зачастую лучше, чем с более естественной для области грамматикой (хотя и выглядит ужасно).
Категорически несогласен. XML-ные ДСЛ-и всегда хуже чем имеющие полноценный синтаксис. А применяют XML по той лишь причине, что его проще обрабатывать парсить и генерировать. То есть, от бедности инструментария. По тем же причинам применяются и встроенные ДСЛ-и.
ДФ>2. Делать DSL с хорошим описанием ошибок заметно сложнее, чем API с таким же описанием ошибок
существенно упростит обработку ошибок.
ДФ>3. Вообще, многие библиотеки вполне себе создают код в рантайме, делов-то
А ты спроси у их авторов чего им это стоит. К тому же в подавляющем большинстве случаев код можно было бы создавать и в компайл-тайме. А это позволяет выявлять множество ошибок еще до запуска приложения.
К тому же библиотеки генерирующие код зачастую сами предлагают свои ДСЛ-и. Но обычно встроенные (на основе хост языка) или на основе атрибутов.
VD>>7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.
ДФ>Увы, увеличивает. Программисту нужно изучить DSL, каркас для создания DSL, конкретный код. Если DSL генерит код — то еще и сгенеренный код.
Это форменное заблуждение. Изучать "каркас для создания DSL" не надо вовсе. Ты же не изучаешь средства использованные для создания компилятора С++ или C#? А с ДСЛ-ями почему должно быть по другому?
В остально, я уже все сказал. Ты доблестно проигнорировал (или не понял) сказанного. Прочти еще раз. Не вижу смысла повторяться.
ДФ>Вообще, основная проблема с DSL в данный момент — полное отсутствие нормальных подходов (с библиотеками, примерами, грамматиками и т.п.) для их создания.
Согласен. Нет вменяемых средств разработки. И нет методологий. Хотя кое что можно почерпнуть из трудов того же Фаулера.
ДФ>PEG не позволяет описывать некоторые примитивные конструкции,
Чего? Примеры в студию, плиз. А то мы грамматику C# с его помощью описать умудрились, а тут такое.
ДФ>всяческие наследники lexx требуют отслеживания нежелательных рекурсий, и все они требуют слишком много разных специфических знаний.
Я не знаю кто такой lexx и что там у него с рекурсией. Думаю, ты что-то перепутал. Но в целом могу согласиться. Средства создания своих языков на сегодня выглядят очень печально. В основном покрыта только разработка парсеров, да и здесь имеется куча проблем. Даже стыковка своего окружения с генератором парсеров вызывает массу проблем.
ДФ>Тогда как на практике нужен один! простой способ записи грамматики языка с возможностью потом _легко_ работать с построенным AST-деревом или просто деревом разбора.
+1
Скажу больше. Кроме дерева разбора еще нужно иметь высокоуровневый механизм типизации (выявления семантических ошибок). А так же механизм трансформации кода. Ведь зачастую от ДСЛ больше толка, если он переписывается в более низкоуровневый язык который потом подвергается компиляции.
ДФ>При этом, например, комментарии должны поддерживаться из коробки.
Комментраии это самая простая проблема. Тут много чего должно поддерживаться из коробки. Например, должно быть автоматическое отслеживание местположений всех конструкций языка, так чтобы в процессе семантического анализа можно было выдать сообщение об ошибке указывающие на то место программы (на ДСЛ-е) в котором произошла ошибка.
Так же должны быть обширные библиотеки языков, чтобы не надо было писать весь свой ДСЛ с нуля. Нужна тебе арифметика, или скажем выражения — возьми их из библиотеки.
Короче, для данной области нужны свои — крутые ДСЛ-и. Вот этим мы сейчас и занимаемся в проекте N2
Здравствуйте, Ikemefula, Вы писали:
I>Полнота по тьюрингу не имеет никакого отношения к дсл.
Имеет. Хороший ДСЛ не должен быть полон по тьюрингу. Наличие оной уже указывает на протекание абстракции. Все случаи полноты по тьюрингу в ДСЛ-ях являются скорее побочным эффектом получающимся от стремления авторов ДСЛ-ей к излишней универсализации ДСЛ-ей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
VD>>>>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL.DSL, уважаемые, это в первую очередь ЯЗЫК.Модель ни разу не язык. I>>> Любая модель — язык, и при этом модель ни разу не язык VD>> Ну, вот и представитель этого заблуждения появился.
I>Я вообще то сказал, что ДСЛ и модель это совершенно разные вещи. раз ты считаешь, что это заблуждение, то с тобой не о чем говорить.
Может я тебя не так понял, то если ты со мной согласен, то зачем влезал?
Я перечислял заблуждения, и описывал почему это заблуждения. Так что я ни разу не утверждал, что модель и язык это одно и тоже. Наоборот, я считаю это заблуждением.
Однако говорить, что это совсем разные вещи тоже не верно. Модель и язык тесно связаны. Семантическая модель — это то что определяет смысл языка и то во что язык преобразуется в результате синтаксического разбора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
WH>>>Ибо у ЯОН есть своя модель и свой синтаксис. VD>>Ну, да. Только для ЯОН — это модель Фон Нэймана. WH>Тут ты не прав. Тот же C# не имеет ничего общего с моделью Фон Нэймана. И может с тем же успехом транслироваться в Гарвардскую архитектуру.
А не подскажите, почему C# не имеет ничего общего с моделью Фон Нэймана? И причем здесь Гарвардская архитектура?
Если под моделью Фон Нэймана понимать это, то да, а так не совсем понятно зачем сравнивать арх-ру компьютерая и яп.
Сущности, как модно говорить в этом треде, из разного домена.
Здравствуйте, VladD2, Вы писали: VD>Начнем с того, что из гипотетической тьюринг-полноты не следует "позволяют решать задачи из любой предметной области". К примеру, отформатируй винт на ANSI SQL или XSLT
<trollmode>
:SQL
Если ты хоть раз писал на любом популярном SQL, то знаешь, что отформатировать винт на SQL можно
:XSLT
Ф тебя и тут разочарую...
</trollmode>
Сразу видно — ни с sql, ни с трансформациями ты не работал. Загляни в стандарты обоих языков, да просветлись. В обоих языках есть стандартные механизмы расширения, делающие их всемогущими.
Здравствуйте, Sharov, Вы писали:
S>А не подскажите, почему C# не имеет ничего общего с моделью Фон Нэймана?
хъ S>Сущности, как модно говорить в этом треде, из разного домена.
Сам же и ответил на свой вопрос.
S>И причем здесь Гарвардская архитектура?
При том, что транслировать C# или точнее MSIL в можно в машинные коды разных процессоров.
В том числе и тех, которые не имеют к архитектуре фон Неймана никакого отношения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>DSL'ем же язык является тогда, когда...
Я бы придерживался все же конкретных дефиниций (хотя бы на основе той же ру.кипедии), а не всевозможных IMHO. типа Владовских либо твоих.
Там в целом нормально сказано и близко моему интуитивному пониманию:
In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique.
Как видишь в данном определении нет ни условия тьюринг-(не-)полноты, ни каких-то особенных свойств.
Здравствуйте, Wolverrum, Вы писали:
W>Как видишь в данном определении нет ни условия тьюринг-(не-)полноты, ни каких-то особенных свойств.
Я не вполне понял — ты хочешь, чтобы в википедии появилось мое определение? Но даже безотносительно вопроса корректности тамошних "дефиниций" — в чем это противоречит тому, что написал я?
VD>Я перечислял заблуждения, и описывал почему это заблуждения. Так что я ни разу не утверждал, что модель и язык это одно и тоже. Наоборот, я считаю это заблуждением.
VD>Однако говорить, что это совсем разные вещи тоже не верно. Модель и язык тесно связаны. Семантическая модель — это то что определяет смысл языка и то во что язык преобразуется в результате синтаксического разбора.
Будет ли правильно сказать что удачный DSL язык должен содержать удачно подобраные примитивы (с их семантическим содержанием) для построения модели соответсвующей предметной области?
Здравствуйте, Ikemefula, Вы писали:
Z>>Гораздо приятнее в поддержке, ключевые слова будут подсвечены, обеспечит контроль контроллеров и их методов на этапе компиляции. На этапе выполнения тоже есть плюсы, выполняться будет код создания маршрутов, а не код их конфигурации, а потом уже создания по ней.
I>Это пример дсл который вобщем то и не нужен. Написать хороший интерфейс для мапинга урлов и дело в шляпе.
Я тебе привел пример написанного хорошего интерфейса для RESTful маппинга. Если у тебя есть пример получше почему бы тебе его не привести.
Z>>И, самое главное по теме, сложность разработки и поддержки этого DSL будет ниже чем сложность разработки eDSL приведенного выше. Все кто писал более менее сложные fluent DSL меня поймут.
I>Нет, не понятно. Объясняй.
Ок, давай на примерах. Есть задача: ACL. Нужно около сотни правил вида:
пользователь (Роль|предикат принимающий пользователя) [не]имеет право совершать действие Д над объектом (Тип|строка|предикат принимающий экземпляр).
в одном правиле может быть указано несколько ролей, действий, констрейнтов на объект.
Давай, ты набросаешь удобный интерфейс для записи правил, и проверок, а я DSL на Nemerle. Результаты выложим здесь и сравним.
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).
VD>Проблема начинается с невнятности терминологии. Примеры заблуждений и их обсуждение: VD>1. VD>2.
Согласен.
VD>3. DSL, уважаемые, это в первую очередь ЯЗЫК.
Да. Но дальше — какая-то феерия. VD>5. Опять же (см. п.4), если вы можете придумать модель для описания задачи (объектную модель), то можно придумать и DSL.
Вот лично мне кажется, что ты слово "модель" (в т.ч. п-т №3) используешь слишком узко. Короче — по пятому пункту низачот.
VD>6. Дает и, порой, очень много.
Подчеркнутое является ключевым. К примеру, в моей команде такая "пора" для XSLT возникла 3 раза за последний год. Для самопального DSL конечно, почаще
VD>4. ...придумать для нее DSL уже не является сложной задачей.
Из текущего опыта: муки рождения DSLя продолжаются уже полгода. И задача не сказать что сложная, и не сказать, что не продумывалась, и не сказать, что выбранный ЯП как-то мешает разработке DSL — наоборот, сильно помог (и это не Немерле ), но времени (=работы) отняла уже дофига.
и к №4: VD>7. Все в точности на оборот.
Ну, если оборот градусов сорок — то да, уменьшает
А вообще, педия с тобой не согласна:
* Cost of designing, implementing, and maintaining a domain-specific language as well as the tools required to develop with it (IDE)
* Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
* Non-technical domain experts can find it hard to write or modify DSL programs by themselves
* Increased difficulty of integrating the DSL with other components of the IT system (as compared to integrating with a general-purpose language).
А я вот по пунктам согласен, особливо, с последним.
VD>8. Разумное применение DSL-ей
Зыыыыыбко!
VD>9. Не мало (sic!) задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность).
1. И что же такое DSL-ность?
2. Педия определяет DSL как:
In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique.
и приводит прикольный пример DSLя:
The Erlang Open Telecom Platform was originally designed for use inside Ericsson as a domain specific language.
Что собственно, навевает на мысль, что все-таки твое "опровержение" (выд. жир.) — чушь.
Грамматический PS: тебя уже реально сложно читать.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Но даже безотносительно вопроса корректности тамошних "дефиниций" — в чем это противоречит тому, что написал я?
Не то, чтобы противоречит:
DSL'ем же язык является тогда, когда его дизайн исключает необходимость использования внешних DSF и не требует их разработки на этом языке для решения задач предметной области.
но мне кажется, это высказывание налагает некоторые (ненужные, в общем-то) доп. ограничения на определение DSL
Здравствуйте, Wolverrum, Вы писали:
W><trollmode> W>:SQL W>Если ты хоть раз писал на любом популярном SQL, то знаешь, что отформатировать винт на SQL можно
W>:XSLT W>Ф тебя и тут разочарую... W></trollmode>
Уважаемому троллю нужно немного поднабраться знаний и тогда он узнает, что SQL-ем является только ANSI/ISO SQL, а всякие там TSQL и прочие PL/SQL являются процедурными расширениями SQL, или по научному ЯОН-ами. PL так и расшифровывается — Procedural Language.
W>Сразу видно — ни с sql, ни с трансформациями ты не работал. Загляни в стандарты обоих языков, да просветлись. В обоих языках есть стандартные механизмы расширения, делающие их всемогущими.
Твоя телепатия тебя подвела. Я игрался с TSQL еще в 1994-ом году (в MS SQL 4.2), а в 1995-ом уже во всю писал на нем запросы для разных оборотных ведомостей с использованием локальных таблиц и прочей ереси. Вот только всемогущество не заметил. Заметил убогость. Убогие и мало понятно зачем нужные курсоры. Убогие циклы. Жуткое ограничите на глубину рекурсии. В общем, всего и не упомнишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, batu, Вы писали:
B>Будет ли правильно сказать что удачный DSL язык должен содержать удачно подобраные примитивы (с их семантическим содержанием) для построения модели соответсвующей предметной области?
Не совсем. Модель предметной области — это тоже туманный термин, но в основном под ним подразумевается некая большая модель приложения. Такая модель может состоять из множества более мелких, конкретных моделей. Лучше называть модель лежащую в основе ДСЛ-я семантической моделью языка (ДСЛ-я).
В такой постановке — да, хороший ДСЛ всегда имеет под собой хорошую семантическую модель.
Грубо говоря модль хорошего ДСЛ-я должна быть моделью отдельной задачи (парсера, преобразователя ХМЛ в текст, описателя конечного автомата, и т.п.).
Иногда такой моделью выступает АСТ. Но это как раз не очень здорово, так как АСТ обладает излишнем шумом и конкретикой не нужной для модели. А это как и в случае применения АПИ негативно сказывается на качестве реализации ДСЛ-я.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
W>>Сразу видно — ни с sql, ни с трансформациями ты не работал. Загляни в стандарты обоих языков, да просветлись. В обоих языках есть стандартные механизмы расширения, делающие их всемогущими.
VD>Твоя телепатия тебя подвела. Я игрался с TSQL еще в 1994-ом году (в MS SQL 4.2), а в 1995-ом уже во всю писал на нем запросы для разных оборотных ведомостей с использованием локальных таблиц и прочей ереси.Вот только всемогущество не заметил. Заметил убогость. Убогие и мало понятно зачем нужные курсоры. Убогие циклы. Жуткое ограничите на глубину рекурсии. В общем, всего и не упомнишь.
Во-первых надо было с ним работать, а не играться. Ну да ладно.
Во-вторых, VD> что SQL-ем является только ANSI/ISO SQL
Открой для себя уже хотя бы ISO/IEC 9075:2003...
Здравствуйте, Wolverrum, Вы писали:
VD>>5. Опять же (см. п.4), если вы можете придумать модель для описания задачи (объектную модель), то можно придумать и DSL. W>Вот лично мне кажется, что ты слово "модель" (в т.ч. п-т №3) используешь слишком узко.
Просто термин "модель" тоже перегружен и мутноват. Тут речь идет о конкретной обособленной модели одной задачи, а не о большой модели всего приложения. Такая модель становится семантической моделью языка. Подробнее смотри здесь
VD>>6. Дает и, порой, очень много. W>Подчеркнутое является ключевым. К примеру, в моей команде такая "пора" для XSLT возникла 3 раза за последний год.
Ты не правильно выделил. Надо так порой, очень.
Ты же говоришь о другом. О том, что вы не часто находите применение ДСЛ. Так это пункт 5, а не 6.
Потом ДСЛ-и разные бывают. Регексы и SQL вы не используете?
W>Для самопального DSL конечно, почаще
+1 Вот и нужно научиться их делать легко и просто.
VD>>4. ...придумать для нее DSL уже не является сложной задачей. W>Из текущего опыта: муки рождения DSLя продолжаются уже полгода. И задача не сказать что сложная, и не сказать, что не продумывалась, и не сказать, что выбранный ЯП как-то мешает разработке DSL — наоборот, сильно помог (и это не Немерле ), но времени (=работы) отняла уже дофига.
Что за язык? И в чем кроются проблемы?
W>А вообще, педия с тобой не согласна: W>
W>* Cost of designing, implementing, and maintaining a domain-specific language as well as the tools required to develop with it (IDE)
W>* Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
W>* Non-technical domain experts can find it hard to write or modify DSL programs by themselves
W>* Increased difficulty of integrating the DSL with other components of the IT system (as compared to integrating with a general-purpose language).
W>А я вот по пунктам согласен, особливо, с последним.
Это все разговор о том что инструменты для создания и интеграции ДСЛ-ев с ЯОН-ами никуда не годны на сегодня.
А Вольфхаунд и поднял эту тему, что работает над созданием средства которое снимет вопросы реализации и поддержки ДСЛ-ей и оставит только проблему дизайна. Ну, а ее можно решить путем систематизации зананий в этой области и выработки хорошей практики.
VD>>8. Разумное применение DSL-ей W>Зыыыыыбко!
Ну, уж извини. Знавал я людей которые и банальную задачу перевода числе в сумму прописью превращала в фейерверк идиотизма используя для этой цели ООП не по назначению.
Понятно, что при глупом использовании чего угодно можно и хрен сломать. (с) народная мудрость.
W>
W>In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique.
W>и приводит прикольный пример DSLя: W>
W>The Erlang Open Telecom Platform was originally designed for use inside Ericsson as a domain specific language.
Дык в Википедию любой прохожий может что угодно написать. Если учесть, что даже на проффесиональном форуме никто к единому мнению не может прийти, то уже туда точно хрени понаписано не мало.
Эрланг такой же ЯОН как и любой другой. В него банально захардкожена некоторые фичи по организации многозадачности. Ничего специфичного для телекома там не и не было. По этому Эрланг с успехом применяют в совершенно разных областях где нужен массовый параллелизм.
W>Что собственно, навевает на мысль, что все-таки твое "опровержение" (выд. жир.) — чушь.
W>Грамматический PS: тебя уже реально сложно читать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Wolverrum, Вы писали:
VD>>Твоя телепатия тебя подвела. Я игрался с TSQL еще в 1994-ом году (в MS SQL 4.2), а в 1995-ом уже во всю писал на нем запросы для разных оборотных ведомостей с использованием локальных таблиц и прочей ереси.Вот только всемогущество не заметил. Заметил убогость. Убогие и мало понятно зачем нужные курсоры. Убогие циклы. Жуткое ограничите на глубину рекурсии. В общем, всего и не упомнишь.
W>Во-первых надо было с ним работать, а не играться. Ну да ладно.
А ты не выдирай фразы из контекста. В 94-ом игрался, в 95-ом работал. Только не на 4.2, а уже на 6.0 (с какого перепуга он стал 6.0 до сих пор понят не могу).
W>Во-вторых, VD>> что SQL-ем является только ANSI/ISO SQL W>Открой для себя уже хотя бы ISO/IEC 9075:2003...
Это и есть ISO. Перестань позориться пытаясь из меня тут мальчика сделать.
Заранее отвечаю, что про CTE я знаю, если вдруг тебе и про это захочется спросить.
W>В-третьих >>поднабраться знаний W>"Или ты." (c) VladD2
ДФ>>1. Увы, не всегда. Изучение новой грамматики очень часто (на опыте) ухудшает процесс написания. Именно из-за этого DSL на основе XML зачастую лучше, чем с более естественной для области грамматикой (хотя и выглядит ужасно).
VD>Категорически несогласен. XML-ные ДСЛ-и всегда хуже чем имеющие полноценный синтаксис. А применяют XML по той лишь причине, что его проще обрабатывать парсить и генерировать. То есть, от бедности инструментария. По тем же причинам применяются и встроенные ДСЛ-и.
Повторю еще раз: при изучении нового языка (даже DSL), крайне желательно опираться на знакомую грамматику. Поэтому удобнее всего делать новые языки или на основании основного языка проекта или на каком-нибудь общеупотребительном (типа XML).
Мне на порядок проще, например, прочитать описание конфигурации системы на XML, нежели на каком-нибудь DSL с неизвестной мне грамматикой.
Что, конечно, не отменяет ужасности всех DSL на основе XML
ДФ>>2. Делать DSL с хорошим описанием ошибок заметно сложнее, чем API с таким же описанием ошибок VD>Согласен, но это вопрос технологий. N2
Я в мире Java, что мне с N2
ДФ>>3. Вообще, многие библиотеки вполне себе создают код в рантайме, делов-то VD>А ты спроси у их авторов чего им это стоит. К тому же в подавляющем большинстве случаев код можно было бы создавать и в компайл-тайме. А это позволяет выявлять множество ошибок еще до запуска приложения.
Ну, вообще для той-же Java есть таки способы легко делать код в рантайме. Хотя, конечно, отлаживать такое еще хуже, чем DSL.
ДФ>>Увы, увеличивает. Программисту нужно изучить DSL, каркас для создания DSL, конкретный код. Если DSL генерит код — то еще и сгенеренный код.
VD>Это форменное заблуждение. Изучать "каркас для создания DSL" не надо вовсе. Ты же не изучаешь средства использованные для создания компилятора С++ или C#? А с ДСЛ-ями почему должно быть по другому?
А, вот тут все чуть-чуть по другому. Если я для описания какого-нибудь домена создаю DSL, то совершенно точно, что в будушем этот DSL придется дорабатывать (так как любая предметная область в проекте развивается). Т.е новому программисту придется знать, как можно расширить DSL — т.е. изучать-таки каркас.
Все-таки, результатом работы нового программиста является не столько код на DSL (что скучно...), сколько сам по себе DSL
ДФ>>PEG не позволяет описывать некоторые примитивные конструкции, VD>Чего? Примеры в студию, плиз. А то мы грамматику C# с его помощью описать умудрились, а тут такое.
Ну, описать простым и естественным способом, например, упорядоченную последовательность необязаетельных токенов или выражений.
В C# таких, насколько я знаю, просто нет, а вот в DSL для конечного пользователя — сплошь и рядом
VD>Комментраии это самая простая проблема. Тут много чего должно поддерживаться из коробки. Например, должно быть автоматическое отслеживание местположений всех конструкций языка, так чтобы в процессе семантического анализа можно было выдать сообщение об ошибке указывающие на то место программы (на ДСЛ-е) в котором произошла ошибка.
Ну, в том PEG-парсере, что я использую — такое есть. А вот с комментариями, увы, приходится возиться руками.
VD>Так же должны быть обширные библиотеки языков, чтобы не надо было писать весь свой ДСЛ с нуля. Нужна тебе арифметика, или скажем выражения — возьми их из библиотеки.
Даже не языков, а отдельных конструкций. Т.е. да, обработка выражений желательно иметь уже готовый. Но с моей типизацией
VD>Собственно приглашаем всех заинтересованных лиц присоединиться к нашему проекту и приблизить то самое светлое будущее.
Ну, у меня и квалификации не хватает, и мир вне JVM не слишком интересен...
Здравствуйте, VladD2, Вы писали: VD> Что за язык? И в чем кроются проблемы?
PS А проблема банальна — жизнь это вам не сумму ряда посчитать, постоянно что-то меняется.
VD>инструменты для создания и интеграции ДСЛ-ев с ЯОН-ами
Не, разве что про первый пункт — о сложности и трудоемкости создания ДСЛя
В остальном же никаким компилятором не решаемые проблемы:
- Non-technical domain experts can find it hard to write or modify DSL programs by themselves
Пример из жизни: разработал RBP обработчик текстов, и посадил жену — филолога поработать. И потом еще неделю объяснял как эти правила правильно сочинять.
- Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
Пример из жизни: наш ДСЛь стремительно обрастает элементами присущими ЯОН. Есть опасения что в конце туннеля получится сильно переусложненный интерпретатор PS, что совершенно не нужно. Баланс дейссно трудно сохранить. Разработчику хочется впихнуть в детище побольше, пользователю хочется изучать поменьше.
VD>Дык в Википедию любой прохожий может что угодно написать
Угу. А потом это что угодное откатывается минимум — до компромиссного варианта, и максимум — до исходного.
Ну не нравится педия, всегда можно упомянуть к-л Мартина: ДСП — компьютерный ЯП с ограниченной выразительностю, ориентированный на определенную предметную область. Звучит аналогично.
Здравствуйте, mrTwister, Вы писали:
T>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .
Можно, например, придумать ДСЛ для разбора бинраных файлов. Скажем если у нас есть некий бинарный формат то для работы с ним можно придумать удобный ДСЛ. Надо только представить структуры представлюящие этот формат. Это и будет моделью формата. А далее сделать ДСЛ который позволит описать в какой последовательности нужно считывать эти структуры.
Делать же ДСЛ для банального чтения файла по байтам или считывания в виде текста особого смысл нет. Это прекрасно можно выразить одной-двумя функциями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Очень интересно! Почитаем! А то я понимаю, что прав, но наши формалисты загоняют в угол своим формальным подходом. Может тут будут более формальные определения .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это и есть ISO. Перестань позориться пытаясь из меня тут мальчика сделать. VD>Заранее отвечаю, что про CTE я знаю, если вдруг тебе и про это захочется спросить.
Причем они тут вообще?! Про PSM/RTJ знаешь? Я именно этих парней имел в виду. Так что кто из нас позорится — вопрос открытый. и баней не решаемый.
VD>ОК?
Okay, поживу без бана, зато при управляемой демократии.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Повторю еще раз: при изучении нового языка (даже DSL), крайне желательно опираться на знакомую грамматику. Поэтому удобнее всего делать новые языки или на основании основного языка проекта или на каком-нибудь общеупотребительном (типа XML).
Если язык новый, то грамматика у него будет тоже новая. Максимум что можно делать — это брать некоторые общие соглашения из основных (используемых в команде) языков. Например, комментарии, выдлеление блоков, описание параметров и функций (если они нужны для ДСЛ-я).
ХМЛ же тупо уродует язык делая его не столь выразительным как он мог бы быть. По сути ХМЛ-ДСЛ — это промежуточный вариант между полноценным ДСЛ-ем и АПИ к модели.
Это огромное заблуждение, что ХМЛ будет привычнее. Он только создаст шум. В ХМЛ-е будет описан другой язык которые точно так же придется изучать. То что он будет состоять из тегов, а не из идентификаторов только усложнит чтение, так как синтаксис тегов будет сильно зашуплять текст. Вот тебе простой пример ДСЛ-я для грамматики:
Не спорю, возможно можно придумать и менее страшный ХМЛ-вариант, но все равно шума будет слишком много.
ДФ>Мне на порядок проще, например, прочитать описание конфигурации системы на XML, нежели на каком-нибудь DSL с неизвестной мне грамматикой.
Это тоже не верно. Скажем файл конфигурации в стиле словоря ты прочтешь куда проще чем ХМЛ-ный:
X=42
Y="abc"
если этого формата хватит, то это будет куда лучшее решение для конфига, так как его будет проще читать.
Ну, а если конфигурировать нужно что-то сложное, например конечные автоматы, то получится уже программирование в ХМЛ. Что в этом хорошего?
Примером уродства которое может получиться в результате попытки использовать ХМЛ в качестве базового синтаксиса является XSLT. При вполне вменяемой модели и отличных фичах код превращается в полное месиво.
ДФ>Что, конечно, не отменяет ужасности всех DSL на основе XML
Я бы сказал, что ХМЛ делает ДСЛ-и ужасными. И смысл в ХМЛ-е есть только, если ДСЛ редко читается и пишется людьми, а часто машиной. Для машинной обработки ХМЛ хорош.
В прочем, есть и альтернативы. Например, тот же JSON. Мне кажется для человека он более читабелен, при той же универсальности формата.
ДФ>>>2. Делать DSL с хорошим описанием ошибок заметно сложнее, чем API с таким же описанием ошибок VD>>Согласен, но это вопрос технологий. N2
существенно упростит обработку ошибок.
ДФ>Я в мире Java, что мне с N2
Мы планируем, что N2 будет иметь бэкэнды для разных платформ. В том числе планируем и бэкэнд для Явы. После полного бутстрапа его можно будет и использовать на ява-машине. А там глядишь и поддержка для Эклипса с Идеей появится.
ДФ>Ну, вообще для той-же Java есть таки способы легко делать код в рантайме. Хотя, конечно, отлаживать такое еще хуже, чем DSL.
Именно. Чем раньше выявляется ошибка, тем проще ее устранить. Плюс компилированный до рантайма код еще и быстрее работает. Ведь не нужно время на генерацию и компиляцию.
VD>>Это форменное заблуждение. Изучать "каркас для создания DSL" не надо вовсе. Ты же не изучаешь средства использованные для создания компилятора С++ или C#? А с ДСЛ-ями почему должно быть по другому?
ДФ>А, вот тут все чуть-чуть по другому. Если я для описания какого-нибудь домена создаю DSL, то совершенно точно, что в будушем этот DSL придется дорабатывать (так как любая предметная область в проекте развивается).
Это если ты создаешь ДСЛ. А если ты его используешь, то выучить придется только сам ДСЛ. А так как правильные ДСЛ-и максимально простые, то учить их очень просто. Даже проще чем аналогичные АПИ.
ДФ>Т.е новому программисту придется знать, как можно расширить DSL — т.е. изучать-таки каркас.
Дык тогда это новый программист ДСЛ-ей, а не программист на ДСЛ-е. Это разные вещи. Программисту ДСЛ-ей придется изучать ДСЛ для построения ДСЛ-ей и предметную область для которой он создает ДСЛ. Но опять же ему не придется изучать то как написан ДСЛ для ДСЛ-ей. Это уже в компетенции того кто создавал этот ДСЛ.
Запутал?
ДФ>Все-таки, результатом работы нового программиста является не столько код на DSL (что скучно...), сколько сам по себе DSL
Точно так же создатель библиотеки будет обязан знать архитектуру и код этой библиотеки, а пользователю этой библиотеки придется знать только лишь ее АПИ.
Тут нет ничего нового.
ДФ>Ну, описать простым и естественным способом, например, упорядоченную последовательность необязаетельных токенов или выражений.
Тут никаких проблем нет. Описание упорядоченных последовательностей — это то что PEG делает отлично. А оператор "?" позволяет любое подправило сделать необязательным. БНФ тут отдыхает.
У ПЕГ-а только две проблемы:
1. Он не может качетвенно выразить приоритетов операторов и вообще не может их ассоциативность. Но для этого придумали силу связывания.
2. Оператор приоритетного выбора является не интиуитивным и может приводить к бессмысленным грамматикам (когда некоторые правила просто не используются никогда).
Обе проблемы исправлены в парсере Н2.
ДФ>В C# таких, насколько я знаю, просто нет, а вот в DSL для конечного пользователя — сплошь и рядом
Думаю не ошибусь, что в таком объемном и сложном языке как C# можно найти любые синтаксические выверы что только можно придумать. ДСЛ-и, как правило, (особенно пользовательские) в разы проще. Уж последовательности и необязательные подправила в шарпе сплошь и рядом.
Короче, лучше приведи гипотетическую грамматику.
VD>>Так же должны быть обширные библиотеки языков, чтобы не надо было писать весь свой ДСЛ с нуля. Нужна тебе арифметика, или скажем выражения — возьми их из библиотеки.
ДФ>Даже не языков, а отдельных конструкций. Т.е. да, обработка выражений желательно иметь уже готовый. Но с моей типизацией
Надо будет тебе свою типизацию, сделаешь. Но скорее всего ты предпочтешь полностью готовое решение. В конце концов их же можно будет сделать не одно.
У нас наборы таких конструкций предполагается помещать в синтаксические модули, а те, в свою очередь, в динамически подключаемые библиотеки или пакеты. Так что создать библиотеку не будет проблемы.
VD>>Собственно приглашаем всех заинтересованных лиц присоединиться к нашему проекту и приблизить то самое светлое будущее.
ДФ>Ну, у меня и квалификации не хватает, и мир вне JVM не слишком интересен...
Квалификация дело наживное. Был бы интерес. Что касается JVM, то мы планируем поддержку и JVM. По началу как бэкэнд для генерации кода, а потом и как хост-платформу. Кто хочет может принять участие в создание оного бэкэнда и в разработке модулей для Эклипса, например.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Повторю еще раз: при изучении нового языка (даже DSL), крайне желательно опираться на знакомую грамматику. Поэтому удобнее всего делать новые языки или на основании основного языка проекта или на каком-нибудь общеупотребительном (типа XML).
Тройной фейспалм.
ДФ>Я в мире Java, что мне с N2
Так N2 будет кроссплатформенным.
ДФ>Ну, вообще для той-же Java есть таки способы легко делать код в рантайме. Хотя, конечно, отлаживать такое еще хуже, чем DSL.
Для .НЕТ тоже. Но это всё равно ужОс-ужОс.
ДФ>Ну, описать простым и естественным способом, например, упорядоченную последовательность необязаетельных токенов или выражений. ДФ>В C# таких, насколько я знаю, просто нет, а вот в DSL для конечного пользователя — сплошь и рядом
Чего?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Wolverrum, Вы писали:
VD>> Что за язык? И в чем кроются проблемы? W>PS А проблема банальна — жизнь это вам не сумму ряда посчитать, постоянно что-то меняется.
Т.е. ушел от ответа?
W>В остальном же никаким компилятором не решаемые проблемы: W>
W>- Non-technical domain experts can find it hard to write or modify DSL programs by themselves
W>Пример из жизни: разработал RBP обработчик текстов, и посадил жену — филолога поработать. И потом еще неделю объяснял как эти правила правильно сочинять.
Это действительно проблема. Но лично мы и не особо рассчитываем, что на ДСЛ будут писать не программисты. Читать — возможно. Писать — только в очень редких случаях. Вот помогать в разрабтке ДСЛ-я специалисты могут. А далее ДСЛ уже будут использовать программисты. Это их работа.
W>
W>- Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
Это проблема дизайна. Она и без ДСЛ-ей встречается. Чуть менее чем любое долгоживущее приложение со временем скатывается к вселенскому всемогутеру.
Наличие же правильной идеологии поможет людям вместо одного всемогутера сделать 10-20 простеньких ДСЛ-ей.
Кроме того это так же может быть проблемой средств интеграции ДСЛ-ей. Если оных нехватает, то в ДСЛ и пытаются впихнуть ЯОН-ные фичи, чтобы склеивать ДСЛ и основную программу.
W>Пример из жизни: наш ДСЛь стремительно обрастает элементами присущими ЯОН. Есть опасения что в конце туннеля получится сильно переусложненный интерпретатор PS,
PS? ПостСкрипт???
W>что совершенно не нужно. Баланс дейссно трудно сохранить. Разработчику хочется впихнуть в детище побольше, пользователю хочется изучать поменьше.
Ну, дык подумайте почему хочется впихнуть лишнее. Может найдете лучшее решение. Разделите ДСЛ на два. Или придумаете как использовать ДСЛ из основного языка. А может вообще смените основной язык .
VD>>Дык в Википедию любой прохожий может что угодно написать W>Угу. А потом это что угодное откатывается минимум — до компромиссного варианта, и максимум — до исходного.
К сожалению откатывают тоже люди. По сему могут откатить и правильные мысли. Тут лучше ориентироваться на тех кто занимается проблемой профессионально или с научной точки зрения. По сему меня очень интересуют труды имеющиеся на эту тему. Уверен, что их много. Но найти их не просто.
W>Ну не нравится педия, всегда можно упомянуть к-л Мартина: ДСП — компьютерный ЯП с ограниченной выразительностю, ориентированный на определенную предметную область. Звучит аналогично.
Фаулера, то? Он как раз выступает на моей стороне. Просто очень деликатен и осторожен. Никогда не говорит никогда. Но он то никогда ВБА ДСЛ-ем не назовет. И он то как раз четко разделяет понятие ДСЛ и модель, а так же ЯОН и ДСЛ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mrTwister, Вы писали:
T>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
VD>Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .
Я имею ввиду DSL для замены файлового менеджера: скопировать, удалить, переместить и пр.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, batu, Вы писали:
B>>Будет ли правильно сказать что удачный DSL язык должен содержать удачно подобраные примитивы (с их семантическим содержанием) для построения модели соответсвующей предметной области?
VD>Не совсем. Модель предметной области — это тоже туманный термин, но в основном под ним подразумевается некая большая модель приложения. Такая модель может состоять из множества более мелких, конкретных моделей. Лучше называть модель лежащую в основе ДСЛ-я семантической моделью языка (ДСЛ-я).
VD>В такой постановке — да, хороший ДСЛ всегда имеет под собой хорошую семантическую модель.
VD>Грубо говоря модль хорошего ДСЛ-я должна быть моделью отдельной задачи (парсера, преобразователя ХМЛ в текст, описателя конечного автомата, и т.п.).
VD>Иногда такой моделью выступает АСТ. Но это как раз не очень здорово, так как АСТ обладает излишнем шумом и конкретикой не нужной для модели. А это как и в случае применения АПИ негативно сказывается на качестве реализации ДСЛ-я.
Меня это интересовало с точки зрения метаязыка, который сам являясь языком, может геренрировать другие языки не меняя синтаксис, но меняя семантику. Так называемая субъектно-ориентированная парадигма, или концептная..Т.е то, чем я занимаюсь
Концепт это тройка (L, S, P), где L -размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами и P –логическое представление (высказывание), используемое при логической интерпретации. Создание концепта заключается в определении его свойств и вложенной группы концептов, определяющих его семантику.
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).
Имхо, вы несколько зациклились на парсинге/семантическом анализе и может быть еще на генерации кода. Это не есть главная проблема при внедрении DSL-ей.
При реальном использовании DSL-ей главная проблема это debug самого DSL. Сгенерили мы код из DSL, а он работает не так. Что делать ? Дебажить генеренный кода и пытаться понять, что поправить в исходном тексте на DSL ? Здесь возникает море всяких технических заморочек. Их становится еще больше, когда позволяем мешать DSL c ЯОН.
Здравствуйте, Ziaw, Вы писали:
Z>Я тебе привел пример написанного хорошего интерфейса для RESTful маппинга. Если у тебя есть пример получше почему бы тебе его не привести.
Чем он хорош ? Для таких вещей нужна максмальна прозрачность, клик мышом и сразу видишь, что как делается а при желании там же можно и подебажить системный код.
Ты думаешь, если апи у микрософта кривой, то обложив его картинками, он станет лучше ? Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся.
Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
Z>Ок, давай на примерах. Есть задача: ACL. Нужно около сотни правил вида:
Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
...
Z>Давай, ты набросаешь удобный интерфейс для записи правил, и проверок, а я DSL на Nemerle. Результаты выложим здесь и сравним.
см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ.
Здравствуйте, VladD2, Вы писали:
VD>Имеет. Хороший ДСЛ не должен быть полон по тьюрингу. Наличие оной уже указывает на протекание абстракции. Все случаи полноты по тьюрингу в ДСЛ-ях являются скорее побочным эффектом получающимся от стремления авторов ДСЛ-ей к излишней универсализации ДСЛ-ей.
"протекание абстракции" это просто красивые слова. Абстракции которые требуются в конкретной задаче спокойно могут потребовать полноту по тьюрингу или черчу.
Здравствуйте, VladD2, Вы писали:
I>>Я вообще то сказал, что ДСЛ и модель это совершенно разные вещи. раз ты считаешь, что это заблуждение, то с тобой не о чем говорить.
VD>Может я тебя не так понял, то если ты со мной согласен, то зачем влезал?
Здравствуйте, _Obelisk_, Вы писали:
_O_>Имхо, вы несколько зациклились на парсинге/семантическом анализе и может быть еще на генерации кода. Это не есть главная проблема при внедрении DSL-ей. _O_>При реальном использовании DSL-ей главная проблема это debug самого DSL. Сгенерили мы код из DSL, а он работает не так. Что делать ? Дебажить генеренный кода и пытаться понять, что поправить в исходном тексте на DSL ? Здесь возникает море всяких технических заморочек. Их становится еще больше, когда позволяем мешать DSL c ЯОН.
ДСЛ не ЯОН. По тому отлаживать его обычно сильно проще. Плюс можно натягивать отладочную информацию на ДСЛ. Думаю, что мы предоставим средства и для этого. Например, при генерации кода можно позволить задавать привязку к синтаксическим конструкциям ДСЛ-я следующим образом:
CallRule is Rule = RuleName : QualifiedIdentifier ("@"s Identifier)?
{
...
transform to N2L
{
set_debug_info (RuleName.Location)
EmitCallRule(RuleName.Text); // генерация кода для вызова правила
}
}
Это приведет к тому, что отладчик будет "прыгать" по обращениям к подправилам и на них можно будет ставить точки останова.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Чем он хорош ? Для таких вещей нужна максмальна прозрачность, клик мышом и сразу видишь, что как делается а при желании там же можно и подебажить системный код. I>Ты думаешь, если апи у микрософта кривой, то обложив его картинками, он станет лучше ? Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся. I>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
С ДСЛ-ем тебе просто должно быть выдано корректное (объясняющее причину ошибки) сообщение или хотя бы исключение.
Если это не так, то — это ошибка в ДСЛ-е. Значит задача сводится к отладке ДСЛ-я. Тут как бы те же методы отладки, что и с библиотеками.
I>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
Он такой же немерлист как ты. Год назад так же возражал на форумах. Потом надоело и он попробовал.
Насколько я знаю он сейчас во всю на Руби работает. Да и Шарп вроде как во всю использует.
I>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ.
I>http://rsdn.ru/forum/philosophy/4701734.1.aspx
Здравствуйте, Wolverrum, Вы писали:
W>Я бы придерживался все же конкретных дефиниций (хотя бы на основе той же ру.кипедии), а не всевозможных IMHO. типа Владовских либо твоих.
Где ты в википедии видел другие определения? Ты их просто по своему интерпретируешь.
Да и смотреть на русскую википедию я бы не стал. В английской обычно все более точно описывается. Уж больно слабый контроль за русской ее частью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
VD>С ДСЛ-ем тебе просто должно быть выдано корректное (объясняющее причину ошибки) сообщение или хотя бы исключение.
Ничего он не выдаст, поскольку проблема в асп и иис, а исключений в том случае про который я говорю, нет и не будет. Потому ДСЛ только затруднит отладку.
I>>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ. I>>http://rsdn.ru/forum/philosophy/4701734.1.aspx
Здравствуйте, VladD2, Вы писали:
VD>ДСЛ не ЯОН. По тому отлаживать его обычно сильно проще. Плюс можно натягивать отладочную информацию на ДСЛ. Думаю, что мы предоставим средства и для этого. Например, при генерации кода можно позволить задавать привязку к синтаксическим конструкциям ДСЛ-я следующим образом:
ЯОН не ЯОН, но если ДСЛ используется для императивных действий (а не как описание модели данных), то без дебага не обойтись. Отладочная информация — это один вариант. Но необходима формализация и обобщение такой инфы, чтоб юзер мог расширять. Минус отладочной информации — мы получаем два вида генеренного кода: с отладочной инфой и без. Иногда надо дебажить код без отладочной инфы.
К сожаленью, в реальности будет смешение ДСЛ и ЯОН а потому надо уметь дежить код, в котором часть сгенерена а часть рукописна.
VD>Это приведет к тому, что отладчик будет "прыгать" по обращениям к подправилам и на них можно будет ставить точки останова.
Это только начало. Для дебаггера необходимы еще
— стэки вызовов
— variables view (с возможностью просмотра и модификации значений переменных, причем значения должны показываться в синтаксисе DSL)
Плюс желательно watch view где юзер может ввести свою конструкцию, которая будет вычислияться в текущем стэк фрейме. Помимо этого нужны доп view для всякой DSL-specific информации.
Я обратил внимание на этот аспект DSL-ей, т.к. мы связаны с большим числом солидных компаний (телеком, военные, авиа) которые в том или ином виде на практике используют (или пытаются, бедняги) свои специализированные языки, генерацию кода, формальные языки спецификаций, DSL-и и т.п. Собственно парсинг/semantic analysis как проблема никогда не стоит. Превейшей задачей является интеграция с унаследованным кодом (т.е. с ЯОН), сторонними библиотеками и т.п. Далее идет проблема дебага генеренного кода а так же интеграция генерации кода по DSL в общуюю систему билда. Плюс поддержка со стороны CM-систем (если над проектом работают много людей, нам надо уметь мержить код и textual merge не всегда хорош)
Я правильно понял вашу идею?
1)"классический" вид абстрактных слоёв.
2)ваша идея.
model — прослойка над выполняющей машиной, например ООП.
Спасибо.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Ikemefula, Вы писали:
I>Ничего он не выдаст, поскольку проблема в асп и иис, а исключений в том случае про который я говорю, нет и не будет. Потому ДСЛ только затруднит отладку.
Да без разница где проблема. Обрабатывай ошибки показывай клиенту.
I>Вот для такого кода и интересен ДСЛ. То есть описание бизнес-логики в виде ДСЛ.
Еще раз. Ты сначала попробуй пойми что этот код делает. Все кто его смотрел, кроме АВК, так и не смог точно понять что он делает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже). VD> [...]
У меня тоже хватило духу почитать эту тему. Откровенно говоря, убедился, что "тема не раскрыта". Я так и не понял, в чём глобально ошибаются разработчики языка Go, создавая новый язык программирования общего назначения, причём с расчётом на около системную разработку (именно с этого и начался весь сыр-бор). В той теме правильно заметили, что там сплошной конфликт опыта и эмоций, мало конструктива, ну и традиционное для РСДН кидание песком друг в друга с целью решения вопросов по поводу своего ЧСВ. Более того, как-то сомнительно то, что Вольфхаунд, как человек далеко не глупый, с квалификацией, не вызывающей сомнений, имеет на самом деле такое категоричное мнение, что ЯОН не имеют смысла. Очевидна несколько иная цель в этом форуме — это подпитка себя какой-то энергией, а не решение этого философского вопроса. И то, что его хватает чуть ли не на каждый ответ в топиках той темы, это подтверждает (лично я завидую такой энергетике). А также заметно то, что Вольфхаунд лишний раз старается обратить внимание на свою проделанную работу, которая, бесспорно, вызывает уважение и чувство признательности, особенно со стороны тех, кто использует Немерле. Но в той теме правильно указали, что со 100 людей, кто открыл ссылку, 99 тут же закрывают страницу, увидев там непонятные для себя крокозяблы.
И в целом, задуманная тема форума не имеет запланированного эффекта, на мой взгляд.
Я предлагаю тебе, Влад, возможно совместно с Вольфхаунд, как-то "на пальцах" раскрыть свои позиции по поводу DSL-строения, относительно своего проекта N2 (я так понимаю, что теперь лучше писать именно N2, а не Н2). Правда непонятно, как это сделать, если у вас двоих, как ярких представителей лагеря N, нет однозначного мнения по поводу этих всяких DSL. Когда есть разброс и шатание внутри проекта, то со стороны это выглядит даже не как некий исследовательский проект (в проекте N есть немало неоднозначностей в ключевых целях, это подтверждают ряд профильных тем в форуме Немерле).
А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
Прежде всего, нужно обратить внимание, что нельзя рассматривать какой-то сферический в вакууме DSL, без конкретных целей, что пытались делать многие в той теме, ругая тот же SQL, пытаясь его натянуть как абстрактную сущность чуть ли не для всех задач, для всех "бизнес-систем" и т.п. Например, можно поставить условную задачу для вымышленного SQL-сервера реляционной СУБД:
— скрыть работу внутренних механизмов для манипулирования данными внутри БД, которые обеспечивают сохранность, согласованность в рамках одновременной работы многих пользователей и пр. Одним словом, предоставить пользователям СУБД возможность низкоуровневого доступа к данным (какой-то некий ISAM) для реализации высокоэффективных своих алгоритмов крайне затруднительно или невозможно. Т.е. необходимо дать понять, что здесь востребована какая-то декларативность, невозможно явное детальное алгоритмическое указание действий. Короче говоря, декларативный DSL здесь уместен, даже необходим — т.е. нужно показать, что DSL-строение происходит не "от фонаря", нужно какое-то обоснование в его потребности;
— нужно конкретно сказать, что проектируемый язык должен быть простым, даже для кухарок — это также необходимая конкретная цель для DSL;
— нужен жёсткий контроль типов, необходимо контролировать набор допустимых операций в нужных местах, причём на этапе компиляции SQL-запросов (в большинстве случаев), перед тем, как что-то сделать;
— необходим жёсткий контроль за целостностью и правильностью объектов в БД, например, нельзя удалить столбец в таблице, если он где-то используется, в каких-то View или хранимых процедурах, или необходимо зафиксировать тот факт, что после удаления столбца все зависимые объекты нельзя больше использовать;
— и пр. В принципе, и этого хватит.
Т.е. нужно указать, что DSL должен позволять неявно для пользователя решать широкий круг технический задач, о которых он (пользователь) возможно и не догадывается, всю заботу на себя берёт система СУБД и вынуждена максимально контролировать пользователей-программистов.
Далее на конкретных примерчиках нужно показать, что вкладывается в понятие модели языка, его семантики и пр. Наконец конкретно показать, что подразумевается под DSL, внешний DSL, внутренний DSL, fluent DSL, DSF (domain specific framework) и т.д., а также, что есть какая-то "степень DSL-ности" в языке, или что здесь лишнее и какой есть бред в этих терминах (хотя в личной практике непонимание того, DSL это или кастрированный ЯОН, как-то не мешает для практичного решения задач). Например, можно конкретно показать, что DSL-лем являются выражения для создания/модификации объектов СУБД (DDL, т.е. "create table", "alter index" и т.д.) и выражения для выборки/модификации данных (DML: select ..., insert ...). А вот процедурные расширения вида PL/SQL, TSQL — языки общего назначения, хоть и ограниченные, специализированные, и пользуются этим DSL-SQL. Если ввести какие-нибудь бинарные вставки в SQL-язык вида <<...>> (где внутри, скажем, будет регулярное выражение), и ввести ряд операций над ними — это будет примером встроенного DSL. Если для процедурного расширения добавить функции/процедуры для работы c HTML (или ввести всякие операторы и т.д.), то HTML будет внешним DSL (например, можем реализовать встроенный веб-сервер). Также в рамках процедурного расширения можно показать какой-то способ для создания fluent DSL, если есть какие-то гибкие способы для задания типов, намёки на ООП и т.п.
Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так:
define MyWhere as AnyCol > 1000 and SomeCol is not null;
-- или с параметрами:
define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
define MySelect (AnyTable) as
select Col1, Col2, ... from AnyTable a
where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
-- и использовать как-то так:select * from MySelect(OperTable)
Здесь есть ключевые моменты:
— только в последнем выражении в этом примере система сможет проконтролировать типы, зависимость объектов и допустимость операций и т.д. Т.е. будет ли такой некий generic-SQL соответствовать установленным требованиям и техническим возможностям в СУБД, когда каждый шаг в системе должен быть под прицелом?
— сможет ли с generic-SQL работать каждая кухарка?
— является ли такой generic-SQL каким-то DSL, или это уже специализированный ЯОН, хоть и очень ограниченный и предметно-ориентированный? Ведь расширяется поле его (т.е. SQL) декларативности, повышается уровень абстрактности, т.е. уже есть какая-то возможность для создания domain specific framework, или для уже своего DSL в DSL-е. Т.е. мы изобрели некий аналог функционального языка, который как бы по своей природе является универсальным.
В общем, лучше, когда можно философствовать на конкретных "пальцах".
Все эти изложения необходимо разбавить с конкретными маленькими примерчиками возможной реализации такой СУБД на Немерле. Речь не идёт о подробном описании (это невозможно и только всех отпугнёт подальше). Достаточно условно показать (не полностью) по каким принципам можно реализовать разбор хотя бы одного простейшего оператора вида:
select Col1, Col2 from MyTable where Col3 > 1000 and Col4 like "..."
Нужно в двух словах сказать о том, что используется своя грамматика, как-то похожая на PEG, с парочкой отличительных свойств. Вот таким-то образом задаются декларации, при этом обратить внимание на то, что используется принципы раздельных описаний с возможностью переопределения (т.е. синтаксические модули, с похожими принципами из ООП). Т.е. сказать, что мы можем, например, определить отдельно правила для разбора чисел, строк и т.д., и подключать эти правила для поддержки синтаксисов разных языков. Указать пару слов о принципах по поводу типизации. Намекнуть, как можно реализовать динамическую типизацию, или сказать, что динамическая типизация — это ошибка природы, её нужно однозначно вырубать топором, и начинать нужно с DSL, пока не поздно.
Необходимо показать на маленьком псевдо-коде, как, например, можно внутри своего приложения взять строку с SQL-кодом, что-то вызвать для разбора и как-то воспользоваться его результатом, например, что-то дёрнуть, чтобы сгенерировать какой-то байт-код.
Как-то так. Т.е. нужно показать, как потенциальные разработчики некоего cервера СУБД смогут воспользоваться проектом N2, даже те, кто создаёт платформу на С/С++, частенько не могут задействовать универсальные генераторы парсеров, кому нужна динамическая компиляция во время работы приложения, компактное AST или, вообще, его отсутствие, скорость и эффективность и т.д.
При этом нужно намекнуть, какие планируются вкусняшки в плане IDE. Что-то уже рассматривалось в темах вокруг N2, например, идея об окошках, когда можно править правила для разбора, в другом окне рядом вводить код для разбора, а в ещё в одном окне сразу видеть результат этого разбора. Или какие будут возможности для дебага DSL, ну, например:
model MyModel {
anyField someType "Описание этого поля",
someField anyObj.prop + 125 "А тут вычисления и вывод типа",
...
}
view MyView(MyModel) {
<p>Это форма для ввода</p>
<input MyModel.anyfield />
...
}
Здесь было бы неплохо, если бы отладчик заходил во внутрь каждого декларативного описания, показывал последовательно каждое вычисление внутри, вместо просто того, чтобы проглотить, например, всю декларацию "model ..." как один шаг отладки. Это помогает также лучше понять, как работает конкретный DSL (проверено на личной практике).
Когда будет представлена хоть какая-нибудь конкретика, то появится пища для конструктивных обсуждений. Многие молча смогут задуматься над тем, а не воспользоваться ли DSL (даже для решения какой-то одноразовой задачи, если смогут ощутить, что в случае чего выкинуть этот DSL на помойку не жалко), вместо того, чтобы поливать другу друга брызгами от воплей. И может быть станет понятно, что разработчики языка Go мучаются напрасно, как и их коллеги из нового языка Rust, также можно будет посочувствовать ребятам из jetbrains, которые страдают над своим новым Kotlin, станет понятно, насколько порочны мысли про натягивание Scala, Clojure на платформу Net и т.д. и т.п.
При этом такое простое изложение материала окажется более продуктивным и ненавязчивым, чем прямой крик: "приходите к нам, в проект N2, всем будет хорошо". А также результаты этих трудов (которые будут не больше, чем сотни бессмысленных ответов в топиках мега-ср..ча) не выбросятся на помойку — это неплохой скелет для статейки про N2, которую можно разместить отдельно, включая и вики в проекте.
Как-то так. Прошу сильно не судить.
P.S. Прав был товарищ Толстой: кому нечего сказать — говорит много. Это не адресовано никому конкретно. Это призыв к тому, чтобы не разводить подобной мега-бойни, это отталкивает людей от ресурса РСДН как потенциального источника реальных знаний.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, VladD2, Вы писали:
T>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
Любой shell на Linux/Unix — это DSL для работы с файлами, причем проверенный временем.
Здравствуйте, VladD2, Вы писали:
VD>В прочем, не странно для автора не расширяемого языка прошлого поколения. Если сейчас Вирта послушать, то он тоже еще тот ретроград стал.
Почему прошлого? Это вполня нормальный язык, некий pof для ООП языков, некоторые идеи, например, программирование по контракту пошли от него.
кстати вот. Вполне себе развивается.
Что для Вас расширяемость языка? C#, сдается мне, тоже не очень расширяем, если вы не из команды разработчиков компилятора.
Здравствуйте, Sharov, Вы писали:
S>Почему прошлого?
А что в нем современного то?
S>Это вполня нормальный язык, некий pof для ООП языков, некоторые идеи, например, программирование по контракту пошли от него.
Дык в нем дизайн бай контрак и был единственной уникальной фичей. Но этого вообще-то мало для нового языка.
Это дело уже даже из шарпа можно использовать. А в расширяемые языки оно просто вставляется на раз два три.
S>кстати вот. Вполне себе развивается.
Ну, ни хай себе развивается. Только на мой взгляд куда-то не туда. От того и идеи у автора странные.
S>Что для Вас расширяемость языка?
Для меня — это возможность не ждать пока автор языка соизволит проявить милость.
S>C#, сдается мне, тоже не очень расширяем, если вы не из команды разработчиков компилятора.
Ну, да. И это отнюдь не плюс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PSV100, Вы писали:
PSV>А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
Для этой цели уже есть готовое DSL решение, LINQ называется.
PSV>Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так: PSV>
PSV>define MyWhere as AnyCol > 1000 and SomeCol is not null;
PSV>-- или с параметрами:
PSV>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
PSV>define MySelect (AnyTable) as
PSV> select Col1, Col2, ... from AnyTable a
PSV> where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
PSV>-- и использовать как-то так:
PSV>select * from MySelect(OperTable)
PSV>
Тоже пробовать не нужно. В том же MSSQL есть UDF. Не очень удобно технологически, но в разрезе языка это не имеет значения.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, PSV100, Вы писали:
PSV>>А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
AVK>Для этой цели уже есть готовое DSL решение, LINQ называется.
PSV>>Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так: PSV>>
PSV>>define MyWhere as AnyCol > 1000 and SomeCol is not null;
PSV>>-- или с параметрами:
PSV>>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
PSV>>define MySelect (AnyTable) as
PSV>> select Col1, Col2, ... from AnyTable a
PSV>> where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
PSV>>-- и использовать как-то так:
PSV>>select * from MySelect(OperTable)
PSV>>
AVK>Тоже пробовать не нужно. В том же MSSQL есть UDF. Не очень удобно технологически, но в разрезе языка это не имеет значения.
А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:
[ (the dept, sum salary)
| (name, dept, salary) <- employees
, group by dept
, order by Down (sum salary)
, order using take 5 ]
что соответствует такому SQL:
SELECT dept, SUM(salary)
FROM employees
GROUP BY dept
ORDER BY SUM(salary) DESCENDING
LIMIT 5
И таких DSL куча для разных языков. Вот только такой LINQ в SQL не впихнёшь. Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах. И лучше сразу оставить какие-то споры по поводу LINQ, SQL и пр. в соответствующей теме этого форума, так такого всякого уже выше крыши.
Здравствуйте, Ikemefula, Вы писали:
I>Ты думаешь, если апи у микрософта кривой, то обложив его картинками, он станет лучше ?
Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше. Все что я видел из не Microsoft, это рельсы, так там язык заточенный под eDSL и описание роутинга выглядит примерно так как я показал.
I>Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся. I>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
Воспроизведу ситуацию и продебажу
I>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
Я так понимаю у тебя, без перехода на личности, дискуссию вести не получается. Я пытаюсь показать, что есть задачи, где DSL удобнее библиотеки с API ...
I>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ.
... А ты — что есть задачи, для которых польза DSL не так очевидна. Можешь не стараться, никто не ставит под сомнение этот тезис.
Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык. Совершение бизнес операций путем вызова бизнес-методов разумное решение. Переписав на немерле мы и так получим более читаемый код. Некоторые операции можно было бы подсахарить. Типа
// не должно быть более поздних операцийif (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
.Any(op => op.Order > relatedOperation.Order))
throw new BusinessException("После внутреннего перемещения не должно быть операций.");
может превратиться во что-то типа:
Should not any accounting kind operation of inv with operation.Order > relatedOperation.Order;
А может и не превратиться. По куску кода такие выводы не делаются
Здравствуйте, VladD2, Вы писали: VD>Мелкие модели лежащие под ДСЛ-ем и составляют (в купе с моделями для которых нет ДСЛ-ей) модель приложения. VD>А ЯОН склеивает их вместе создавая приложение.
Как-то так?
Будет возможно реализовать многоуровневые DSL? Что-то вроде такого:
------------------------- VD>...модель приложения.
Под моделью я подразумеваю "модель среды"(не IDE) она же семантика(возможно), а не приложения, то есть всё то что можно использовать для создания программы, посредством языка. Например в Java это объекты, классы, методы etc. в ассемблере это регистры, память, команды, процедур etc.
Когда вы пишете программу вы строите её модель из элементов модели среды:
Как-то так.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже). VD>Проблема начинается с невнятности терминологии.
ИМХО пытатря конкретизировать понятие "DSL", это тоже что пытаться конкретизировать например понятие "маленький" или "яркий".
Я бы сказал: "предметными языками программирования" принято называть ЯП разработанные с прицелом на программирование в рамках некоторой предметной области, а ЯОН называют соответственно ЯП разрабатываемые без определённой предметной нацеленности:
-Что на нём можно будет писать?
-Нуу.. разное..
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Как-то так? AC>
Что-то вроде. Только DSLModel скорее нужно называть SymantecModel. И GPLModel тоже. Просто DSL не обазателен. С мелкими моделями можно работать и без них.
Кроме того все эти мелкие модели можно объвести одним большим квадратом и написать на нем ApplicationModel.
AC>Будет возможно реализовать многоуровневые DSL? Что-то вроде такого: AC>
Да, ДСЛ-и могут использовать другие ДСЛ-и для своей реализации. Только это уже детали реализации. ДСЛ и лежащая под ним модель — это абстракция. Если они есть, то детали того как они реализованы уже не важны для общего восприятия приложения.
VD>>...модель приложения. AC>Под моделью я подразумеваю "модель среды"(не IDE)
Приложение он ведь решает некоторую проблему пользователя. Скажем текстовый редактор позволяет создать текстовый документ, а бухгалтерия получить данные по финансам фирмы. Грубо говоря у каждого приложения есть своя задача, а у задачи есть своя большая модель. Модель приложения — это как бы модель предметной области. По сути это составная вещь, и описать ее можно только в виде абстрактных диаграмм. Но все же она есть и не надо забывать об этом.
AC>она же семантика(возможно), а не приложения, то есть всё то что можно использовать для создания программы, посредством языка. Например в Java это объекты, классы, методы etc. в ассемблере это регистры, память, команды, процедур etc.
Классы, другие структуры данных, процедуры, и т.п. — это средства универсального языка (ЯОН). Они используются для реализации семантических моделей. Модель же приложения это как бы совокупность семантических моделей отдельных задач. Скажем в бухгалтерии это могут быть модели отчетов, модель плана счетов, и т.п.
AC>Когда вы пишете программу вы строите её модель из элементов модели среды: AC> AC>Как-то так.
Вот тут уже не совсем так. На самом деле мы используем ЯОН и ДСЛ-и для описания и работы с моделями предметной области. Мы моделируем эту область разными способами. ДСЛ-и это возможность работать с этими моделями в терминах этой предметной области. Только и всего. Если не применять ДСЛ-и то мы будем вынуждены возиться с классами и процедурами которые в свою очередь реализуют модель.
Тут можно провести следующую аналогию. Представь себе, что ты пишешь простую программу которая читаешь данные из файла, производит не сложные их изменения и записывает их в другой файл. Не сложная задача, правда? А теперь представь, что вместо того чтобы программировать, скажем, на С ты вынужден программировать на AST. То есть вместо:
Здравствуйте, PSV100, Вы писали:
PSV>А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:
Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.
PSV>А вот пример генератора SQL на Кложуре:
Ну и? Ты сказать то чего хотел?
PSV>И таких DSL куча для разных языков. Вот только такой LINQ в SQL не впихнёшь.
При чем тут куча языков, если речь о LINQ? И зачем его впихивать?
На LINQ твой запрос будет выглядеть так:
var q = (from e in employees
group e by e.dept into g
let sum = g.Sum()
order by sum descending
select new {g.Key.dept, sum})
.Take(5);
Единственная проблема, которую я здесь вижу — синтаксис query comprehension не поддерживает take/skip. Но с теоретической точки зрения это не интересно, потому что проблема исключительно в том, что недореализовали и ни в чем больше.
PSV> Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах.
А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.
Майкрософт прикармливает исследования в Хаскеле, в частности технология LINQ была обкатана в экспериментальном расширении этого языка, возможно не в том именно, примерчик от которого я указал. Я давненько изучал соответствующие материалы по этому вопросу, не исключаю, что я мог и что-то напутать. Так что вполне вероятно, что моё "изречение" было перебором, всё может быть.
PSV>>А вот пример генератора SQL на Кложуре: AVK>Ну и? Ты сказать то чего хотел?
То, что кроме LINQ есть множество аналогичных DSL, для разных языков, и не только для генерации SQL (манипулирование данными внутри приложения, в коллекциях, например).
PSV>> Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах. AVK>А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.
Я, собственно, ничего обсуждать не хочу. И в моём первом сообщении речь была совсем не о DSL в рамках клиентского приложения для работы с SQL. Я предложил Владу, как автору этой темы, и другим представителям лагеря Немерле сделать небольшой и простой учебный материал, в рамках форума, где бы на небольшой условной псевдо-задаче раскрыть свои теоретические взгляды по поводу DSL-строения, включая и определения ряда терминов, подкрепленными наглядными примерами, и заодно всем показать потенциал N2 для реализации DSL. В качестве постановочной задачи я предложил взять условную упрощённую реализацию SQL-сервера реляционной СУБД, т.к. эта сфера знакома всем. Ещё раз подчеркну, ни о каком DSL в рамках клиентского кода внутри своего приложения речи не было. А на примере этого кода:
PSV>
PSV>define MyWhere as AnyCol > 1000 and SomeCol is not null;
PSV>-- или с параметрами:
PSV>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
PSV>define MySelect (AnyTable) as
PSV> select Col1, Col2, ... from AnyTable a
PSV> where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
PSV>-- и использовать как-то так:
PSV>select * from MySelect(OperTable)
PSV>
я лишь хотел сказать о том, что в рамках учебного изложения на подобном коде можно указать на то:
— что не всегда в DSL реализуется язык так, как хотелось бы программистам, т.к. через DSL часто решаются многие вопросы, технические и политические, не только прихоти профи-программистов. Т.е. именно такой SQL внутри сервера СУБД может, теоретически, не удовлетворять условиям поставленной задачи;
— что такой SQL является весьма спорным в рамках термина DSL: является ли такой вариант языка DSL-лем или это уже какой-то универсальный, хоть и ограниченный, язык, который уже сам позволяет создавать DSL? (Я бы сам хотел узнать, что об этом думают те, кто раскрывает тему DSL-строения)
Ни о LINQ и его аналогах, ни о конкретном SQL-сервере, включая и MSSQL, речи нет.
Здравствуйте, PSV100, Вы писали:
AVK>>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.
PSV>Майкрософт прикармливает исследования в Хаскеле
О да, это все меняет
PSV>, в частности технология LINQ была обкатана в экспериментальном расширении этого языка
Для того Хаскель и придумали. Но обкатывали не на нем, а на C omega.
PSV>То, что кроме LINQ есть множество аналогичных DSL
И?
AVK>>А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.
PSV>Я, собственно, ничего обсуждать не хочу.
PSV> И в моём первом сообщении речь была совсем не о DSL в рамках клиентского приложения для работы с SQL.
А LINQ никак не обязывает использовать SQL. Даже в самом фреймворке есть провайдеры для IEnumerable, XML, DataSet.
PSV>и заодно всем показать потенциал N2 для реализации DSL.
В Н просто LINQ реализован. Так что выглядеть это будет бессмысленным извращением.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали: VD>Что-то вроде.
Теперь понял.
ИМХО, проблемой будет "скрутить" в одно приложение код, нагенерированный каждым из DSL(или даже точнее, сделать так чтобы все DSL корректно собрались в одно приложение и не конфликтовали друг с другом), это будет основным источником "жуков". Особенно если предполагается доверить разработку новых языков пользователям и кросплатформеность. А увеличение уровней на которых будет происходить такая "скрутка", умножит эти проблемы на число уровней(маленькая ошибка на верхних уровнях, приводит большим проблемам на нижних).
Но с другой стороны, если "фронтэнд"(то с чем работает пользователь) каждого из DSL будет хорошо спроектирован, то есть не будет давать пользователю делать того чего нельзя, а "бэкэнд"(генерируемый код) будет хорошо протестирован на совместимость с другими DSL, это будет работать.
VD>>>...модель приложения. AC>>Под моделью я подразумеваю "модель среды"(не IDE) VD>Приложение он ведь решает некоторую проблему пользователя...
Вы ведь пилите ЯП(инструмент для создания приложений), а не приложение. VD>Вот тут уже не совсем так. На самом деле мы используем ЯОН и ДСЛ-и для описания и работы с моделями предметной области. Мы моделируем эту область разными способами. ДСЛ-и это возможность работать с этими моделями в терминах этой предметной области. Только и всего. Если не применять ДСЛ-и то мы будем вынуждены возиться с классами и процедурами которые в свою очередь реализуют модель. VD>Тут можно провести следующую аналогию. Представь себе, что ты пишешь простую программу которая читаешь данные из файла, производит не сложные их изменения и записывает их в другой файл. Не сложная задача, правда?
Я изложу подробней как я это понимаю, поправь если я где не прав.
Мы можем написать программу, решающую конкретную проблему в конкретной предметной области, в лоб. Просто взять и написать, на каком нибудь ЯОН. Но если таких программ предполагается много, то прежде стоит подготовить инструмент, который облегчит написание программ для этой конкретной предметной области.
Например нам нужен инструмент для написания программ работающих с текст файлами, конкретно и их заглавиями. Это может быть и библиотека функций или макросов, класс etc. но в данном случае мы выберем предметный язык. У этого инструмента есть собственная модель*, являющаяся "отражением" предметной области.
Наш язык для работы с файлами можно представить так:
В зелёном прямоугольнике форматы языковых конструкций, в коричневом связанные с ними элементы модели языка(отражения элементов предметной области). Реализовано это может быть разными способами, например если бы мы выбрали библиотеку функций то в зелёном были бы форматы их вызовов, а в коричневом собственно библиотека с функциями и структурами. Если DSL реализован при помощи макросов, то в коричневом они. Если для DSL используется транслятор, то до трансляции элементы в коричневом треугольнике будет существовать только в документации к DSL(или в голове его разработчика), однако транслятор будет "знать" как построить каждый из них.
Когда инструмент готов, можно приступать к написанию собственно программы. Для чего мы складываем элементы модели(посредством ЯП), предоставляемые инструментом, таким образом чтобы конструкция из них решала конкретную проблему(как ты не знаю, я делаю именно так). Эта конструкция и будет моделью приложения(отражением конкретной проблемы,(!)а не всей предметной области).
Например у нас есть конкретная проблема, нужно взять заглавие одного текст файла изменить его и сохранить в отдельный файл, для чего мы пишем приложение:
Модель этого приложения можно представить так:
"В компьютере" оно конечно не будет иметь точно такой вид, но структурой будет похоже.
Т.е. "модель приложения" есть набор связанных между собой элементов модели ЯП, использованного для его написания, построенный по исходному тексту этого приложения.
*"модель" — следует понимать в зависимости от контекста как "программная модель реального объекта"(существует в компьютере) или как "мысленная модель реального объекта"(в воображении).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AndrewVK, Вы писали:
PSV>>и заодно всем показать потенциал N2 для реализации DSL.
AVK>В Н просто LINQ реализован. Так что выглядеть это будет бессмысленным извращением.
Я Немерле не использую и, фактически, его не знаю, да и не знаток я и платформы Net, но очень рад, что в Немерле, как я понимаю, появилась прозрачная поддержка LINQ, как в С#, вместо макросов linq <# ... #>, которые были в N1. И очень жаль, что теперь наличие LINQ делает процесс создания DSL в Немерле бессмысленным извращением, даже если (возможно) речь идёт об учебном примере создания псевдо-сервера СУБД.
Но, откровенно говоря, я не понимаю, каким боком LINQ причастен к тем тезисам, которые были в моём первом сообщении в этой теме форума. Я лишь могу предположить:
— наличие LINQ в языке избавляет от всех потребностей в любом другом DSL для любой задачи. Поэтому создание своего DSL на Немерле теперь является бессмысленным извращением. Нет никаких потребностей в другом языке, кроме LINQ, включая и сервер СУБД.
Как-то всё это противоречит тому, о чём здесь говорят Влад и Вольфхаунд, как минимум. Странно, пока лучше опустить этот момент, я не специалист по Немерле, сам хочу увидеть какую-то конкретику.
— В современном сервере СУБД не должно быть неудобного и ограниченного языка SQL: там однозначно должен быть язык для запросов похожий на LINQ.
В жизни ещё не доводилось разрабатывать сервера СУБД, вполне возможно, что так будет лучше, хоть и не стандартно, я не спец.
— Использование LINQ в Немерле (возможно, и во всём Net) теперь является обязательным явлением, и даже страшно предположить, теперь является чуть ли не единственным способом для манипулирования данными, не исключаю, что многие методы/алгоритмы, например, в тех же коллекциях, объявлены как "deprecated". Поэтому LINQ это единственный очевидный способ реализации обработки данных в рамках сервера СУБД.
Здесь я тоже не спец по платформе Net.
— LINQ является лишь одним из способов для работы с реляционными и иерархическими данными, но для реализации учебного сервера СУБД всё-равно обязательно им (LINQ) нужно воспользоваться, так как этот DSL является очень яркой и удачной технологией. Но по непонятным причинам (возможно техническим) делает этот процесс бессмысленным извращением.
Тоже странно, хотя вполне вероятно, что некая неэффективность LINQ делает такую обработку данных бессмысленным извращением.
— В Немерле жёстко принято все операции с данными делать через LINQ: писать запросы внутри программы, компилировать/собирать сборку/проект и запускать на выполнение. Это делает инструмент Heмерле бессмысленным извращением для создания сервера СУБД.
В этом логика есть.
Одним словом, не понимаю, в чём заключается всемогущая обязательность LINQ и каким образом он делает процесс создания DSL бессмысленным извращением, даже в рамках учебного материала для псевдо-задачи по созданию условного сервера СУБД. По мне, так наоборот, раз уж эта технология LINQ такая прекрасная для всех случаев, то этот LINQ как раз может упростить создание учебного примера. Можно задать простое условие: нужно реализовать приложение, которое будет слушать сеть или по простому читать из консоли/файла строку с текстовым запросом, процесс как-то переварит этот запрос и обработает данные в ОЗУ (пусть вся информация будет только в коллекциях), и программа выдаст нужный ответ наружу. Фактически, достаточно только показать:
— пусть этот LINQ будет как язык запросов внутри этого LINQ-сервера (вместо SQL-сервера). Мы прочитали текстовую строку с запросом, какими-то уже имеющимися средствами скомпилировали этот запрос как исходник Немерле, как-то динамически загрузили новый байт-код и его успешно запустили для выполнения (при этом новый код чудесным образом через LINQ как-то добрался до данных в памяти основного процесса, в его коллекциях). Всё это хотелось бы увидеть, как оно примерно выглядит. Можно также показать схематично, очень кратко, как осуществлена поддержка этого DSL, т.е. LINQ (не думаю, что там настолько всё криво, что выглядит как бессмысленное извращение).
— или пусть мы всё-таки делаем SQL-сервер. Тогда запрос будет в виде SQL. Нужно как-то его через универсальный парсер в Немерле трансформировать в вид LINQ и дальше как выше по тексту. Здесь можно кратко показать как задаются правила разбора, как используется парсер, как генерируется текстовый код LINQ. Может здесь есть возможность схематично показать как реализуются бэкенды для Немерле, через которые можно текст SQL сразу перегнать в байт-код Net-а, где будет использован LINQ.
Такой реальный пример будет всем полезный, чем ругня в многотысячных топиках форума. В нём же и в двух словах не мешало бы раскрыть и все нужные термины по поводу DSL. Более того, нужен пример для тех, у кого платформа Net не является целевой. Я, например, как некий потенциальный разработчик сервера СУБД, должен буду задуматься над тем, что если я возьму Немерле, как замечательный инструмент для работы с DSL, с какими проблемами я столкнусь, чтобы создать объектные файлы, которые я смогу скомпоновать с остальным кодом проекта на С++ (без никакой зависимости от Net, особенно при использовании чудесного LINQ). Мне реально нужно понять, из-за чего профессионалы, работающие для таких проектов как gcc, LLVM с Сlang и пр., переключатся на создание бэкендов для Немерле, или по каким соображениям корпорации смогут их нагнуть для этого, или какие будут мотивы у интузиастов-профессионалов для адаптации Немерле под JVM, и т.д. Не хотелось бы всегда заниматься своей низкоуровневой генерацией кода на С++, Java, Erlang и т.п.
P.S. Вести неконструктивные споры не вижу никакого смысла, здесь уже более чем достаточно темы форума по поводу ненужности многих языков.
Здравствуйте, mrTwister, Вы писали:
T>>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
VD>>Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .
T>Я имею ввиду DSL для замены файлового менеджера: скопировать, удалить, переместить и пр.
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, mrTwister, Вы писали:
T>>>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
VD>>>Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .
T>>Я имею ввиду DSL для замены файлового менеджера: скопировать, удалить, переместить и пр.
GIV>Дык в ОС (Windows/Linux/etc) есть такой DSL .
По поводу Windows (cmd) соглашусь, а по поводу PowerShell, bash и пр., нет, это полноценные языки общего назначения (особенно PowerShell). Но назвать cmd хорошим DSL-ем значит сделать антирекламу всей идеи.
Здравствуйте, Ziaw, Вы писали:
Z>Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше.
В таком случае ты просто предложил другую платформу — руби. Вот и все преимущество.
I>>Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся. I>>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
Z>Воспроизведу ситуацию и продебажу
То есть вижла должна поддерживать все инструменты для ДСЛ, правильно ? Откуда это будет у кастомных ДСЛ ? Откуда прикладной программист будет знать, какие системные вызовы стоят за твоим дсл, если дсл будет возложен на архитектора ?
Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?
I>>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
Z>Я так понимаю у тебя, без перехода на личности, дискуссию вести не получается. Я пытаюсь показать, что есть задачи, где DSL удобнее библиотеки с API ...
Не надо слов, покажи решение для общего случая, а не для частных. Тебя же никто не просит накидать парсер-компилер, а только показать сам язык.
Z>... А ты — что есть задачи, для которых польза DSL не так очевидна. Можешь не стараться, никто не ставит под сомнение этот тезис.
Wolfhound как раз и ставит под сомнение. Роутинг, пермишны — это капля в море. Время на это расходуется около нуля даже без ДСЛ. А вот бизнеслогика это совсем другой расклад и здесь как я понял, у вас ничего нет, а это 99% расходов на разработку. Вот эти затраты и нужно сокращать.
Z>Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык.
Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.
Здравствуйте, Ikemefula, Вы писали:
Z>>Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше.
I>В таком случае ты просто предложил другую платформу — руби. Вот и все преимущество.
Я не понимаю, что ты хочешь этим сказать. Я показал, как нормально можно описать REST роутинг в приложении. Люди пытаются сделать что-то подобное с помощью fluent+expressions, но выходит все равно коряво. Без этого получаются ужаснейшие рукописные макароны.
I>То есть вижла должна поддерживать все инструменты для ДСЛ, правильно ? Откуда это будет у кастомных ДСЛ ? Откуда прикладной программист будет знать, какие системные вызовы стоят за твоим дсл, если дсл будет возложен на архитектора ?
А какие системные вызовы стоят за File.Exists и нужна ли специальная поддержка студии для него? В принципе можно наколбасить макросами кода так, что отлаживать его ты задолбаешься, но это проблема применима ко всем технологиям программирования. Безудержное применение ООП или ФП не по месту тебе даст проблем не меньше. Попробуй подебажить linq запрос, например. Если вдруг он начал падать на продакшен сервере
I>Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?
Прикладной понимает API на уровне архитектора? Та же ситуация и с макросами.
I>Не надо слов, покажи решение для общего случая, а не для частных. Тебя же никто не просит накидать парсер-компилер, а только показать сам язык.
Да не бывает частных решений для общего случая. Покажи чем там может помочь FP? Или это тоже негодная парадигма?
I>Wolfhound как раз и ставит под сомнение. Роутинг, пермишны — это капля в море. Время на это расходуется около нуля даже без ДСЛ. А вот бизнеслогика это совсем другой расклад и здесь как я понял, у вас ничего нет, а это 99% расходов на разработку. Вот эти затраты и нужно сокращать.
Ну так спорь с Wolfhound, я тут при чем? Впрочем, подозреваю, что ты пытаешься довести его точку зрения до абсурда и этим опровергнуть.
Z>>Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык.
I>Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.
Несмотря на ответы, мне толком непонятно что там происходит. Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое, одна мелкая операция. Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.
Здравствуйте, Ziaw, Вы писали:
I>>В таком случае ты просто предложил другую платформу — руби. Вот и все преимущество.
Z>Я не понимаю, что ты хочешь этим сказать. Я показал, как нормально можно описать REST роутинг в приложении. Люди пытаются сделать что-то подобное с помощью fluent+expressions, но выходит все равно коряво. Без этого получаются ужаснейшие рукописные макароны.
Возьми трекер и отфильтруй тикеты на эту маршрутизацию. Сколько суммарно времени ? Сколько разработчиков на проекте, тестеров, ба и тд ? Сколько выходит в процентах, если поделить сумму времени по тикетам на сумму времене всех работников на проекте ?
Z>А какие системные вызовы стоят за File.Exists и нужна ли специальная поддержка студии для него? В принципе можно наколбасить макросами кода так, что отлаживать его ты задолбаешься, но это проблема применима ко всем технологиям программирования. Безудержное применение ООП или ФП не по месту тебе даст проблем не меньше. Попробуй подебажить linq запрос, например. Если вдруг он начал падать на продакшен сервере
Роутинг на иис не сводится к File.Exist. Я привел абсолютно реальный пример, если что.
I>>Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?
Z>Прикладной понимает API на уровне архитектора? Та же ситуация и с макросами.
АПИ винды или ИИС — вполне возможно. Архитектор давно забыл что это такое.
Z>Да не бывает частных решений для общего случая. Покажи чем там может помочь FP? Или это тоже негодная парадигма?
Вот-вот.
I>>Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.
Z>Несмотря на ответы, мне толком непонятно что там происходит. Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое, одна мелкая операция. Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.
Это типичная операция. Он даже указал откуда это все взялось.
Здравствуйте, _Obelisk_, Вы писали:
T>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами? _O_>Любой shell на Linux/Unix — это DSL для работы с файлами, причем проверенный временем.
Осталось понять, почему при наличии хорошего и проверенного временем DSL при написании приложений всё ещё используются fopen/fstream/File/open/... ?
http://habrahabr.ru/post/143306/ интересная презентация. Т.е. сам предмет не новый, но я что-то не видел ещё подобную популяризацию, да ещё и на русском.
Здравствуйте, AndrewVK, Вы писали:
PSV>>А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:
AVK>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.
На Хаскеле был создан прототип (очень отдаленный) линка. Об этом Меер где-то вещал, если не ошибаюсь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое
Нет, это как раз таки типичная бизнес-логика.
Z>Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.
О как. Так покажи хоть ты, в каком стиле надо писать бизнес-логику наконец. Причем интересуют не выборки, которые все тут дружно берутся задслить, а логические ветвления, рассчеты, модификация.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
Z>>Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое
AVK>Нет, это как раз таки типичная бизнес-логика.
Отличное доказательство, что для этого требуется ДСЛ.
Z>>Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.
AVK>О как. Так покажи хоть ты, в каком стиле надо писать бизнес-логику наконец. Причем интересуют не выборки, которые все тут дружно берутся задслить, а логические ветвления, рассчеты, модификация.
Так ты задачу то опиши. Тогда и покажем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Нет, это как раз таки типичная бизнес-логика.
VD>Отличное доказательство, что для этого требуется ДСЛ.
Ну так где пример такого DSL?
VD>Так ты задачу то опиши. Тогда и покажем.
Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт? Т.е. рассчет зарплаты — один DSL, кадровый учет — другой, бухгалтерия — третий?
Ну да ладно — вот тебе весьма тривиальная задачка — рассчет ЗП. Некоторые прям в экселе делают. Нагуглилось сходу — http://www.reghelp.ru/raschet_zarplat.shtml .
Достаточно подробно? Только учти — писать рассчет зарплаты много много раз не нужно, достаточно одного. Т.е. DSL, завязанный конкретно на этот самый рассчет — не нужен. Нужен DSL, позволяющий решать подобные задачи.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
AVK>>>Нет, это как раз таки типичная бизнес-логика.
VD>>Отличное доказательство, что для этого требуется ДСЛ.
AVK>Ну так где пример такого DSL?
Где внятное описание задачи? Я как бы уже не один десяток ДСЛ-ей окучил. И авторитетно тебе заявляю, что создать ДСЛ по твоей лапше нельзя в принципе. Для ДСЛ-я вжно понимать, что за процесс мы описываем, а не видеть какие-то там действия не ясно с чем, да еще и в виде макаронного АПИ.
VD>>Так ты задачу то опиши. Тогда и покажем.
AVK>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт?
Это зависит. Иногда даже для отдельной подзадачи. А иногда универсальное решение которое можно использовать во многих проектах. Если речь идет о расчете амортизации, то скорее всего ДСЛ будет под этот рассчет, но в рамках системы.
AVK>Т.е. рассчет зарплаты — один DSL, кадровый учет — другой, бухгалтерия — третий?
Для зарплаты ДСЛ будет самое то. Для бухгалтерии возможно придется несколько использовать. Это тоже онятие растяжимое.
Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий. Для расчета баланса или оборотки нужно было компиляцию запустить. Прямо как в Рубо Паскале. :)
Так вот мой отец на базе этого ДСЛ-я вел сразу 7 фирм зарабатывая тем самым не плохие деньги на то время.
Это к вопросу предоставления ДСЛ-ей конечным пользователям. А уж для нужд разработчика их сам бог велел использовать.
AVK>Ну да ладно — вот тебе весьма тривиальная задачка — рассчет ЗП. Некоторые прям в экселе делают.
А у меня для этого свой ДСЛ-чик на ХМЛ-е создан (он правда более универсальный, я им еще накладные и счета генерирую). Правда количество сотрудников у нас сам знаешь какое :). И сложность рассчета тоже. Но тем не менее я спокойно обхожусь без бухгалтера и делаю эту самую зарплату за 10 секунд. Подъезжай, как нить, покажу.
AVK>Нагуглилось сходу — http://www.reghelp.ru/raschet_zarplat.shtml . AVK>Достаточно подробно? Только учти — писать рассчет зарплаты много много раз не нужно, достаточно одного.
Спасибо за разяснения, кэп! :))
AVK>Т.е. DSL, завязанный конкретно на этот самый рассчет — не нужен. Нужен DSL, позволяющий решать подобные задачи.
Ну, ты тут правильно заметил, что подобный ДСЛ чем-то на Ёксель должен быть похож. Он должен содержать рассчеты (они там взаимосвязанные) и указания откуда надо брать данные. Ну, а на выходе может быть, например, генерация файла экспорта 1Эс, который во многих банк-клиентах используется.
Я вот, у себя, данные прямо в ХМЛ храню (объемы нулевые — БД не нужна).
Вот пример моего, реально используемого на фирме, ДСЛ-я который считает зарплату и сразу же генерирует платежки для банк-клиента. Жирным выделены поля которые приходится изменить при выдаче зарплаты.
<?xml version="1.0"encoding="utf-8"?>
<Specification>
<Template>
<Path>ПлатежноеПоручениеДляБанкКлиентаСБ.txt</Path>
<Info>
<Copies>2</Copies>
</Info>
</Template>
<Includes>
<Include>Реквизиты-Название-фирмы-специально-удалено-в-файле-лежат-ее-реквизиты.xml</Include>
</Includes>
<Properties>
<ЗаМесяц>$Месяц</ЗаМесяц>
<День>27</День><Месяц>02</Месяц><Год>2012</Год>
<ЗарплатаСПодоходным>ставка-зарплаты-так-же-скрыта</ЗарплатаСПодоходным>
<Дата>$День.$Месяц.$Год</Дата>
<ЛицевойСчет>40100770016</ЛицевойСчет>
<ПодоходныйНалог>$(ЗарплатаСПодоходным * 13 / 100)</ПодоходныйНалог>
<ЗарплатаНаРуки>$(ЗарплатаСПодоходным - ПодоходныйНалог)</ЗарплатаНаРуки>
<Платеж>
<Номер>$(НомерЭлемента())</Номер>
<Статус>01</Статус>
<Показатель>
<Основания>ТП</Основания>
<НалоговогоПериода>МС.$ЗаМесяц.$Год</НалоговогоПериода>
<НомераДокумента>0</НомераДокумента>
<ДатыДокумента>$Дата</ДатыДокумента>
<Типа>НС</Типа>
</Показатель>
<СуммаПрописью>$(РублиПрописью(Платеж_Сумма)) 00 копеек</СуммаПрописью>
<СуммаНДС>Без НДС</СуммаНДС>
<СуммаБезКопеек>$Платеж_Сумма-00</СуммаБезКопеек>
<Город>Москва</Город>
<Очередность>3</Очередность>
<ОКАТО>45280580000</ОКАТО>
</Платеж>
</Properties>
<Items>
<Платеж id="ПенсионныйСтраховой">
<Сумма>$(ЗарплатаСПодоходным * 16 / 100)</Сумма>
<Статус>01</Статус>
<Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
<Основание>
"Уплата ПФР - страховая часть пенсии." Рег. № 087-301-000107. За $ЗаМесяц месяц $Год года.
</Основание>
<ИНН>7703363868</ИНН>
<КПП>770301001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
<БИК>044583001</БИК>
<КБК>39210202010061000160</КБК>
<Показатель>
<Типа>ВЗ</Типа>
</Показатель>
</Платеж>
<Платеж id="ПенсионныйНакопительная">
<Сумма>$(ЗарплатаСПодоходным * 6 / 100)</Сумма>
<Статус>01</Статус>
<Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
<Основание>
"Уплата ПФР - накопительная часть пенсии." Рег. № 087-301-000107. За $ЗаМесяц месяц $Год года.
</Основание>
<ИНН>7703363868</ИНН>
<КПП>770301001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
<БИК>044583001</БИК>
<КБК>39210202020061000160</КБК>
<Показатель>
<Типа>ВЗ</Типа>
</Показатель>
</Платеж>
<Платеж id="ФФОМС">
<Статус>01</Статус>
<Сумма>$(ЗарплатаСПодоходным * 3.1 / 100)</Сумма>
<Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
<Основание>Рег. в Управлеии ПФР № ГУ 6 087-301-000107. Рег. № в ФОМС 453160900411818. Страховые взносы ОМС, зачисляемые в бюджет ФФОМС.</Основание>
<ИНН>7703363868</ИНН>
<КПП>770301001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
<БИК>044583001</БИК>
<КБК>39210202101081011160</КБК>
<Показатель>
<Типа>ВЗ</Типа>
</Показатель>
</Платеж>
<Платеж id="ПодоходныйНалог">
<Статус>02</Статус>
<Сумма>$ПодоходныйНалог</Сумма>
<Основание>Подоходный налог с з/п.</Основание>
<Имя>УФК по г. Москве (ИФНС России № 16 по СВАО г. Москве).
Лицевой счет $ЛицевойСчет.</Имя>
<ИНН>7716103458</ИНН>
<КПП>771601001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
<БИК>044583001</БИК>
<КБК>18210102021011000110</КБК>
</Платеж>
<Платеж id="СтраховойТарифОтрасли">
<Статус>08</Статус>
<Тариф>0.2</Тариф>
<Сумма>$(ЗарплатаСПодоходным * Платеж_Тариф / 100)</Сумма>
<Основание>Уплата страхового тарифа
отрасли $Платеж_Тариф%. Рег. № 7729032413.</Основание>
<Имя>Филиал №29 ГУ - МРО ФСС РФ</Имя>
<ИНН>7710030933</ИНН>
<КПП>770701001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России в г.Москве</ВБанке>
<БИК>044583001</БИК>
<КБК>39310202050071000160</КБК>
</Платеж>
<Платеж id="ФСС">
<Статус>08</Статус>
<Тариф>2.9</Тариф>
<Сумма>$(ЗарплатаСПодоходным * Платеж_Тариф / 100)</Сумма>
<Основание>Уплата в ФСС по временной нетрудоспособности и в связи с
материнством $Платеж_Тариф%. Рег. № 7729032413.</Основание>
<Имя>УФК по г. Москва (Госудерственное учреждение -
Московское региональное отделение Фонда социального
страхования Российской Фередерации)</Имя>
<ИНН>7710030933</ИНН>
<КПП>770701001</КПП>
<РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
<КорСчет></КорСчет>
<ВБанке>Отделение 1 Московского ГТУ Банка России в г.Москве</ВБанке>
<БИК>044583001</БИК>
<КБК>39310202090071000160</КБК>
<Показатель>
<Типа>ВЗ</Типа>
</Показатель>
</Платеж>
<Платеж id="ПереводСуммыЗарплатыНаКредитку">
<Сумма>$ЗарплатаНаРуки</Сумма>
<Основание>л/с 40817.810.0.3809.4505543 RuR з/п Чистяков Владислав Юрьевич</Основание>
<Имя>Чистяков Владислав Юрьевич, Мещанское ОСБ № 7811/01444, г. Москва</Имя>
<ИНН>772415355463</ИНН>
<КПП>0</КПП>
<РассчетрыйСчет>40817810038094505543</РассчетрыйСчет>
<КорСчет>30101810400000000225</КорСчет>
<ВБанке>Сбербанк России, ОАО. г. Москва</ВБанке>
<БИК>044525225</БИК>
<КБК></КБК>
<Показатель>
<Основания></Основания>
<НалоговогоПериода></НалоговогоПериода>
<НомераДокумента></НомераДокумента>
<ДатыДокумента></ДатыДокумента>
<Типа></Типа>
</Показатель>
<СуммаПрописью>$(РублиПрописью(Платеж_Сумма)) 00 копеек</СуммаПрописью>
<Очередность>3</Очередность>
<ОКАТО></ОКАТО>
<Статус></Статус>
</Платеж>
</Items>
</Specification>
А вот файлик который используется для генерации платежек в формате 1Эс-ного экспорта:
Здравствуйте, mrTwister, Вы писали:
T>По поводу Windows (cmd) соглашусь, а по поводу PowerShell, bash и пр., нет, это полноценные языки общего назначения (особенно PowerShell). Но назвать cmd хорошим DSL-ем значит сделать антирекламу всей идеи.
ДСЛ-ями скорее являются команды копирования, перемещения и удаления. Против robocopy.exe возражения есть? :))
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И авторитетно тебе заявляю, что создать ДСЛ по твоей лапше нельзя в принципе.
Больше вопросов не имею.
AVK>>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт?
VD>Это зависит. Иногда даже для отдельной подзадачи.
Ясно. DSL с ровно одним использованием — это круто.
VD>Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий.
Только DSL там был очень похож на то, что мы сейчас имеем в 1С.
VD>Вот пример моего, реально используемого на фирме, ДСЛ-я который считает зарплату и сразу же генерирует платежки для банк-клиента. Жирным выделены поля которые приходится изменить при выдаче зарплаты.
Это просто настройка для уже написанного кода расчета зарплаты. Я же спрашивал про DSL для самого кода рассчета зарплаты.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт? VD>>Это зависит. Иногда даже для отдельной подзадачи.
AVK>Ясно. DSL с ровно одним использованием — это круто.
Я уже где-то слышал подобный домысел. ДСЛ — не функция, чтобы можно было говорить о его применении. ДСЛ — это язык. Даже однократное его применение в проекте может дать существенное сокращение кода и существенно увеличить ясность решения.
VD>>Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий.
AVK>Только DSL там был очень похож на то, что мы сейчас имеем в 1С.
Вообще ничего общего. Там ДСЛ имел вид списка проводок. Что-то типа:
Сам Турбо-Бухгалтер был эдаким компилятором который читал этот файл и генерировал по нему нужные документы. Еще были другие файлы с описание счетов и т.п.
Эдакая смесь базы данных в текстовом виде и простенького языка программирования позволяющего вычислять суммы проводок на основании имеющихся данных.
Выглядит примитивно, но моему отцу очень нравилось, так как легко можно было сделать произвольные вычисления.
VD>>Вот пример моего, реально используемого на фирме, ДСЛ-я который считает зарплату и сразу же генерирует платежки для банк-клиента. Жирным выделены поля которые приходится изменить при выдаче зарплаты.
AVK>Это просто настройка для уже написанного кода расчета зарплаты. Я же спрашивал про DSL для самого кода рассчета зарплаты.
Ты ошибаешься. Расчет зарплаты прямо там приведен. Просто он очень простой.
Сам расчет зарплаты — это не более чем набор формул. Вводим исходные цифры (сумма зарплаты, в моем случае) и вычисляем какие налоги нужно заплатить.
Если бы стояла задачи рассчитывать сами начисления, то это тоже не было бы проблемой. Описать их в виде пропертей и использовать в рассчете.
То что я тебе показал — это нечто генератора отчетов по модели. Модель состоит из свойств (пропертей) и ряда "документов". Я с помощью этого дела генерирую накладные при выходе нового номера журнала. Опять же процедура полностью автоматизирована. Документами, при этом, являются список заказов (кто чего заказал и какая у них скидка), а результатом набор документов: счета, накладные, счета фактуры. Для некоторых журналов в итоге получается стопка в сотни страниц. При этом заводится всего несколько цифр. Печать идет через эксел. Он как шаблонизатор выступает. Открывается в текстовом виде (xml), трансформируется и выбрасывается на печать.
Заметь ДСЛ-ь этот не внутренний, а внешний. Используется он в трех разных видах задач и автоматизирует работу которая при ручном ее исполнении у меня занимала по пол дня (а то и весь день). Но главное — это то, что он резко сокращает объем ошибок и их исправление, в случае чего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>ДСЛ — это язык. Даже однократное его применение в проекте может дать существенное сокращение кода и существенно увеличить ясность решения.
Моя практика подобного не подтверждает.
VD>Выглядит примитивно, но моему отцу очень нравилось, так как легко можно было сделать произвольные вычисления.
Так это, ТБ твой вполне жив. Только особой популярностью почему то не пользуется.
AVK>>Это просто настройка для уже написанного кода расчета зарплаты. Я же спрашивал про DSL для самого кода рассчета зарплаты. VD>Ты ошибаешься. Расчет зарплаты прямо там приведен. Просто он очень простой.
Это не рассчет, это настройка движка рассчета. Потому что реальный рассчет — это куча чисто эвристических правил. Их, конечно, можно в итоге свести к некоему набору заранее заготовленного кода, только особого преимущества перед обычной библиотекой у такого DSL не будет. Потому что основная сложность вовсе не в описании начислений и удержаний со стандартным рассчетом (% от стандартной базы, это даже не нужно в каком то DSL описывать, это банально заталкивается в несколько справочников), а как раз таки в реализации уникальных методик рассчета (типа рассчета отпускных или каких нибудь хитровысущенных скидок типа возврата НДФЛ при покупке жилья). И именно про них я спрашивал. А про DSL, который ты привел мне не интересно, он тривиален.
VD>Сам расчет зарплаты — это не более чем набор формул.
Купи методичку по рассчету ЗП и ознакомься, там далеко не только формулы.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
VD>>ДСЛ — это язык. Даже однократное его применение в проекте может дать существенное сокращение кода и существенно увеличить ясность решения.
AVK>Моя практика подобного не подтверждает.
Это проблемы твоей практики и инструментов что ты используешь.
AVK>Это не рассчет, это настройка движка рассчета.
Ты уж полную хреновину не лепи, плиз. Если ты не в силах сосредоточиться и рассмотреть там формулы расчетов, то это твои проблемы.
AVK>Потому что реальный рассчет — это куча чисто эвристических правил.
:)))
Вся бухгалтения — это арифметика уровня первого класса! Какие на фиг "эвристических правил"?
AVK>Их, конечно, можно в итоге свести к некоему набору заранее заготовленного кода, только особого преимущества перед обычной библиотекой у такого DSL не будет.
Я тебе привел ДСЛ который не будучи специально заточенным под эту задачу позволил мне свести всю возню с зарплатой к вводу даты и выбору из контекстного меню одного пункта.
Сам рассчет, можно было сделать и Ёкселе. Ёксель вообще является средством для создания своих ДСЛ-ей для не программистов. Но вот сгенерировать платежки из него затруднительно. И вообще, программировать его затруднительно. А вот указанный ДСЛ на раз. Описываешь структуры дунных, формулы (можно обращаться к свойствам и значениям из документов по иерархической ссылке) и у тебя готово решение нудной (при исполнении вручную) проблемы.
А то что это ДСЛ, а не захардкоженное решение позволяет менять все что угодно в мгновении ока, а не ждать пока производитель софта за телится и не платить ему денег.
Вот недавно сменили Банк-Клиент Сербанка на онлайн-версию. Изменился формат импорта. Ну, дык после того как я разобрался, что хочет новый вариант импорта изменения заняли пару секунд.
Наличие такого (а лучше специализированного и с синтаксисом) ДСЛ-я в реальной программе расчета зарплаты позволило бы сделать программу более гибкой и удобной.
В 1Эс еще можно конфигурацию изменить. Но это явно не для всех. А в другом ПО все в доску захардкожено.
AVK>Потому что основная сложность вовсе не в описании начислений и удержаний со стандартным рассчетом (% от стандартной базы, это даже не нужно в каком то DSL описывать, это банально заталкивается в несколько справочников),
Банальное заталкивание в справочники? Это ты на кого рассчитываешь? И на какой объем работы рассчитваешь? Пойми, я с помощью указанного ДСЛ-я решил свою конкретную задачу где-то за 2 часа. Это примерно то же время, если бы я делал все вручную (с учетом добавления платежек и т.п.).
ДСЛ-и тем и хороши, что позволяют ввести высокоуровневое описание для конкретных проблем, а не создавать вселенский всемогутер который решает все проблемы универсальным образом.
Причем, если это внешний ДСЛ, как в данном случае, то я могу настраивать решение прямо под задачу на месте.
AVK> а как раз таки в реализации уникальных методик рассчета (типа рассчета отпускных или каких нибудь хитровысущенных скидок типа возврата НДФЛ при покупке жилья).
Что там уникального? Просто формулы. Это для тебя, привыкшего все хардкодить, кажется сложным "запихнуть все в таблички". А я сразу мыслю о проблеме в терминах модели. В задачи предметной области входит формирование рассветов на основе заранее неизвестных данных? Отлично! Вводим ДСЛ описывающий эти данные и возможность задать формулы для расчета. Далее остается только прикрутить интерфейс для добавления отдельных ДСЛ-файликов
и ГУЙ который позволит людям не возиться с ДСЛ-ем, а вводить исходные данные в привычном для них виде (мне это и не надо).
AVK> И именно про них я спрашивал. А про DSL, который ты привел мне не интересно, он тривиален.
Ты не уточнял про что спрашивал. Но это даже хорошо. Это дает возможность показать, что разным людям нужно разное. И создать ДСЛ абстрагирующий программиста от запросов этих людей очень даже не сложно.
VD>>Сам расчет зарплаты — это не более чем набор формул.
AVK>Купи методичку по рассчету ЗП и ознакомься, там далеко не только формулы.
Ты это советуй своим подчиненным. А мне не надо. П. 5, как не как. Я в бухгалтерии сильно больше твоего знаю, так как сам ею занимаюсь уже 10 лет.
Ты просто не можешь понять одной прописной истины. У разных людей разные проблемы. Соответственно и решают они их по разному. Мне сложные начисления (а именно так называется то о чем говорил ты) попросту не нужны. А вот расчет зарплаты и формирование кучи платежек для меня проблема актуальная.
Если бы я писал код для зарплатного модуля какой-то финансовой системы, то сделал бы по другому. Потому как решения должны быть адекватны задачам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>О как. Так покажи хоть ты, в каком стиле надо писать бизнес-логику наконец. Причем интересуют не выборки, которые все тут дружно берутся задслить, а логические ветвления, рассчеты, модификация.
Я не знаю как надо Но логические ветвления у меня просто не получаются большими. Давай я попробую чуть отрефакторить твой код в то, что написал бы я.
// откатить отработку документов в ХО
UncarryDocuments(objectsIds);
var cardsDeleteSet = new HashSet<IInventoryCardBase>();
var documents = Manager.Get(objectsIds);
var inventories = from doc in documents
from obj in doc.GetObjects()
let inv = obj.GetInventory()
select new
{
Inv = inv,
Operations = inv.GetInventoryOperations(null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null)
};
foreach (var row in inventories)
{
foreach (var operation in row.Operations) // удалить операции
{
MustCanDelete(operation); // будет кидать экзепшен в случае если там есть поздние операции, я думаю это общее правило в логике
// != в данном случае должен делать ровно то же самое, что и Equals, который следует использовать только для полиморфных операцийif (operation.InventoryCardBefore != operation.InventoryCardAfter)
if (!operation.InventoryCardAfter is IAccrualAccountingInventoryCard)
cardsDeleteSet.Add(operation.InventoryCardAfter);
DeleteInventoryOperation(operation);
}
var inv = row.Inv;
if (inv.ChangesHistory)
SomeChangesHistoryActions(inv, cardsDeleteSet); // я не могу придумать имя методу, ибо не понимаю что там происходитelse
ChangeInventoryActualStateInDocuments(inv, inv);
// изменить ИО
inv.MateriallyResponsiblePerson = doc.GetDelivererMateriallyResponsiblePerson();
inv.StructuralSubdivision = doc.GetDelivererSubdivision();
}
// удалить созданные при отработке инвентарные карточки
Manager.DeleteObjects(cardsDeleteSet);
Я постарался не менять окружение кода. Только вынес два хелперных метода, один из них почти наверняка реюзабельный. Второй скорее всего нет, но там черная магия которая должна быть вынесена под неким кодовым названием. Логика стала достаточно простой для дальнейшей поддержки, страшных логических ветвлений не осталось.
Здравствуйте, batu, Вы писали:
B>Меня это интересовало с точки зрения метаязыка, который сам являясь языком, может геренрировать другие языки не меняя синтаксис, но меняя семантику. Так называемая субъектно-ориентированная парадигма, или концептная..Т.е то, чем я занимаюсь
Вот знаешь, меня не покидает ощущение, что ты делаешь что-то интересное. Но когда я читаю такое:
B>Концепт это тройка (L, S, P), где L -размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами и P –логическое представление (высказывание), используемое при логической интерпретации. Создание концепта заключается в определении его свойств и вложенной группы концептов, определяющих его семантику.
Я делаю и переключаюсь на следующий пост. Ибо для меня это звучит как "огурцы ложкой банка майонеза".
Здравствуйте, Ziaw, Вы писали:
Z>Я не знаю как надо
Ну вот о том и речь. Рассказать как все плохо в универсальных языках все могут, а вот предложить в сложных ситуациях решение — не очень.
Z> Но логические ветвления у меня просто не получаются большими. Давай я попробую чуть отрефакторить твой код
А зачем? Я ведь не про качество кода спрашивал, а про DSL.
Z> Логика стала достаточно простой для дальнейшей поддержки, страшных логических ветвлений не осталось.
Ну, может WH и Владу это поможет понять код.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ziaw, Вы писали:
B>>Концепт это тройка (L, S, P), где L -размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами и P –логическое представление (высказывание), используемое при логической интерпретации. Создание концепта заключается в определении его свойств и вложенной группы концептов, определяющих его семантику.
Z>Я делаю и переключаюсь на следующий пост. Ибо для меня это звучит как "огурцы ложкой банка майонеза".
Ну, извини.. Практически все гораздо проще. Но по другому пока не могу определить понятней. Давай расскажу подробней, может подскажешь определение лучше. Я в гении не записываюсь, и даже наоборот. Всегда рад советам. И получал их здесь много и полезных. Работаю сам. Оппонентов нет. Это плохо. Спрашивай.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот о том и речь. Рассказать как все плохо в универсальных языках все могут, а вот предложить в сложных ситуациях решение — не очень.
Ну так это проблема сложности, неужели ты думаешь, что ее можно решить как-то универсально? DSL один из инструментов перевода сложности "из количество в качество".
Z>> Но логические ветвления у меня просто не получаются большими. Давай я попробую чуть отрефакторить твой код AVK>А зачем? Я ведь не про качество кода спрашивал, а про DSL.
Конкретно в этой ветке ты просил показать в каком стиле надо писать бизнеслогику.
Z>>Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.
AVK>О как. Так покажи хоть ты, в каком стиле надо писать бизнес-логику наконец. Причем интересуют не выборки, которые все тут дружно берутся задслить, а логические ветвления, рассчеты, модификация.
Здравствуйте, Ziaw, Вы писали: B>>Концепт это тройка (L, S, P), где L -размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами и P –логическое представление (высказывание), используемое при логической интерпретации. Создание концепта заключается в определении его свойств и вложенной группы концептов, определяющих его семантику.
Z>Я делаю и переключаюсь на следующий пост. Ибо для меня это звучит как "огурцы ложкой банка майонеза".
Хотя время есть.. Попробую подробней.. Концепт это некая фигня с которой может работать некая виртуальная машина. Что нужно машине? Во первых размер. Это и загрузка, и выделение памяти и протокол обмена. Во-вторых эта фигня должна что-то делать.. Ну, например, концепт For должен организовать цикл, а концепт Class должен создавать объекты..Это я и назвал семантическим содержанием. За название не держусь. Ну, и в третьих концепт может содержать высказывание. Т.е. логическое представление, которое как в Прологе создает среду для логической интерпретации.
В итоге получаем систему в которой все создано концептом Concept (концепт-класс) подобно как в объектной парадигме объекты создаются классом (Class). Только здесь получается что все в системе создано вот этим концептом-классом. Ну, и витруальная машина проще.. Она вообще ничего не делает.. Встретила непосредственное наследованый концепт и запустила программу в него вложенную. С загрузкой и храненем тоже все очевидно. Правила построения и, следовательно, размеры вычисляются по единым правилам.. Операций ввода-вывода вообще нет. Везде концепты и механизм событий (концепт Event). Об этом позже. Что б не перегружать.. Таким образом на уровне концептов можем работать с любой архитектурой компа..Ясный перец что системные концепты надо будет для каждого свои написать. С адресацией тоже не так просто.. Адрес тоже концепт..
Где-то так.. Как смог
Здравствуйте, Ziaw, Вы писали:
AVK>>Ну вот о том и речь. Рассказать как все плохо в универсальных языках все могут, а вот предложить в сложных ситуациях решение — не очень.
Z>Ну так это проблема сложности, неужели ты думаешь, что ее можно решить как-то универсально?
Я то, как раз, так не думаю.
Z>>> Но логические ветвления у меня просто не получаются большими. Давай я попробую чуть отрефакторить твой код AVK>>А зачем? Я ведь не про качество кода спрашивал, а про DSL.
Z>Конкретно в этой ветке ты просил показать в каком стиле надо писать бизнеслогику.
Имелся в виду DSL. А стиль — твой рефакторинг принципиально ничего не изменил, ты просто причесал очевидные моменты.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, batu, Вы писали:
B>Хотя время есть.. Попробую подробней.. Концепт это некая фигня с которой может работать некая виртуальная машина. Что нужно машине? Во первых размер.
Давай начнем с размера. Что это? Чему равен размер концепта For? Почему он так важен, что ты его ставишь во главу тройки?
Вообще идея похожа на Nemerle, где в языке минимум примитивов, остальное макросы. Компилятор запускает их на выполнение и они генерируют код. Но там под это создан механизм квазицитирования. Покажи пример кода концептов и их использования. Например концепты Class и For.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, batu, Вы писали:
B>>Хотя время есть.. Попробую подробней.. Концепт это некая фигня с которой может работать некая виртуальная машина. Что нужно машине? Во первых размер.
Z>Давай начнем с размера. Что это? Чему равен размер концепта For? Почему он так важен, что ты его ставишь во главу тройки?
Можно поменять местами.. Тем более размер все равно вычисляется. Другое дело что по единым правилам. Z>Вообще идея похожа на Nemerle, где в языке минимум примитивов, остальное макросы. Компилятор запускает их на выполнение и они генерируют код.
У меня и текст тоже концепты. Потому компилятор, редактор, интерпретатор и браузер Это все одно и тоже. Заодно и UML и Exel и графический редактор. Потому компиляция это перевод из концептов в концепты. Теоретически ничего не меняется, но есть упрощения. Мы же знаем что должно получиться. В смысле знаем что результат тоже концепты .. Ну и немного отличается.. Четко разделен лексический, синтаксический и семантический анализ где проверяются ограничения (согласно описания класса-концепта) и создаются новые концепты (а не код). Есть еще один этап 0-выполнение. На этом этапе формируются адреса, там где это возможно.
Покажи пример кода концептов и их использования. Например концепты Class и For. Это системные концепты там двоичный код. Создание концепта For выглядит приблизительно так.
Соncept For (0233, 456...) цифры это код после ассемблирования..
Общий синтаксис создания концепта "класс концепта" "Имя концепта" (Реализация)
Реализация="скобка открывающая" ("определение значений свойств"|"определение свойств"|"Содержание"} "скобка закрывающая"
"определение значений свойств"="Точка" "Имя свойства"="Значение"
"определение свойств"= Property "Концепт"
Содержание="Операторы языка"
Сори.. Это очень приблизительно..И со скобками проблемы.. У меня текстовые разный смысл имеют.. И Property только свойства концепта. У объекта атрибуты Dim.. Но для общего понимания сойдет..
Здравствуйте, AndrewVK, Вы писали:
Z>>Ну так это проблема сложности, неужели ты думаешь, что ее можно решить как-то универсально? AVK>Я то, как раз, так не думаю.
Так почему ты требуешь универсального DSL? Ты же не показал домен, которым должен управлять язык. Домен это набор сущностей и элементарных операций над ними. Когда они известны, можно прикинуть DSL для конструирования бизнес транзакций. Ты показал код элементарной операции, кирпичика для построения транзакции, вероятно сам кирпичик изменится не особо. DSL будет применен уровнем выше. Сами же элементарные кирпичики все равно придется писать на таком же низком уровне.
Здравствуйте, Ziaw, Вы писали:
Z>Так почему ты требуешь универсального DSL?
Я совсем универсального не требую, я требую универсального в рамках заданного домена.
Z> Ты же не показал домен, которым должен управлять язык.
Домен общеизвестен — ERP.
Z> Домен это набор сущностей и элементарных операций над ними
Тебя кто то обманул. Домен по русски — предметная область.
A domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering.
Z>. Когда они известны, можно прикинуть DSL для конструирования бизнес транзакций. Ты показал код элементарной операции, кирпичика для построения транзакции, вероятно сам кирпичик изменится не особо.
Ну то есть заголовок топика, в котором этот пример приведен был (Языки общего назначения не имеют смысла!) — несколько неверен?
Z> Сами же элементарные кирпичики все равно придется писать на таком же низком уровне.
О том и речь.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>ДСЛ-ями скорее являются команды копирования, перемещения и удаления. Против robocopy.exe возражения есть?
И чем этот DSL лучше powershell`а? На всякий случай замечу, что команды по манипуляции файлами в powershell не являются его первоклассными сущностями, это просто часть стандартной библиотеки, как например std::string в С++. То есть это не DSL внутри языка, как Linq Query Syntax в C#
Здравствуйте, alex_public, Вы писали:
_>http://habrahabr.ru/post/143306/ интересная презентация. Т.е. сам предмет не новый, но я что-то не видел ещё подобную популяризацию, да ещё и на русском.
Здравствуйте, alex_public, Вы писали:
_>http://habrahabr.ru/post/143306/ интересная презентация. Т.е. сам предмет не новый, но я что-то не видел ещё подобную популяризацию, да ещё и на русском.
Доступ к публикации закрыт
Вы пытаетесь открыть публикацию, написанную пользователем Polazhenko.
Автор переместил топик в черновики.
Здравствуйте, AndrewVK, Вы писали:
Z>> Домен это набор сущностей и элементарных операций над ними AVK>Тебя кто то обманул. Домен по русски — предметная область.
Которая для программиста превращается в набор сущностей и элементарных операций над ними.
AVK>Ну то есть заголовок топика, в котором этот пример приведен был (Языки общего назначения не имеют смысла!) — несколько неверен?
Конечно, надо понимать, что заголовок провокационный и не может быть верен на 100%.
Здравствуйте, Ziaw, Вы писали:
AVK>>Тебя кто то обманул. Домен по русски — предметная область. Z>Которая для программиста превращается в набор сущностей и элементарных операций над ними.
Странная какая то у тебя логика. Не знаю что там у тебя для абстрактного программиста превращается, но когда говорят о домене в контексте DSL, то имеется в виду именно терминология и набор понятий из предметной области, а не какие то абстрактные сущности. Модель и домен это далеко не одно и то же. Модель проектируется исходя из потребностей конкретной решаемой задачи, домен же охватывает отрасль в целом и никак не завязан ни на конкреную задачу, ни на специфику конкретного софта (если, конечно, этот софт сам не является доменом).
Z>Конечно, надо понимать, что заголовок провокационный и не может быть верен на 100%.
Боюсь, автор заголовка с тобой не согласится.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, batu, Вы писали:
B>>Хотя время есть.. Попробую подробней.. Концепт это некая фигня с которой может работать некая виртуальная машина. Что нужно машине? Во первых размер.
Z>Давай начнем с размера. Что это? Чему равен размер концепта For? Почему он так важен, что ты его ставишь во главу тройки?
Не торкнуло?
Разделяем термины. DSL — не метапрограммирование (как термин). DSL — не прикладная библиотека.
Для справки: язык программирования 1С не дсл, а язык общего назначения. Изначально в нем нет проблемной специфики, специфика введена архитектурой и прикладными объектами. Они этого идеологического подхода придерживались, не знаю уж, кто им его разработал.
Расчет зарплаты в 1С не дсл, это комплекс средств — язык + платформа (база и прикладные объекты). В составе платформы 1С есть и DSL — язык запросов на базе SQL. Как частный случай этот dsl еще и метапрограммирование, поскольку напрямую транслируется в известный нам язык SQL и работает в известном окружении, вполне специализированном на решение определенных задач и 1С-ники потом и с итоговым SQL работают.
Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже.
> Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
Ать еть, ашипка. Формально _расширение_ языка общего назначения не делает его domain-specific. Как точки зрения придерживаться при расширении языка, нужно подумать.
Здравствуйте, grosborn, Вы писали:
G>Разделяем термины. DSL — не метапрограммирование (как термин). DSL — не прикладная библиотека.
G>Для справки: язык программирования 1С не дсл, а язык общего назначения. Изначально в нем нет проблемной специфики, специфика введена архитектурой и прикладными объектами. Они этого идеологического подхода придерживались, не знаю уж, кто им его разработал. G>Расчет зарплаты в 1С не дсл, это комплекс средств — язык + платформа (база и прикладные объекты). В составе платформы 1С есть и DSL — язык запросов на базе SQL. Как частный случай этот dsl еще и метапрограммирование, поскольку напрямую транслируется в известный нам язык SQL и работает в известном окружении, вполне специализированном на решение определенных задач и 1С-ники потом и с итоговым SQL работают.
С написанным выше я согласен. Что из сказанного выше, по твоему, противоречит моим словам?
G>Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
И получишь встроенный в язык ДСЛ. Не более того. Иначе Лисп и Немерле по твоему определению автоматически становятся ДСЛ-ями (ведь в них можно легко вводить поддержку прикладной специфики), что явно не так.
G>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде.
Это противоречит сказанному тобой выше.
G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
А как же пример с 1С?
G>Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже.
Для начала хорош бы устранить противоречия в твоих же высказываний.
По моей классификации ДСЛ должен быть нацелен на решение задач в одной предметной области. Универсальный язык автоматически этому противоречит. Другими словами ориентации на домен мало. Это всего лишь один из признаков. В противном случае в ДСЛ-и можно будет записать почти любой язык, и смысл этого термина просто исчезнет, так как он будет синонимом термина "язык".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> С написанным выше я согласен. Что из сказанного выше, по твоему, противоречит моим словам?
Мое замечание по использованию термина, я не спорю с тобой. Но призываю не обобщать DSL по своему усмотрению. Если есть потребность в термине, при имеющихся противоречиях с существующими скорее нужно вводить новый или даже систему.
DSL это определение в рамках классификации языков GP/DSL/another-SL.
> G>Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL. > > И получишь встроенный в язык ДСЛ. Не более того. Иначе Лисп и Немерле по твоему определению автоматически становятся ДСЛ-ями (ведь в них можно легко вводить поддержку прикладной специфики), что явно не так.
Уже поправился. Расширение не всегда приводит к появлению domain-specific языка, само расширение так же не обязательно domain-specific, тут нужно смотреть частные случаи.
На Немерле, насколько я его не знаю, нет поддержки конкретной проблемной области на уровне языка, так же его средства для метапрограммирования не ограничивают область применимости языка (с точки зрения идеологии, а не конкретной реализации). Если это не так, назови проблемную область или как-то по другому обозначь домен.
Не используй понятие DSL, если домен не обозначен.
> G>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. > > Это противоречит сказанному тобой выше.
Ничуть. Можешь задать уточняющие вопросы.
> G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific. > > А как же пример с 1С?
Выверен, верен. Да ты спроси светил 1С, если они еще не вымерли, хы
> G>Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже. > > Для начала хорош бы устранить противоречия в твоих же высказываний.
Вроде бы Их нет.
> По моей классификации ДСЛ должен быть нацелен на решение задач в одной предметной области. Универсальный язык автоматически этому противоречит. Другими словами ориентации на домен мало. Это всего лишь один из признаков. В противном случае в ДСЛ-и можно будет записать почти любой язык, и смысл этого термина просто исчезнет, так как он будет синонимом термина "язык".
Если ты убираешь из определения домен, то автоматически теряешь право называть DSL-ем. Домен тут определяет, домен должен быть. "specific" и "purpose" дает нам направление к применимости, проблемной области. То есть если скажем четко выделяющийся домен, это методология, то нужно смотреть, если это не дает эффекта ограничения на область применимости, то этот домен даже с натяжкой не даст нам domain-specific часть в термине DSL.
Если ты вводишь некоторый набор макросов не общего назначения, то DSL-ем можно назвать только этот набор, а не язык в котором ты его ввел. Средства трансляции не DSL, общие ограничения на синтаксис макросов у вас в Немерле ограничивает как-то область применимости?
Так же для формального соответствия хорошо бы это было не "изменение синтаксиса", а язык. Так же трансляция каких-нибудь невербальных данных выпадает из понятия термина DSL (этот формат данных).
> G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific. > > А как же пример с 1С?
Если я правильно понял твой вопрос, ты предполагаешь в 1С поддержку предметной области на уровне языка. Идеологически и практически ее не было на уровне языка, не думаю что она появилась в последние годы (давно не смотрел). Повторю, вся поддержка проблемной области в 1С на уровне архитектуры и специальных прикладных объектов, создаваемых командами общего назначения, а уже сами они публикуют проблемной области интерфейсы и имеют проблемно-ориентированную логику внутри. DSL который язык запросов, проблемная область у него это не расчет зарплаты, а структура базы данных, движок самой 1С. И он не встроен в язык, он представлен строкой текста в языке 1С.
Здравствуйте, grosborn, Вы писали:
>> А как же пример с 1С?
G>Если я правильно понял твой вопрос,
Похоже, не правильно.
G>ты предполагаешь в 1С поддержку предметной области на уровне языка.
Я говорю, что по твоим же словам 1С не ДСЛ. А раз так, то это противоречит твоим же словам из второй половины твоего сообщения.
G> Идеологически и практически ее не было на уровне языка, не думаю что она появилась в последние годы (давно не смотрел). Повторю, вся поддержка проблемной области в 1С на уровне архитектуры и специальных прикладных объектов, создаваемых командами общего назначения, а уже сами они публикуют проблемной области интерфейсы и имеют проблемно-ориентированную логику внутри. DSL который язык запросов, проблемная область у него это не расчет зарплаты, а структура базы данных, движок самой 1С. И он не встроен в язык, он представлен строкой текста в языке 1С.
Ну, так теперь внимательно прочти свои же слова во второй половине своего исходного сообщения и увидишь противоречие.
1С — это не ДСЛ. Тут я согласен. Это ЯОН в который встроен ДСЛ для доступа к данныи и который прикручен к визуальному ДСЛ который и дает реальные преимущества. А язык 1С — это не более чем скрипт в этой системе.
Но все тоже самое относится и к любому другому ЯОН который прикручивается к некоторой системе или в которой встраиваются расширения позволяющие упростить решение прикладной задачи.
А ДСЛ — это сужение (что ли) возможностей в неотносящихся к задаче вопросах и нацеливание (специализация) языка на одну конкретную задачу.
Отсюда в 1Э есть несколько ДСЛ, но сам язык 1С не ДСЛ, а ЯОН.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
Написано "может стать", значит для доказательства непротиворечивости я могу привести абстрактный пример.
Пример:
Предположим, фирма 1С ввела обработку сценариев предметной области на уровень языка, скажем таких как: решение не компилируется, если в коде не предусмотрена обработка сущностей "Пользователь:Администратор, Пользователь:Руководитель организации, Хрень:Расчетный счет" (проверяется наличие соответствующих по наименованию справочников и предопределенных элементов).
Если такие сценарии ограничат применение языка некоторым множеством предметных областей, по классификации GP(general purpose)/DSL язык станет DSL, хотя синтаксис мы не меняли.
(Сами разработчики платформы 1С таких зависимостей целенаправленно и тщательно избегали.)
Теперь предположим, конкурент выпустил альтернативную платформу, но использовал тот же базовый синтаксис языка, но не ввел обработку ограничивающих сценариев. То есть это как бы диалект языка, не классифицируемый как DSL. Сущности разделяются, язык в общем, а не его диалекты, скорее всего будет рассматриваться и классифицирован как GP.
Здравствуйте, grosborn, Вы писали:
G>Если такие сценарии ограничат применение языка некоторым множеством предметных областей, по классификации GP(general purpose)/DSL язык станет DSL, хотя синтаксис мы не меняли.
G>(Сами разработчики платформы 1С таких зависимостей целенаправленно и тщательно избегали.)
G>Теперь предположим, конкурент выпустил альтернативную платформу, но использовал тот же базовый синтаксис языка, но не ввел обработку ограничивающих сценариев. То есть это как бы диалект языка, не классифицируемый как DSL. Сущности разделяются, язык в общем, а не его диалекты, скорее всего будет рассматриваться и классифицирован как GP.
Берем листинг на С++ если нет там строки :
int i = 0;
Отказываемся компилироваться !!!!
У нас получился супер приплюснутый DSL. Это для сокращения трудозатрат вместо разработки собственного синтаксиса отрубаются возможности ЯОН? Помоему это не DSL. Максимум чего можно достичь — это заузить использование ЯОН до рамок некоторой прикладной области, но синтаксис будет плохо пригоден для нее. DSL в таком случае может быть только набор макросов написанный на таком приплюснутом ЯОН, а сам ЯОН так и останется ЯОН. Просто в ЯОН всегда останется возможность дописать новый макрос, который явно не подходит выбранной прикладной области, а в случае набора макросов мы как бы говорим — эти и только эти макросы будут нами использоваться. Помоему DSL не должен давать использовать синтаксис не сочетающийся с прикладной областью. Вопрос такой — в какой момент ЯОН превращается в DSL если в него все время добавлять новые и новые ограничения? Думаю что надо считать DSL следующим более сложным механзмом по сравнению с библиотеками. Т.е. всякие макросы и наборы процедур это скорее относится к библиотекам. Имхо проще соотносить DSL с декларативным программирование, листинг задает что должно быть сделано, а в DSL должна быть выполнена работа по выяснению что нужно сделать чтобы получить указанный результат. Правда и в ЯОН это происходит, а вместо листинга можно забацать множество библиотечных вызовов. Вот и моя очередь пришла самому себе противоречить.
), поэтому возможно эту мысль уже кто-то высказал... ИМХО, проблема недопонимания тут в том, что многие путают DSL с DSF (domain specific framework). 1С, VBA, javascript — это ЯОП к прикрученными к ним DSF'ами. Т.е. их предметно-ориентированность определяется именно наличием наглухо встроенных библиотек, объектных моделей и тому подобной радости, не имеющей прямого отношения к этим языкам. Вместо любого из них можно воткнуть произвольный ЯОП и "степень предметно-ориентированности" от этого не изменится, т.к. определяется внешними по отношению к языку средствами.
Любая модель — язык, и при этом модель ни разу не язык 
Ну, вот и представитель этого заблуждения появился.
в зеркало посмотри. Ты отрицаешь очевидное. У тебя возможен язык без синтаксиса. 
и переключаюсь на следующий пост. Ибо для меня это звучит как "огурцы ложкой банка майонеза".
