Здравствуйте, gandjustas, Вы писали:
G>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.
От того, что кто-то замкнул SQL до тьюринг-полноты, он (jIMHO, конечно) не теряет свои основные подходы и применения именно как описатель запросов и соответственно остаётся DSLем именно для этой цели.
Думаю, основной из моментов, за который тут зацепились спорщики, должен быть как раз в чёткой формулировке метода отделения прямых методов применения от непрямых, основанных на тёмных углах, пристроенных сбоку возможностях и дополнительных слоях абстракций.
Здравствуйте, VladD2, Вы писали:
VD>Тут проблема в тремине "тьюринг полнота". Сама по себе она еще не дает возможности присать полезные программы. Вот на VBA можно прочесть файл и вывести данные на любое устройство. А на SQL или на шаблонах С++ нельзя. Хотя оба вроде как теоретически полны по тьюрингу.
VD>Для данного вопроса важно, что язык общего назначения позволяет решать произвольную задачу. В то время как ДСЛ только конкретную.
VD>Иначе в этом делении нет никакого смысла и все языки программирования становятся ДСЛ-ями. Ведь в какой-то мере все языки заточны на что-то.
Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области.
Т.е. если на DSL для вычисления факториала приходится пользоваться терминами той предметной области, под которую он заточен (и вычисление факториала на порядки менее высокоуровнево, чем решение задачи из своей области), то это DSL. Даже если задачу из родной области решить проще на Nemerle.
Т.о. главное — нацеленность на одну область.
В этом смысле хоть на SQL и можно факториал посчитать, но это куда сложнее, чем то, для чего SQL предназначен.
Грань, правда, опять не провести, поэтому видимо придётся DSL-изм переименовать в DSL-альность
VE>>По-моему, SQL тут просто ярчайший пример того, что твоё определение несостоятельно. Потому что грань "через зад"/"не через зад" провести ты не сможешь.
VD>Да элементарно она проводится. Если для достиженя целей в языке нужно использовать некоторые побочные эффекты, то это через зад. Скажем, если для организации цикла/рекурсии мне нужно использовать хитроумную хрень которая исходно была предназначена для организации древесных запросов, или нужно описывать структуры данных, то это через зад.
Это не чёткая грань, а некоторая мера. В целом, согласен.
И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Хвост, Вы писали: VD>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!
В начале хотел прокомментировать что в таком простом случае я бы взял Boost.Spirit, указал бы грамматику в несколько строк и тут же получил бы очень быстрый парсер.
Но потом подумал... А ведь Boost.Spirit — это же на самом деле тоже разновидность DSL!
Кстати, глянул только что в гугле: не мне одному такая мысль сразу в голову пришла — уже есть готовое такое http://boost-spirit.com/repository/applications/json_spirit.zip
VD>Проверим, так сказать, на практике и циферки, и твои сомнения. Если ты прав, то без труда запихаешь все в библиотеку, кода у тебя будет хотя бы столько же как в вариенте PegGrammar-а. Ну, и скоростью похвастаешься. Хэнд-мэйд все таки.
Интересно, а что можно было бы использовать при разработке такого парсера, что бы не считалось что используем DSL какой-то? Регулярные выражения? Не, тоже dsl... Остаётся только в лоб реализовать разбор посимвольный, в виде какого-нибудь конечного автомата. Я бы не стал.
Здравствуйте, WolfHound, Вы писали:
V>>Это вы программистов на C/C++/java и т.д. как как щас назвали? WH>Это я к тому что аппеляция к большенству примитивная демагогия.
Аппеляция к инструменту, который уже написан, и на который затрачено куча времени и сил, тоже демагогия.
WH>>>Обычно намного проще чем библиотеку которой его пытаются заменить. V>>Это спорное утверждение. WH>Ну, давай изучи АПИ для прямых обращений к физической структуре БД. WH>Удачи.
Ну а ты давай сделай SQL с нуля, сам язык, теорию, и поддерживай это всё.
Он толсто намекает на то, что DSL написать — не поле перейти, и очень нередко написать "свой SQL" может оказаться сложнее, чем таки поработать через АПИ.
Только ты ему одну крайность кидаешь в качестве аргумента, а он тебе другую. Точнее говоря, ты опираешься на крайность (берёшь один из самых вырожденных случаев DSL) в качестве доказательства того, что DSL оправданы всегда, а это не так.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VoidEx, Вы писали:
VE>>Поэтому есть потребность занять даже клинических идиотов, лишь бы приносило прибыль.
VD>1. Клинические идиоты скорее всего принисут один убыток. VD>2. Прибыть можно получать тупо уменьшив количество занятых в разработке программистов, ведь основные затраты на разработку ПО — это заработная плата. VD>3. Людям с ограниченными умственными способностями куда безопаснее и эффективнее давать DSL-и или визуальные дизайнеры. Это позволяет их лучше контролировать и снизить на них нагрузку.
VE>>Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.
VD>DSL-подход позволяет задействовать башковитых людей при разработке DSL-ей, а тех что по тупее в качестве пользователей DSL-ей.
Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.
Здравствуйте, VladD2, Вы писали:
VD>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!
Мало что ли парсер-генераторов?
VD>Проверим, так сказать, на практике и циферки, и твои сомнения. Если ты прав, то без труда запихаешь все в библиотеку, кода у тебя будет хотя бы столько же как в вариенте PegGrammar-а. Ну, и скоростью похвастаешься. Хэнд-мэйд все таки.
Ну когда не хватает библиотеки, можно и кодогенератор. Зачем всё в один исходник пытаться запихнуть под эгидой Универсального ДСЛ Конструктора?
Здравствуйте, VladD2, Вы писали:
VD>Это из той же серии что и "Нахрена лифты, когда есть лестницы?", "Нахреа роторные экскаваторы, когда есть лопаты?", "Нахрена компьютеры, когда есть счеты?"... И, главное, обоснование можно то же использовать — нахрена вифтеры, эксковаторщики, программисты, когда есть специалисты "общего назначения" у которых есть ноги, руки и голова которые отлично справляются с хождением по лестницам, рытьем лопатой и щелканье костяшками?
Не совсем так. Лифты в одном месте, роторные экскаваторы в другом, компьютеры в третьем. А вот нахрена это всё собирать в одном, действительно не очень понятно.
Здравствуйте, VladD2, Вы писали:
VD>Визуальный редактор не всегда генеирирует код на ЯОН. Скажем тот же МС помучившись с генерацией и интерпретацией ЯОН-ов в ВинФормсах выбрала DSL основанный на XML в WCF. И сделано это было не потому что в МС ополоумили. Просто с генерацией ЯОН (и тем более с их чтением) были серьезные проблемы. А уж о рантайм-генерации и думать было сложно. На серевере это еще прокатывает (АСП.НЕТ), но на клиенте слишком много сложностей.
В том редакторе, что мы используем, данные хранятся в каком-то своём диком формате. Так что задача парсинга системного языка вообще не стоит.
И мне не кажется что данная задача чем-то сложная. В данном случае решение MS мне не кажется правильным, но абсолютно не удивляет — оно же укладывается в их давнюю традицию. Те же rc файлы в прошлом и т.п. Т.е. это их давняя стратегия. А стратегии с кодогенерацией я у них вообще не помню — это традиции других.
VD>Кроме того в тех же ВинФормсах поддержка генерации ЯОН не полная. По сути поддерживается только подвид ЯОН-ов воспроизводящий нужную функциоальность. И при этом не делается многих проверок. Так что сгенерированный код может вполне оказаться не компилируемым. Сложность добавления поддержки нового языка тоже вилика. К тому же F#-у дизайнер винформсов так и не прикрутили (не смотря на ресурсы и знания МС).
Хыхы, а тот наш редактор как раз генерит код сразу на нескольких языках. )))
VD>Как раз лучше полноценный ДСЛ. Но по бедности создание ДСЛ-ей выливается в слишком большой геморрой. Генерация тоже выливается в геморрой. По этому народ чаще всего тупо плюет на эти подходы и долбит все руками (набирая тучу индокодеров). И только при частом изменении модели (см. выше) отдельные личности приходят к ДСЛ-ям/генерации кода по модели.
Я в какой-то степени про это и говорю. Продумывание синтаксиса нового языка — это всё же определённая задача, которую не профи (в dsl строение) не так уж и просто решить. А вот такие инструменты по сути выполняют роль DSL, но при этом их создатели вообще не тратили время на продумывание синтаксиса и т.п.
Здравствуйте, VladD2, Вы писали:
VE>>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.
VD>Остается только понять почему VoidEx периодически троллит нас исповедуя, казалось бы, те же истины.
Это метод получения информации в спорах. Поэтому я почти всегда занимаю противоположную точку зрения, а свою высказываю редко. Когда я вырабатываю для себя чёткую позицию, я теряю интерес к спору.
from num in numbers
where num % 2 == 0
orderby num
select num;
а вот здесь надо "лишь посмотреть на внешний интерфейс"
numbers.Where(num => num % 2 == 0).OrderBy(n => n);
VE>>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.
___>Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.
Внешний интерфейс и есть язык. Язык библиотеки. Он оперирует не объектами и методами, а терминами самой библиотеки. И вот это и надо изучать. А уж как там будет написано:
SomeObject x = new SomeObject(new RangeStep(10, 20, 3));
SomeBlabla y = Foo.Register(x, "y", "trololo");
или
y as trololo from 10 to 20 step 4
большого значения не имеет. Разве что второе проще читать и понимать, ибо первое загажено всякими языковыми деталями.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот что в тестах, к примеру, валяется:
Удалено избыточное цитирование.
AVK>В сиквел в итоге отдаеться такое:
Удалено избыточное цитирование.
Это аналог и 1С 8 го запроса (прада там еще и подмена названия полей). Правда в 1С бесит, что нет вывода типа для запросов и соответствующей подсказки. В Linq to EF тоже вроде такого плана можно строить запросы по ассоциациям. Правда могу ошибаться. Но и там нет автоматического вывода типа для результата запроса.
Кстати, что там нового для Linq to EF хотят сделать? Начал трансформировать файл edmx для "человеческого" воспиятия названия полей и ассоциаций (да и бороться без foreign key,а кое где и primary key). Сейчас обхожусь генераторами для прямых запросов, но было бы проще работать как через Linq to EF так и запросами аля 1С через измененные ScalarProperty Name. Есть возможность генерировать edmx через какой нибудь апи не трансформируя *.edmx?
и солнце б утром не вставало, когда бы не было меня
Ну это аналогично трансформации 1С 8 ки. Правда бесит, что нет вывода типа результата запроса.
Часто приходится делать прямые запросы для апдейтов больших по объему данных, через генераторы запросов. Поэтому, мой взгляд упал на Linq to EF. Там мне понравилось, что можно использовать запросы по схеме. Правда опять же нет вывода типов (может сейчас что изменилось).Там можно переименовать свойства и ассоциации в файле .edmx. Началь делать, да что то времени не хватает да и желания. Да и в модели 1С для регистров нет первичных полей, а для ассоциаций вторичных.
Я выбрал путь через трансформацию EDMX, но может проще сделать EDMX через какой то АПИ, так по сути я могу создать и из 1С т.к. название полей и ассоциаций имеется?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Тут же речь идет именно о разнице между использованием ДСЛ-я и ручном кодировании того же самого.
А по каким критериям ты относишь то или иное API к ДСЛ и к "ручному кодированию"? Если мы напишем класс, название которого соответствует некоторой доменной сущности, а методы соответствуют доменным операциям, то код, написанные с использованием этого класса является DSL? Скорее всего ты ответишь нет, но почему тогда Criteria API из hibernate является DSL?
Некоторые тезисы к обсуждению. Формулировки в заметной мере откорректированы с учётом уже сказанного в теме, как и вообще необходимость подобного постинга, хотя всё то же самое можно было сказать отдельно и независимо.
1. Каждый язык более высокого уровня является DSL, если сравнивать с языком более низкого уровня, с которым его можно напрямую соотнести.
Язык команд x86 является DSL по сравнению с языком микрокоманд конкретного Core Duo или Sandy Bridge. Доменом является переносимая система команд x86.
Язык C является DSL по сравнению с языком команд конкретных x86, ARM или любого другого процессора.
Доменом является виртуальная модель среды исполнения C, со всеми её ограничениями (например, не может быть двух разных входов в функцию или неопределённых аргументов).
Язык со сборкой мусора является DSL по сравнению с языком с ручным управлением памятью. Доменом является среда с гарантированной защитой от проблем ручного управления памятью и открытых указателей.
Декларативный язык является DSL по сравнению с процедурным языком. Доменом является поддержка описания зависимостей, условий и требований вместо ручного вычисления метода исполнения. Это в равной мере справедливо, например, для SQL и для Makefile.
2. Введение DSL, он же язык более высокого уровня, вызывается конкретным преимуществом его введения.
Типичными преимуществами являются:
Независимость от особенностей реализации (как переносимость системы команд, написания на C или доступные индексы для СУБД).
Устранение "геморроя", сиречь неприятных накладных расходов на реализацию. Характерный пример — ручное управление памятью.
Необходимость вывести определённые сущности из ментального поля автора реализации. Уже работа с указателями доступна не всем программистам, а учитывать сочетаемость акций в АЛУ конкретной модели сможет десяток человек по всему миру.
В заголовке этого пункта сделано отождествление DSL и языка высокого уровня (высота этого уровня относительна), что является натяжкой по сравнению с утверждавшимся в пункте 1. Это может показаться чрезмерным, но подождите до конца изложения.
3. DSL, он же язык более высокого уровня, имеет заметные недостатки по сравнению со своей альтернативой.
Написание в системе команд x86 требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом, когда все распределения действий максимально эффективно рассчитаны для конкретной модели процессора.
Написание на C требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом. (Чтобы в этом убедиться, достаточно поговорить с любым энтузиастом ассемблера.)
Написание на языке с автоматическим управлением памятью выливается в общеизвестные недостатки в виде непредсказуемого времени жизни и неравномерной производительности.
Кто-то сейчас скажет, что у него всё это заглажено; верю. Как и с любым другим конкретным примером здесь, важны не средние случаи, а крайние. Кроме того, сказано "заметные недостатки", а не "существенные".
4. Тем не менее, использование правильного DSL, он же язык более высокого уровня, предоставляет использующему заметные преимущества по сравнению с его неиспользованием.
Это не повторение пункта 2, потому что в пункте 2 утверждалось наличие преимущества без оценки его важности, а в данном уже рассматривается то, насколько он существенен с учётом и недостатков.
Пример с прямой работой с внутренностями процессора был бы самым показательным, потому что маргинальность такой работы ясна каждому. Именно поэтому он мне не нравится. SQL интереснее: каждый может в своём воображении залезть внутрь базы и напрямую поработать с таблицей, но большинство понимает, почему этого не следует делать. (Может, это вообще не таблица.) Интересен также случай с make, или с тем странным зверем по ссылке WolfHound'а, который по сути — супернавороченный make. Можно писать зависимости напрямую, но лучше воспользоваться для этого явным языком и оставить вычисление среде исполнения.
5. Понятие высокоуровневого языка программирования, сложившееся исторически и в основном разработанное в 1960-х годах, означает DSL.
Это не абсолютный принцип; есть заметные исключения в виде языков, которые позволяют делать почти всё, но при этом считаются высокоуровневыми из-за необходимости описать все детали и последствия. И именно они по факту малопопулярны и держатся только в особых средах. Примеры — Паскаль, который остался почти только в обучении, и Ada, которая держится только на стандартах военных заказчиков. Я не утверждаю, что они именно поэтому малопопулярны; этот вопрос требует отдельного изучения.
В основной же части отрасли высокий уровень определён обструктивно, то есть опре
деляется запретом, а не утверждением. Аналогично тому, как воспитание есть больше правила, что *не* делать, чем то, что делать, высокий уровень — это обещание безопасности (не в смысле посторонних вторжений, а в смысле реализации только того, что требуется) за счёт отказа от возможностей. См. пункт 3.
6. И наоборот, DSL в современном понимании неявно подразумевает отказ от возможностей, даже если это явно не формулируется.
Даже если какой-то DSL сделан тьюринг-полным за счёт возможности включить произвольные исполняемые участки кода, это не означает возможность делать что угодно в этом коде; сохраняется общая логика той среды, под которую рассчитан этот DSL. Например, код может быть вызван только по определённому действию пользователя. Многие DSL намеренно не предоставляют таких широких возможностей.
Ограничения являются и неизбежной, и необходимой оборотной стороной того преимущества, которое даёт конкретный DSL.
7. Языки более общего назначения (более низкоуровневые), несмотря на заголовок темы, имеют смысл.
Они имеют смысл, во-первых, потому, что на чём-то надо реализовать этот DSL. Этот фактор очевиден, но его не следует упускать в данной дискуссии.
Они имеют смысл, во-вторых, потому, что DSL всегда ограничен, а задачи — нет. Чем более низок уровень языка, тем меньше его надо менять под задачу.
8. Радикальные примеры показывают радикальные случаи, но не годятся для доказательства в общем.
Пример в стартовом письме данной темы является как раз таким радикальным случаем. Столько страстей, сколько в среднем фильме, вы можете не получить за всю жизнь, и такое же правило применимо и к программированию. Прорыв в 19 строк вместо ~4000 — дастся не каждому.
9. Введение DSL имеет смысл, если он упрощает реализацию не только текущей задачи, но и будущих задач.
10. Всё изложенное здесь нестрого и в принципе не может быть строгим.
Это связано с тем, что программирование в принципе не является строго формализуемой деятельностью.
Но это не значит, что не может быть чётких и однозначных случаев, которые можно классифицировать и сравнить в соответствии с изложенным выше. (Хотя их мало.)
11. Основная часть споров, происходящих здесь — это конфликты опыта и эмоций в недостаточно однозначных случаях.
Поэтому я не хотел вступать в тяжёлые дискуссии, которые тут заведомо неконструктивны.
Можно заметить, что процентов 90 споров ведётся между немерлистами и прочими, на тему того, насколько просто можно писать DSL.
Но синтаксис не является проблемой.
В конце концов, всегда можно откатиться на XML/JSON/etc., не к ночи будь сказано
Проблема — что именно в нём должно быть и чего не должно быть. А вот тут сложность фактически совпадает со сложностью придумывания нового языка программирования, и последствия те же — 99% этих языков гибнут не получив популярность.
В случае DSL обстановка чуть более тепличная. Угадать потребности проще, давление рынка и вкусовщины на сам язык слабее.
И это то, что никак не может быть решено никакими столь рекламируемыми здесь новшествами из N2.
Они дадут только облегчение разборки с синтаксисом. Семантику они не решат.
И именно поэтому описанное противостояние нелепо.
Здравствуйте, VoidEx, Вы писали:
VE>Грань, правда, опять не провести, поэтому видимо придётся DSL-изм переименовать в DSL-альность
Грань размывается и в этом все и дело. Истинный ДСЛ и в понимании ЯОН заточенный тем или иным образом под задачу — это разные вещи. У них разные свойства.
Более того языки вроде 1Эс заточены за счет внедрения в них ДСЛ-ей. Это переворачивает все с ног наголову и не дает полноценно рассуждать о ДСЛ-ях.
Языки же вроде ВБА вообще не имеют никакой заточи и отличаются только рантаймом привязанным к МС Офис. Почему ВБА — это ДСЛ, а Ява встроенная в Опен Офис не ДСЛ?
VD>>Да элементарно она проводится. Если для достиженя целей в языке нужно использовать некоторые побочные эффекты, то это через зад. Скажем, если для организации цикла/рекурсии мне нужно использовать хитроумную хрень которая исходно была предназначена для организации древесных запросов, или нужно описывать структуры данных, то это через зад.
VE>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.
Если признать что ДСЛ — это мера, то нужно искать новые термины для выражения того же самого.
Если же признать, что 1Эс и ВБА — это не ДСЛ, то все становится куда проще. За одно стаовится понятно, что 1Эс — это ЯОН в который гвоздями прибит ДСЛ. А как только это становится понятно, и программисту становится известно о наличии Немерла и Лиспа, то становится понятно и то, что такое решение не более чем ошибка дизайна. Ведь ДСЛ может быть прост библиотекой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>В начале хотел прокомментировать что в таком простом случае я бы взял Boost.Spirit, указал бы грамматику в несколько строк и тут же получил бы очень быстрый парсер.
Да было бы смешно прочесть такой комментарий .
_>Но потом подумал... А ведь Boost.Spirit — это же на самом деле тоже разновидность DSL!
Именно. С кучей проблем, созданный на побочных эффектах, но полноценный ДСЛ. И именно по этому на нем можно решить конкретную задачу создания парсера написав существенно меньше строк кода нежели при решении задачи в лоб на С++.
_>Кстати, глянул только что в гугле: не мне одному такая мысль сразу в голову пришла — уже есть готовое такое http://boost-spirit.com/repository/applications/json_spirit.zip
Ежу понятно. Но сравнивать решение на Спирите с другим ДСЛем в нашем случае не особ интересно. Мы только узнаем то что и так очевидно — на немерле ДСЛ-и получаются лучше.
Интересно сравнить именно реализацию средствами ЯОН и на ДСЛ-е.
VD>>Проверим, так сказать, на практике и циферки, и твои сомнения. Если ты прав, то без труда запихаешь все в библиотеку, кода у тебя будет хотя бы столько же как в вариенте PegGrammar-а. Ну, и скоростью похвастаешься. Хэнд-мэйд все таки.
_>Интересно, а что можно было бы использовать при разработке такого парсера, что бы не считалось что используем DSL какой-то? Регулярные выражения? Не, тоже dsl... Остаётся только в лоб реализовать разбор посимвольный, в виде какого-нибудь конечного автомата. Я бы не стал.
Классическим решением для написания парсеров является использование метода рекурсивного спуска. Для каждого правила грамматики пишется по фукнции. Проблема в том, что этот метод хорошо разбирает только LL-грамматики. Но джейсон как раз относится к таковой (вроде бы).
_>P.S. Boost.Spirit очень быстрый. )
Рвали мы его как тузик грешку .
В нем не эффективные алогоритмы. Как только горамматика выходит за LL(1) производительность парсера резко падает. Вплоть до экспоненты.
Но в любом случае его скорость в простых случаях обусловлена (в немалой мере) тем, что он использует генерацию кода по модели.
ДСЛ позволяет не только сделать описание коротким и понятным, но и (при наличии должных средств трансформации/генерации) кода генерировать весьма эффективный код.
Подход Немерла и N2 позволяет куда больше чем С++-ное метапрограммирование на шаблонах (использованное в бусте). Потому позволяет добиться лучшей скорости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.
Ты и сам знаешь что это не так. В библиотеки нельзя запихать все. Библиотеки не позволяют всегда получать эффективнй код. Ну, и конечно же, многие библиотеки — это ДСЛ-и облаченные в не очень красивую форму и имеющий не очень эффективный рантайм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, VladD2, Вы писали:
VD>>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!
VE>Мало что ли парсер-генераторов?
Много. И они все используют ДСЛ-и. По сему и предлагаю сравнить одни из них (без ложной скромности, скажу — один из лучших) с лобовым решением.
Ведь какая еще альтернатива ДСЛ-ям? Просто когда речь идет о парсерах, то все вспоминают интституцкий курс на котором говорилось, что парсер-генераторы — это хорошо. А распространить эту идею на другие области у людей соображения не хватает.
VD>>Проверим, так сказать, на практике и циферки, и твои сомнения. Если ты прав, то без труда запихаешь все в библиотеку, кода у тебя будет хотя бы столько же как в вариенте PegGrammar-а. Ну, и скоростью похвастаешься. Хэнд-мэйд все таки.
VE>Ну когда не хватает библиотеки, можно и кодогенератор. Зачем всё в один исходник пытаться запихнуть под эгидой Универсального ДСЛ Конструктора?
Затем, что почти для любой задачи можно придумать свой ДСЛ. Их можно использовать как библиотеки. Это и есть средство повышения абстракции пока еще слабо задействованное на практике.
При этом никто не отменяет наличия ЯОН-ов и их совместное использование с ДСЛ-ями. Так что с темой я не согласен. Но ЯОН должен гладко интегрироваться с ДСЛ-ями, а лучше — позволять их разрабатывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Не совсем так. Лифты в одном месте, роторные экскаваторы в другом, компьютеры в третьем. А вот нахрена это всё собирать в одном, действительно не очень понятно.
Все на одной земле. Возможно даже на одной стройке. Просто в компютере все виртуально. А ДСЛ-ям место в библиотеках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S> Ну это аналогично трансформации 1С 8 ки. Правда бесит, что нет вывода типа результата запроса. S>Часто приходится делать прямые запросы для апдейтов больших по объему данных, через генераторы запросов. Поэтому, мой взгляд упал на Linq to EF. Там мне понравилось, что можно использовать запросы по схеме. Правда опять же нет вывода типов (может сейчас что изменилось).Там можно переименовать свойства и ассоциации в файле .edmx. Началь делать, да что то времени не хватает да и желания. Да и в модели 1С для регистров нет первичных полей, а для ассоциаций вторичных. S> Я выбрал путь через трансформацию EDMX, но может проще сделать EDMX через какой то АПИ, так по сути я могу создать и из 1С т.к. название полей и ассоциаций имеется?
string entitySQL = " SELECT p, p.Filling " +
"FROM PartyContext.Pinatas AS p "
"WHERE p.Filling.Description='Candy'";
var query=context.CreateQuery<DbDataRecord>(entitySQL);
query.MergeOption = System.Data.Objects.MergeOption.NoTracking;
var pinatasWithFilling=query.ToList();
Вообще конечно смотрю я на Linq to EF с большой надеждой. И по большому счету может она заменить и 1С и парус с соответствующими конфигурациями, или что то на её основе
и солнце б утром не вставало, когда бы не было меня
