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

BS>Запросы бывают иногда на несколько страниц. Это основная проблема как мне кажется sql-подобных языков, при кажущейся простоте, довольно сложно прочитать большой запрос целиком.
Просто в SQL и потомках не предусмотрены средства декомпозиции запросов.
Да и статическая типизация им явно не помешает.

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

VE>Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области.
Все проще. Мера ДСЛьности всегда относительна задачи. Поэтому про некий язык в вакууме нельзя сказать ДСЛ он или нет.
Те чем модель языка ближе к модели задачи, тем этот язык более ДСЛ для этой задачи.
Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 будет ДСЛ для этой задачи.

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

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

WH>Все проще. Мера ДСЛьности всегда относительна задачи. Поэтому про некий язык в вакууме нельзя сказать ДСЛ он или нет.

А твой коллега VladD2 пытается установить какие-то абсолютные критерии.

WH>Те чем модель языка ближе к модели задачи, тем этот язык более ДСЛ для этой задачи.
WH>Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 будет ДСЛ для этой задачи.

См. мой соседний комментарий про факториал и длинную арифметику.
123+324 недостаточно.

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

N>А твой коллега VladD2 пытается установить какие-то абсолютные критерии.
Он часто пытается делать странные вещи.

N>См. мой соседний комментарий про факториал и длинную арифметику.
N>123+324 недостаточно.
Ох, буквоед. Причем знал же, что до пуговиц кто-то докопается.
Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 при условии что типы чисел совпадают с типами чисел нужными для решения задачи, будет ДСЛ для этой задачи.
Так лучше?

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

VE>Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.

С точки зрения теории кристалла, счастье в любом случае наступает при использовании фреймворков. Можно строить фреймворки на основе библиотек; можно — на основе DSL. Можно — на основе того и другого.
В Delphi, к примеру, была VCL (библиотека) + язык описания форм (DSL) + возможность расширять библиотеку. Благодаря наличию малозаметного DSL, хейльсберг сумел с первой попытки получить работоспособную IDE с визуальным дизайнером. Модным пацанам из Symantec потребовалось несколько лет и пара-тройка мажорных версий, чтобы получить мало-мальски стабильную реализацию того же самого на Java.
Ровно оттого, что в качестве "языка описания дизайна формы" была выбрана cама Java, а не DSL. Сложность two-way синхронизации изменений в дизайнере и в коде существенным образом зависит от устройства языка.

Фреймворк ASP.NET построен на основе библиотек и сразу нескольких DSL языков.

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


_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.
А где у вас хранится описание GUI после того, как редактор закрыт? Он же не одноразовый, правда?
Ну, то есть какой файл я открываю этим визуальным редактором, чтобы подправить расположение кнопочки на форме?

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

WH>Просто в SQL и потомках не предусмотрены средства декомпозиции запросов.
WH>Да и статическая типизация им явно не помешает.

Можно ли Linq2Sql считать приближенным к идеалу в этом смысле? Декомпозиция присутствует, статическая типизация присутствует.

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


_>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?
Конечно можете. Это и есть DSL. И когда вы поменяете этот формат, у вас встанут совершенно такие же проблемы, как всегда при смене языка — как мигрировать мегабайты существующего кода.
То, что он у вас внутри какой-то некрасивый, как раз неважно. Важно, что он есть. Вы можете приделать к нему произвольное представление. Визуальное у вас уже есть. Можете приделать текстовое, и получите много замечательных бенефитов.
В Delphi много-много мажорных версий подряд текстовое представление DFM существовало только "на экране", а в файл скидывался бинарник. У нас даже был свой нарошный тул для конверсии txt2dfm и dfm2txt, потому что бинарники крайне неудобно мерджить в системах контроля версий. А потом борланд добавило это в коробку — по той же причине.

Пусть вас не обманывает тот факт, что вы редактируете UI мышкой, а не клавиатурой. Современный редактор текстового ЯП тоже крайне далёк от notepad — там тебе и раскраска синтаксиса, и автодополнение, и всё остальное. Если посмотреть на экран студии непредвзятым взглядом, то окажется, что редактор кода уже тоже достаточно "визуальный". Т.е. помимо чисто текста он рисует в канвас дофига всего. То, что на диске ничего этого реально нет (ну, если не считать наркомании типа Оберона), не делает язык не-языком.

Здравствуйте, Vain, Вы писали:
WH>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
V>А в чём проблема? MFC, ADO, DAO?
Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".

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

K>Можно ли Linq2Sql считать приближенным к идеалу в этом смысле? Декомпозиция присутствует, статическая типизация присутствует.
Приближением можно.

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

VE>Ну а ты давай сделай SQL с нуля, сам язык, теорию, и поддерживай это всё.
Хороший поинт. Вы его не в ту сторону рассматриваете. Надо его рассматривать как повод удешевить разработку языков, теорий, и их поддержку.
Иначе получается, что двадцать лет назад не стоило рассматривать стройматериалы вроде, скажем, газобетона. Ну, потому что пессимисты типа вас записывали бы в стоимость строительства здания стоимость разработки технологии автоклавного твердения бетона и постройки завода, и уверенно бы доказывали полную непригодность этой идеи для малоэтажного строительства. На практике, как мы видим, побеждает всё же газобетон.

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

_>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?
Тысячи их.
_>Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
Чуть менее, чем во всех GUI-фреймворках привязка обработчиков выполнена внутри "языка размётки". Сами обработчики традиционно отдаются в General-Purpose-язык, но это исключительно оттого, что не хочется делать "ещё один" turing-complete язык внутри разметочного.

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

A>давайте разберем такой проект — надо написать IM клиент, например для jabber'а
A>допустим у нас нет готовой библиотеки и мы пишем его с нуля
A>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
A>где там можно применить DSL?
Например, шибко бы пригодился DSL для описания протокола взаимодействия, чтобы чётко были видны все переходы статусов соединения.

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

Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры.
Это оттого, что изначально SQL проектировался как терминальный язык для клиента-человека. Это оказалось стратегической ошибкой.
Б> Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.
По сути получился DSL.

Б>Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?
Традиционной проблемой SQL является его закрытость. В него добавить Regex — нереальная задача. Это скриптовый язык — в том смысле, что у него есть first-class objects, предоставленные "богом", и есть скрипты, написанные "людьми". Ну и von licet jovi non licet bovi.
Там очень слабые возможности как по декомпозиции и повторному использованию того, что сделано в терминах SQL, так и по синтезу и повторному использованию того, что сделано "снаружи".

Как только мы отвлекаемся от ансишного SQL и рассматриваем какую-нибудь реализацию, то оказывается, что RegEx таки можно запихать внутрь SQL, и они даже будут работать.

Б>Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.

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

S>На практике, как мы видим, побеждает всё же газобетон.
Оффтоп: Только хорошие дома получаются из обычного полнотелого кирпича утепленного снаружи эковатой. У меня отец малоэтажным строительством занимается. Причем это все на уровне школьной программы посчитать можно.

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

S>>На практике, как мы видим, побеждает всё же газобетон.
WH>Оффтоп: Только хорошие дома получаются из обычного полнотелого кирпича утепленного снаружи эковатой. У меня отец малоэтажным строительством занимается. Причем это все на уровне школьной программы посчитать можно.
Я не специалист в малоэтажном строительстве, но строить из полнотелого кирпича межкомнатные перегородки — топить печь ассигнациями. Насчёт эковаты — same point still stands, т.е. давайте засчитаем в стоимость коттеджа стоимость завода по выпуску эковаты и мы легко обоснуем, что дешевле строить из мрамора.

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

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

N>>А твой коллега VladD2 пытается установить какие-то абсолютные критерии.
WH>Он часто пытается делать странные вещи.

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

N>>См. мой соседний комментарий про факториал и длинную арифметику.
N>>123+324 недостаточно.
WH>Ох, буквоед. Причем знал же, что до пуговиц кто-то докопается.

Это не "до пуговиц".
Это попытка выяснить хотя бы твои критерии чётко, а не плюс-минус три парсека.

WH>Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 при условии что типы чисел совпадают с типами чисел нужными для решения задачи, будет ДСЛ для этой задачи.
WH>Так лучше?

Для чёткости формулировки — да.
Теперь можно переходить к вопросу её адекватности общей ситуации.
Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.
Нужно придумать так, чтобы ограничение было сильнее.

Здравствуйте, netch80, Вы писали:
N> [...]

Большое спасибо тебе, добрый человек netch80, ты прямо отдушина в этой традиционной РСДН-бойне. Это самый адекватный пост в этой теме.

Мне много лет приходится заниматься DSL-строением. Я никогда не задумывался над философией по этому поводу, и считал, что это именно DSL, но почитав тут много всякого, у меня сложилось впечатление, что на самом деле занимался какими-то "кривыми и ограниченными" языками (здесь

Автор: PSV100
Дата: 26.03.12

можно увидеть пример, недавно консультировался у немерлистов по этому поводу).

И лично мне очень не хватает хорошего языка общего назначения, в том числе и для создания DSL.

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

N>Осталось понять, кто из вас более странный.
Ты.

N>Для чёткости формулировки — да.
N>Теперь можно переходить к вопросу её адекватности общей ситуации.
N>Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.
N>Нужно придумать так, чтобы ограничение было сильнее.
А нельзя придумать классификацию, не привязанную к предметной области.
Ибо Domain-specific language.
А раз мы привязываемся к некоторому домену то для любого языка можно придумать домен (а обычно множество доменов) для которых данный язык является языком предельно высокого уровня. Те делай, что хочешь, но язык более высокого уровня не придумать. Ибо язык и так напрямую оперирует терминами предметной области.

Но если уж так хочется разделить, то нужно смотреть на исходную постановку задачи при разработке языка.
Для SQL это запросы к реляционной базе данных.
Для https://github.com/rampelstinskin/ParserGenerator это разбор текстовых языков программирования.
...
А для С, С++, C#,... написание произвольных программ.
При этом нужно понимать что, например, в том же C# захардкожен linq. Задача которого типизированные запросы к данным. Те это ПОЯ внутри ЯОН.

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

S>Там очень слабые возможности как по декомпозиции и повторному использованию того, что сделано в терминах SQL, так и по синтезу и повторному использованию того, что сделано "снаружи".

Поэтому нужно развиват Linq to EF в том числе и ObjectQuery и использование ХП или динамических функций CLR. Пусть сам SQL будет низкоуровневой конструкцией.