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

S>По факту — есть.

Неа, нету.

S> То, что он "тот же самый", неверно. Синтаксис — тот же. Семантика — совершенно другая.

Семантика в понимании компиляторостроения — та же. Даже семантический анализатор в компиляторе физически тот же, просто режим немного другой, с ограничениями. Отличается только бекенд.

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

S>Так и было.

Было. Но в итоге все договорились о стандарном языке.

S>И несмотря на это, NoSQL сейчас лезут как грибы после дождя.

При чем тут NoSQL? У них как правило вообще никаких языков запросов нет, только программное API.

S>Так и с DSL — для того, чтобы были единицы мегаудачных языков, должны создаваться (и умирать) тысячи кандидатов.

Аналогия в качестве доказательства логически некорректна.

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


AVK>Семантика в понимании компиляторостроения — та же. Даже семантический анализатор в компиляторе физически тот же, просто режим немного другой, с ограничениями. Отличается только бекенд.
Ну, наш спор зашёл в тупик, т.к. противоречие неразрешимо. Ты считаешь бэкенд несущественным, я — существенным.
Ты считаешь важным то, как работает компилятор, я — получаемый результат. Предлагаю на этом закруглиться, т.к. по остальным пунктам противоречий нет.

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

M>Ну да, из текста, который говорит: из 5к строчек мы получаем 50к сгенеренного кода ты делаешь далеко идущий вывод, что библиотека, существовашая до этого, имела 50 к кода. Ну-ну.
А в чём тут сложность?
Если была библиотека, для работы с которой было достаточно 5к строчек, то зачем потребовался этот DSL?
То есть теория, конечно же, не запрещает нам строить DSL, который будет требовать 50к строчек для замены 5к строчек библиотечных вызовов, но физического смысла в этом нет, и мы предполагаем, что вменяемые проекты таким идиотизмом заниматься не будут.

M>О да, компилятор их нового в старый с сохранением семантики — это, безусловно обязательно очень легкая задача, ага.
Коллеги, почему бы вам не рассмотреть конкретные примеры?
То, что у вас был конкретный баттхёрт, связано с одним из трёх:
1. Недостатки проектирования конкретно вашего DSL
2. Недостатки инструментальных средств, применяемых при построении и изменении вашего DSL
3. Проблемы в самом подходе DSL.
Вы делаете скрытое предположение о №3, оппонент — о №2.
Но я не понимаю, как вы собираетесь выяснить истину, не глядя ни на язык, ни на изменение, ни на инструменты.

M>Доказательств кроме «я, у меня» ты так и не смог предоставить ни одного.
Гм. Он опирается на свои примеры, которые для вашей задачи нерелевантны. А также на расширение множества решений за пределы известных ему примеров, делая неявные предположения, которые считает обоснованными.
Например, что никто в здравом уме не будет писать DSL, который многословнее библиотечных вызовов.
Или что никто в здравом уме не будет писать DSL, который скрывает подробности реализации хуже, чем библиотека.
Затем он усиливает эти утверждения — т.е. применение DSL считается обоснованным там, где удаётся получить значительное преимущество по сравнению с библиотекой по одному или двум из этих параметров.
Дальнейшие рассуждения тривиальны — скажем, если подробности реализации скрыты лучше, то при смене реализации наблюдаемые пертурбации прикладного кода будут иметь меньший масштаб, а стало быть и изменения станут дешевле.

Опять же, ситуация несимметрична: вы видите проблемы, которых не видит ваш коллега. Справедливо одно из двух:
— его кругозор не позволяет ему представить проблемы, которые плохо решаются его подходом
— ваш кругозор не позволяет вам представить решения ваших проблем, которые лишены наблюдаемых вами недостатков.

Вы не сможете выяснить истину, пока не начнёте обсуждать конкретные проблемы конкретных языков.

M>Именно потому, что компилятор выдавал сообщения об ошибке, приходилось перелопачивать все места, где использоввался этот DSL. Мегаумному Вульфхаунду, который никогда не включает дурачка, не приходит в голову, что замена синтаксиса «a PLUS b» на «a + b» в DSLе приведет к тому, что надо будет менять все места, где эта конструкция вызывается?
Ну вот тупому Синклеру совершенно непонятно
а) какие задачи решал синтаксис (a PLUS b)
б) какие были проблемы у этого синтаксиса, которые повлекли за собой его замену на (a + b)
в) почему в качестве замены было выбрано именно (a + b) а не Plus(a, b) и не ещё пятьдесят кандидатов с хорошими родословными
г) в чём была сложность автоматически найти все вхождения (a PLUS b) и заменить их на (a + b) без потери семантики

Без ответов на эти жизненно важные вопросы беседа вынуждена скатываться на пенисометрию вроде "а моя бабушка ещё строже твоей".

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

S>Ну, наш спор зашёл в тупик, т.к. противоречие неразрешимо. Ты считаешь бэкенд несущественным, я — существенным.

Я не считаю бекенд несущественным, я не считаю что замена бекенда создает новый язык. Классический VС++, компилирующий в IL, это все тот же С++, gcc, компилирующий в LLVM, это тоже, по прежнему, С++.

M>>Ну да, из текста, который говорит: из 5к строчек мы получаем 50к сгенеренного кода ты делаешь далеко идущий вывод, что библиотека, существовашая до этого, имела 50 к кода. Ну-ну.
S>А в чём тут сложность?
S>Если была библиотека, для работы с которой было достаточно 5к строчек, то зачем потребовался этот DSL?

Тут (или в презентации) это уже было описано. Все изменения должны были вноситься в код на Эрланге. Не-программеры из отдела Риска хотели вносить изменения сами.

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

Не будут, если заниматься этими проектами будут не люди с мозгом больше, чем у всей компании

M>>О да, компилятор их нового в старый с сохранением семантики — это, безусловно обязательно очень легкая задача, ага.
S>Коллеги, почему бы вам не рассмотреть конкретные примеры?

Я честно пытался

S>То, что у вас был конкретный баттхёрт, связано с одним из трёх:
S>1. Недостатки проектирования конкретно вашего DSL
S>2. Недостатки инструментальных средств, применяемых при построении и изменении вашего DSL
S>3. Проблемы в самом подходе DSL.
S>Вы делаете скрытое предположение о №3, оппонент — о №2.
S>Но я не понимаю, как вы собираетесь выяснить истину, не глядя ни на язык, ни на изменение, ни на инструменты.

Я привел как минимум два примера. Wolfhound предпочитает (уже года два) говорить только и исключительно о светлом будущем.

M>>Доказательств кроме «я, у меня» ты так и не смог предоставить ни одного.
S>Гм. Он опирается на свои примеры, которые для вашей задачи нерелевантны.

Нет, он опирается ровно на два примера. Один — парсер. Второй — библиотека на Java, которая позволила что-то там. Все. После этого человек-«я постоянно занимаюсь написаниями DSLей» неспособен привести ни одного другого примера

Автор: WolfHound
Дата: 04.01.13

на протяжении почти десятка сообщений.

S>А также на расширение множества решений за пределы известных ему примеров, делая неявные предположения, которые считает обоснованными.

Выделенное ключевое. В отсутсвие примеров больших, чем «у меня на компьютере все работает», обоснования считаются странными для любого его оппонента.

S>Например, что никто в здравом уме не будет писать DSL, который многословнее библиотечных вызовов.

Это надо обосновывать, обосновывать, и еще раз обосновывать. Если мы делаем DSL для программистов, возможно. Если для не-программистов, то это далеко не факт.

S>Или что никто в здравом уме не будет писать DSL, который скрывает подробности реализации хуже, чем библиотека.

Про хуже никто и не говорил

S>Затем он усиливает эти утверждения — т.е. применение DSL считается обоснованным там, где удаётся получить значительное преимущество по сравнению с библиотекой по одному или двум из этих параметров.

Про это никто не спорит, если что

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

И про это никто не спорит Спорят с безаппеляционными утверждениями, носящими максимально общий и максимально максимальный (тавтология, ага) характер

S>Опять же, ситуация несимметрична: вы видите проблемы, которых не видит ваш коллега. Справедливо одно из двух:
S>- его кругозор не позволяет ему представить проблемы, которые плохо решаются его подходом
S>- ваш кругозор не позволяет вам представить решения ваших проблем, которые лишены наблюдаемых вами недостатков.

S>Вы не сможете выяснить истину, пока не начнёте обсуждать конкретные проблемы конкретных языков.

Мы пытаемся. Напомнить классическую реакцию Вульфхаунда?

M>>Именно потому, что компилятор выдавал сообщения об ошибке, приходилось перелопачивать все места, где использоввался этот DSL. Мегаумному Вульфхаунду, который никогда не включает дурачка, не приходит в голову, что замена синтаксиса «a PLUS b» на «a + b» в DSLе приведет к тому, что надо будет менять все места, где эта конструкция вызывается?
S>Ну вот тупому Синклеру совершенно непонятно

Что это был пример. Как там? Обоснованно и очевидно, что если меняется синтаксис DSLя, то надо вносить изменения везде, где использовался синтаксис этого DSLя. Разве нет? Тогда в чем ключевое отличие от библиотек? При том, что для большинства языков программирования существуют инструменты, способные быстро и безболезненно сделать это в случае использования библиотек. Что в случае DSL? Ах, да, мы же не конкретные языки обсуждаем, а который год мифический N2 по классическому сценарию.

S>Без ответов на эти жизненно важные вопросы беседа вынуждена скатываться на пенисометрию вроде "а моя бабушка ещё строже твоей".

С этим к Вульфхаунду.

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

M>Как там было в примерах? a.Insert(b) против insert b into a? Каким образом реализован этот самый insert вызывающего не волнует от слова вообще. Где там что путается под ногами неизвестно.
Это неудачный пример. Здесь нет никакого преимущества у DSL, т.к. код остаётся в целом таким же.
DSL начинают рулить там, где не удаётся сделать DRY средствами библиотеки.
Из обсуждавшихся за последние месяцы примеров можно взять INotifyPropertyChanged. "Библиотечная реализация" — вот она, перед глазами:

public string Name
{
    get { return _name; }
    set
    {
        _name = value;
        RaisePropertyChanged("Name");
    }
}

Если я был настолько глуп, что остановился на этом, то маленькое изменение в требованиях через полгода застанет меня врасплох: "надо сообщать только в тех случаях, когда значение меняется".
Что нам делать в библиотеке?
Два варианта: полагаться на клиента, либо изменить сигнатуру:

...
    set
    {
        if (_name != value) // вариант 1. 
        {
          _name = value;
          RaisePropertyChanged("Name");
        }
    }

    set
    {
       RaisePropertyChanged("Name", var _name, value); // вариант 2 - проверка и присвоение уехали в библиотеку.
    }
...

Ну так вот я не знаю средств рефакторинга, способных автоматически отпроцессить весь существующий код в любом из этих вариантов.
А на DSL я бы с самого начала имел

public notifying string Name {get; set;}

И семантика notifying бы менялась лёгким манием руки вообще без переделки клиентов.
Именно об этом говорит WH, когда говорит "из библиотеки торчат подробности реализации".
Даже если мы усложним задачу, типа "у нас есть клиенты, которые заточены на получение всех присваиваний, даже дублирующихся", то в DSL есть богатый выбор — либо ввести синтаксис notifying all, чтобы дать новое поведение по умолчанию всем, либо notifying distinct, чтобы сделать его добровольным.

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

M>Как ты там рядом говорил? Легкая трансформация? Вот мы трансформировали наш SQL на использование window functions вместо linit x,y. ВНЕЗАПНО оказалось, что все у всех перестало работать. А как же сказки о безболезненном изменении DSL

Автор: WolfHound
Дата: 03.01.13

?
Не очень понятно, почему оно должно прямо-таки "перестать работать". Что помешает нам иметь и то и другое сразу? Скажем, MS SQL умеет и TOP и window functions.
Далее, если мы всё же на это решились, то у нас есть парсер, способный построить AST для версии с limit x, y.
И у нас есть несложная формула для трансформации этих деревьев в window functions.
Пишем Visitor, скармливаем его результат в pretty printer, и вуаля! у нас готов конвертер из версии 1 в версию 2.
Для случая библиотеки это будет затруднительно, т.к. вопрос не сводится к простому рефакторингу, а парсера в AST у нас под рукой нету — библиотека опирается на монолитный компилятор.

M>>Как там было в примерах? a.Insert(b) против insert b into a? Каким образом реализован этот самый insert вызывающего не волнует от слова вообще. Где там что путается под ногами неизвестно.
S>Это неудачный пример. Здесь нет никакого преимущества у DSL, т.к. код остаётся в целом таким же.
S>DSL начинают рулить там, где не удаётся сделать DRY средствами библиотеки.

С этим, как бы, никто и не спорит

[skipped чтобы не засорять экран ]

За пример спасибо. Именно такие примеры и просили приводить. Тут я с аргументами, приведенными ниже, согласен.

S>И семантика notifying бы менялась лёгким манием руки вообще без переделки клиентов.
S>Именно об этом говорит WH, когда говорит "из библиотеки торчат подробности реализации".
S>Даже если мы усложним задачу, типа "у нас есть клиенты, которые заточены на получение всех присваиваний, даже дублирующихся", то в DSL есть богатый выбор — либо ввести синтаксис notifying all, чтобы дать новое поведение по умолчанию всем, либо notifying distinct, чтобы сделать его добровольным.

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

S>Далее, если мы всё же на это решились, то у нас есть парсер, способный построить AST для версии с limit x, y.
S>И у нас есть несложная формула для трансформации этих деревьев в window functions.

Практика показывает, что не такая уж она и несложная. Одно обязательное наличие order by во втором случае уже много вопросов ставит.

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

AVK>Практика показывает, что не такая уж она и несложная. Одно обязательное наличие order by во втором случае уже много вопросов ставит.
Ну, не то чтобы много, но ставит. С очевидным ответом — т.к. сами запросы с limit но без order by не имеют внятной семантики, то конвертер имеет право вносить порядок на своё усмотрение.

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

S>С очевидным ответом — т.к. сами запросы с limit но без order by не имеют внятной семантики, то конвертер имеет право вносить порядок на своё усмотрение.

Ну вот это внесение уже не так тривиально. Собственно, по странной случайности я этим в декабре как раз занимался, поэтому точно представляю, что да как.

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

AVK>Ну вот это внесение уже не так тривиально. Собственно, по странной случайности я этим в декабре как раз занимался, поэтому точно представляю, что да как.
Ну, мы же имеем в виду сравнение с вариантом замены "вызовов библиотечного кода".

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

S>Ну, мы же имеем в виду сравнение с вариантом замены "вызовов библиотечного кода".

Это понятно. Только я не вижу в данном случае никакой разницы между DSL и библиотекой. Что изменить реализацию "SKIP 10 TAKE 30" в движке запросов, что поправить обработку .Skip(10).Take(30) в коде провайдера.

Еще небольшой офтоп.

Полагаю , что часто DSL используется вместо данных для программы. Т.е. набирать данные на DSL, хотя оба спосба это архитектурная ошибка. Данные стоит отделять от программы и предоставлять в явном виде.

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

AVK>Это понятно. Только я не вижу в данном случае никакой разницы между DSL и библиотекой. Что изменить реализацию "SKIP 10 TAKE 30" в движке запросов, что поправить обработку .Skip(10).Take(30) в коде провайдера.
Я, наверное, туплю, но я так понял, что речь идёт как раз о том, как сменить представление запроса в связи с пересмотром политики партии.
То есть сравнивается переход от "SKIP 10 TAKE 30" к "where Rownumber() over (order by ID) between 11 and 40" c переходом от ".Skip(10).Take(30)" к ".Where(r => r.RowNumber(r => r.PK) <= 40 && r.RowNumber(r=>r.PK) > 10)"
(Я пишу, понятное дело, из воздуха, т.к. с трудом себе представляю, как эту адскую наркоманию оконных функций представить в виде С#).
Ну и вот первый переход хотя бы примерно понятно, как делать — имея в наличии парсер, разбирающий SKIP 10 TAKE 30 в AST и инфраструктуру по анализу этого AST. А как получить второй на традиционном pre-Roslyn компиляторе, грепе, и решарпере мне непонятно.

А замена реализации при сохранении клиентского представления кода — она, понятное дело, интереса не вызывает, т.к. выглядит одинаково с точностью до второстепенных мелочей.

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

S>То есть сравнивается переход от "SKIP 10 TAKE 30" к "where Rownumber() over (order by ID) between 11 and 40" c переходом от ".Skip(10).Take(30)" к ".Where(r => r.RowNumber(r => r.PK) <= 40 && r.RowNumber(r=>r.PK) > 10)"
S>(Я пишу, понятное дело, из воздуха, т.к. с трудом себе представляю, как эту адскую наркоманию оконных функций представить в виде С#).

Такая постановка малоосмысленна, но и в этом случае, максимум, DSL и библиотека будут эквивалентны. Что более реально — специально заточенные под универсальный язык средства рефакторинга дадут 100 очков вперед сгенерированным средствам для кастомного DSL.

S>Ну и вот первый переход хотя бы примерно понятно, как делать — имея в наличии парсер, разбирающий SKIP 10 TAKE 30 в AST и инфраструктуру по анализу этого AST. А как получить второй на традиционном pre-Roslyn компиляторе, грепе, и решарпере мне непонятно.

Плагин к решарперу, если уж приспичило полностью автоматично это делать.

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

AVK>Плагин к решарперу, если уж приспичило полностью автоматично это делать.

Ну вот разработали мы плагин, а разработчик — возьми да уволься. Теперь никто толком не знает как этот плагин работает и что с ним делать, если глючить начал.

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

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

Z>Ты же понимаешь, что этот плагин будет по сложности сопоставим с DSL.

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

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

AVK>Какая постановка задачи, такой и результат. Это не я предлагал непременно править исходники полностью автоматично. В реальности при изменении в библиотеках один раз проводится рефакторинг в полуавтоматическом режиме. А вот с DSL да, только руками преобразователи выписывать, кроме совсем уж примитивных, которые удасться обобщить на любой DSL.

Предлагалось сравнить рефакторинг изменения синтаксиса в конкретном случае, когда оно действительно нужно. Оказалось, что в случае с библиотекой средств для автоматического тоже нет, а их написание является задачей сравнимой по сложности с созданием DSL.