Здравствуйте, VladD2, Вы писали:

WH>>А раз мы привязываемся к некоторому домену то для любого языка можно придумать домен (а обычно множество доменов) для которых данный язык является языком предельно высокого уровня. Те делай, что хочешь, но язык более высокого уровня не придумать. Ибо язык и так напрямую оперирует терминами предметной области.
VD>Это бессмысленное философствование превращающее в бессмыслицу даже заголовок данной темы.
Это не философствование, а прямое следствие из самого названия Domain-specific language.

VD>Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).
Так у любого языка есть свой домен.
Просто домен некоторых языков не ориентирован на решение конкретной проблемы, а создавался для решения любых проблем. Вот это и есть ЯОН.
Проблема в том, что такие домены плохо подходят для почти всех реальных задач.

VD>Уровень ЯОН не делает из него более ДСЛ для всех задачей.
Чего?

VD>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.
Создание библиотеки не будет бесплатным никогда... и дальше по тексту.

VD>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".
Только если домен задачи хорошо ложится на домен языка.
Если же нет, то получаем от десяти до тысяч раз больше кода, чем необходимо.

Здравствуйте, WolfHound, Вы писали:

WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?

Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.

Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.

И 1Эс-язык не ДСЛ, только от того, что прибит гвоздями к специализированному рантайму и содержит в себе захардкоженый ДСЛ доступа к данным.

Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.

А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.

Здравствуйте, WolfHound, Вы писали:

WH>Это не философствование, а прямое следствие из самого названия Domain-specific language.

Название ни разу не является определением.

VD>>Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).
WH>Так у любого языка есть свой домен.

Ага. Разработка ПО, например. На фиг нужны такие знания?

WH>Просто домен некоторых языков не ориентирован на решение конкретной проблемы, а создавался для решения любых проблем. Вот это и есть ЯОН.
WH>Проблема в том, что такие домены плохо подходят для почти всех реальных задач.

Проблема в том, что ты не понимаешь важности четкого определения терминов. Философия ни разу не помогла объяснить людям что-то. Она только путает.

В твоем определение термин ДСЛ (ПОЯ) не имеет никаого смысла, так как разные люди под ним будут понимать разные вещи.

Между ВБА и регексами общего только то, что они оба языки.

VD>>Уровень ЯОН не делает из него более ДСЛ для всех задачей.
WH>Чего?

Того. ДСЛ для арифметики — это строчный калькулятор, а не С++. А язык на котором можно отформатировать винт ни фига не ДСЛ. Он в любой задаче будет скорее вреден.

Ты пришел объяснять пользу ДСЛ-ей народу, но сам же не можешь объяснить ему, что же такое ДСЛ.

Лично для меня очевидно, что ДСЛ дающий делать больше чем нужно для решения задачи предметной области — это как минимум плохой ДСЛ. А скорее всего не ДСЛ.

Польза ДСЛ в декларативности описания. Меньше кода, меньше ошибок, больше метаинформации. Польза же от ВБА == нулю. На его месте может быть и C#, и Ява и даже С++. Это ровным счетом ничего не меняет. А раз так, то называя ВБА ДСЛ-ем мы дескредитируем саму идею использования ДСЛ-ей.

VD>>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.
WH>Создание библиотеки не будет бесплатным никогда... и дальше по тексту.

Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.
Зачем вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?

Смысл в ДСЛ-е появляется тогда, когда библиотечная функция:
* Не может выразить решение задачи без копипасты и кучи ручного кодирования.
* Приводит к более медленному решению.
* Выливается в эмуляцию ДСЛ-я средствами ЯОН.

В остальных случаях я сам выберу функцию, так как на нее банально уйдет меньше времени.


VD>>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".

WH>Только если домен задачи хорошо ложится на домен языка.
WH>Если же нет, то получаем от десяти до тысяч раз больше кода, чем необходимо.

Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.

А вот ДСЛ может быть нежелателен хотя бы потому, что время затраченное на него больше лобового решения. Или его тупо сложно выделить.

В жизни вообще нет места ультра-максимализму. Любое решение — это компромисс (ваш КО). Выбор ДСЛ-я тоже.

Здравствуйте, Vain, Вы писали:
V>Речь то как раз про удобные и несложные средства. SQL на них не тянет, т.к. является таким же тяжёлым языком как языки общего назначения.
Не понимаю, откуда такой вывод. SQL является удобным и несложным средством описания сложных операций с данными. Если все ваши операции с данными — это локальные load и save, то SQL вам не нужен.
А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.

Здравствуйте, alex_public, Вы писали:

_>Что-то это какой-то уход в мелкие детали. Я бы начал с простой общей вещи. Что в нашем языке есть какое-то отображение понятика контрол — в какой-то объект языка. И эти объекты мы в языке можем создавать и потом вызывать их функции. И отдельно можем вызывать функции "системного" языка. В принципе уже только это позволило бы убрать практически весь код связанный с интерфейсом в наш dsl, оставив системному языку только "движок".
Непонятно. На каком языке написаны "функции контролов", и чем он отличается от системного языка?

Здравствуйте, alex_public, Вы писали:

_>Ммм, ну да, должен признать что регулярно вижу диффы этих файлов в Mercurial и по ним даже можно понять что поменяли люди. Но я как-то никогда не воспринимал это как существенное преимущество. ) И слияние на таком файле автоматике старались никогда не доверять. )))
Представьте, что ваша идея заменить сериализацию в файл на сериализацию в SQLite-базу была реализована. С точки зрения редактора не поменялось ничего. С точки зрения меркуриала — это бинарь, который изменился непонятным образом.
Далее, ваше недоверие автоматике возможно говорит о проблемах типа Rational Rose, т.е. формат является малочитаемым, и результат слияния, предложенный тулом, надо править руками.

_>Ммм, ну это скорее задано самим фреймворком, под который генерируется код, а не авторами редактора.
Я не видел ваш редактор. Но во всех, которые я видел, синтаксис по факту присутствует.
_>Вообще к чему это всё я говорю. Вот я смотрю на этот редактор и в общем не вижу никаких проблем написать самому такой же вообще практические не думая. Т.е. тупо "закодить". А вот если бы я захотел придумать некий язык, по которому потом генерировался тот же код, то я бы с самого начала начал задумываться над всякими нюансами. Причём не обязательно какими-то "высоконаучными", а возможно просто стилевыми. Например использовать мне в моём dsl {} или begin/end? Я не говорю что это что-то дико сложное, но всё же время отнимает. А в случае с редактором ничего такого нет — тупо закодить визуальный редактор плюс набор шаблонов кода под контролы.
Я думаю, это оттого, что у вас визуальный редактор с некоторым синтаксисом уже перед глазами. Выбрав, скажем, в качестве синтаксиса языка JSON, тоже можно "тупо закодить" и ни о чём не думать.

Здравствуйте, Sinclair, Вы писали:

S>Непонятно. На каком языке написаны "функции контролов", и чем он отличается от системного языка?

Функции контролов (типа показать/скрыть окно и т.п.), как и сам набор базовых контролов "даны в язык богом", но их можно расширять из системного языка. Всё это для того, что бы как писал Влад сократить возможности и упростить. Причём упростить до такого уровня, что бы оно нормально интегрировалось в язык размётки.

Попробую привести совсем упрощённый пример идеи. В стилистике Питона:

form Main
    title "Main"
    button Calc
        title "Calc"
        onclick [Calculate]
    button About
        title "About"
        onclick About.ModalShow
form About
    title "About"
    button OK
        title "OK"
        onclick this.Close

Это у нас будет файла нашего dsl. Компилируем его допустим в C++ h файл. И потом у нас останется написать реализацию функции Main::Calculate() на C++ в cpp файле и собрать итоговую программу.

P.S. Всё это придумал буквально 10 минут назад и вообще dsl строение не специалист, так что сильно не ругаете пример — это просто попытка подумать в сторону удобного gui dsl, отделяющего интерфейс программы от "движка".

Здравствуйте, Sinclair, Вы писали:

S>Я думаю, это оттого, что у вас визуальный редактор с некоторым синтаксисом уже перед глазами. Выбрав, скажем, в качестве синтаксиса языка JSON, тоже можно "тупо закодить" и ни о чём не думать.

Да, если в качестве языка своего dsl подходит какое-то подмножество готового продуманного языка, то действительно уже можно просто "закодить". ) Но что-то мне кажется это далеко не всегда так.

Здравствуйте, WolfHound, Вы писали:

WH>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.
WH>И в институтах этому не учат.

Вообще-то учат, как минимум на специальностях 2201 и 2202.

WH>И вообще распространяют миф, что это что-то очень сложное.

Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.

WH>А почему программы плохо проектируют?
WH>В данном случае неверные требования (чтобы любая кухарка писать могла) и недостаток знаний.

ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью. И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.


WH>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.

Знания тут не при чем. Это такой популярный алгоритм независимо от кол-ва знаний. Действительно, тенденция сравнивать, проверять, расчитывать и т.д. за последние лет 15 куда-то ушла. Не модно. Потому что "мощщи компов все проглотят" и прочая ересь, идущая с сегмента заказухи... которой постепенно заражалась вся индустрия.

ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия... Уже пошел процесс очищения "общественного мнения" от всей этой шелухи.


WH>>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД?
G>>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
WH>И это человек обвиняет меня в уходе от вопросов.

Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.

WH>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.
WH>Вперед. Покажи, как паттерны решат эту задачу.

Там точно DSL нужен, а не таблицы составляющих и коэффициентов?


WH>Критерий реальности в студию.

Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.

Здравствуйте, Gaperton, Вы писали:

G>Да нет никаких проблем. Вот, например, уже как более чем 10 лет как есть отличный DSL под названием "1С: Предприятие".

Почти 20.
Встроенный язык для проводок и отчетов появился в 5-ке.

Здравствуйте, WolfHound, Вы писали:

G>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.
WH>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.

Доступ к экземплярам прикладных сущностей, к регистрам, к временн`ым значениям и т.д. Вполне предметно-ориентировано.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.

Какие еще классы и пакеты? Тебя синтаксис языка в заблуждение ввел, похоже.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>При этом в основной массе, когда описывают что такое внутренний DSL, отдельно отмечают, что Word+VB это не DSL для обрабтки документов, а скриптовый язык.

Обычно хост скрипта поставляет в его систему глобально-доступные типы и ф-ии. Т.е. если сам язык не умеет создавать/подключать готовые модули и нет встроенных ср-в ввода/вывода, то вот тебе классический императивный-DSL. ИМХО, наличие операторов присваивания, арифметических операторов и способа объявления и вызова ф-ий не делает некий скриптовый язык языком общего назначения без существования в нем встроенных ср-в, позволяющих решать на нем те самые задачи общего назначения. Т.е. он может стать языком общего назначения, только если хост ему предоставит всю необходимую функциональность.

Здравствуйте, VladD2, Вы писали:

N>>Некоторые тезисы к обсуждению...

VD>Буду краток — полный бред.

В общем случае оно и не должно было быть не-бредом, потому что тезисы к обсуждению не должны быть истинными или даже адекватными. Они должны стать отправной точкой для дискуссии, и рассчитаны на то, чтобы получить конструктивный результат, даже если все они будут опровергнуты.

Но, с другой стороны, я не соглашусь с твоей оценкой их как бреда.

VD> Подменил понятие "ДСЛ" на понятие "Уровень языка", и выстроил на этом стройную, но бессмысленную картину.

Конечно, написать вместо трёх страниц три предложения — это архикруто. Странно, что ты их ещё не строишь в стиле WolfHound'а.
Мне бы хотелось увидеть критику попунктно и по существу. Пока что я не увидел ни одного опровержения тезису, что в формировании DSL ограничения не менее важны, чем упрощения и адаптации. Более того, они являются одним и тем же, и это ты тоже не опроверг.

И ты, очевидно, не заметил, что "уровень языка" здесь являлся только временным синонимом для визуализации связи с уже известными понятиями, но никак не первичным понятием.

VD> Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума.

Нет, только двоих общеизвестных участников.

VD> Синклер такой прям рьяный немерлист .

Я не вижу принципиально общего между позицией тебя и WH с одной стороны, и Синклера с другой. По-моему, они заметно различны. Докажи, если считаешь иначе.

VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.

VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.

Это уже раскритиковали, могу только согласиться с твоими оппонентами.

Здравствуйте, gandjustas, Вы писали:


AVK>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.
G>Тогда давай формализуем понятие мощности.

Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.

G>Если мы рассматриваем мощность как выразительную силу языка, то есть возможности выразить некоторые вычисления наименьшим количеством конструкций этого самого языка, то очевидно что в менее мощном языке надо больше писать для достижения того же результата.

Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач. Но это только первая их роль, на которую могут тянуть даже eDSL. Вторая роль DSL — это заведомое ограничение языка для ограничения класса решаемых задач, чтобы многократно уменьшить поле для ошибок. Здесь eDSL уже не катят.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


AVK>>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.
G>>Тогда давай формализуем понятие мощности.

V>Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.

Это мощность парсера. А еще семантика этих цепочек есть.

G>>Если мы рассматриваем мощность как выразительную силу языка, то есть возможности выразить некоторые вычисления наименьшим количеством конструкций этого самого языка, то очевидно что в менее мощном языке надо больше писать для достижения того же результата.

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

Здравствуйте, vdimas, Вы писали:

V>Обычно хост скрипта поставляет в его систему глобально-доступные типы и ф-ии. Т.е. если сам язык не умеет создавать/подключать готовые модули и нет встроенных ср-в ввода/вывода, то вот тебе классический императивный-DSL. ИМХО, наличие операторов присваивания, арифметических операторов и способа объявления и вызова ф-ий не делает некий скриптовый язык языком общего назначения без существования в нем встроенных ср-в, позволяющих решать на нем те самые задачи общего назначения. Т.е. он может стать языком общего назначения, только если хост ему предоставит всю необходимую функциональность.

Тот же Word+VB умеет работать с COM. Чем это отличается от С с библиотеками? А то получается, что С без библиотек это DSL, а с — нет.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.

V>Какие еще классы и пакеты?

Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL. Отдельное подмножество встроенных классов и методов можно считать внутренним DSL.

V>Тебя синтаксис языка в заблуждение ввел, похоже.

DSL нужен человеку -> вся суть DSL в синтаксисе (а если не вся, то 80% точно, т.е. таки вся).

Здравствуйте, Sinclair, Вы писали:

S>Ну, во-первых, вы правы. При разработке SQL вопросы повторного использования не рассматривались почти что никак. Поэтому в нём, в частности, нет функций высшего порядка. Да и вообще функций, аргументом которых являлось бы relation, нет.

Но там есть подзапросы. Остальное, имхо

Автор: Andrei N.Sobchuck
Дата: 24.01.08

, это просто синтаксический сахар.

Здравствуйте, gandjustas, Вы писали:

G>Решает задачи не только учета, а потенциально любые.

Угу, любой язык, который содержит арифметические выражения и условные операторы решает потенциально любые задачи.
Нормальный такой способ спорить через неоспоримые банальности.