Здравствуйте, VladD2, Вы писали:
VD>В нем не эффективные алогоритмы.
Там нет никаких алгоритмов. Вообще. Просто способ декларативной комбинации функторов.
VD>Как только горамматика выходит за LL(1) производительность парсера резко падает. Вплоть до экспоненты.
Дык, на то они и комбинаторные парсеры, что УГ полное. И они должны заметно сливать даже на LL(1) в сравнении с табличной реализацией. Чем "шире" набор правил на каждом уровне, тем в большее число раз должны сливать. Потому что комбинаторные парсеры — это тупой рекурсивный спуск с перебором.
VD>Но в любом случае его скорость в простых случаях обусловлена (в немалой мере) тем, что он использует генерацию кода по модели.
Не только из-за генерации кода. А еще из-за выделение регулярного подмножества, на котором у вас идет не тупой нисходящий ПЕГ-перебор, а восходящий детерминированный разбор автоматом.
VD>Подход Немерла и N2 позволяет куда больше чем С++-ное метапрограммирование на шаблонах (использованное в бусте). Потому позволяет добиться лучшей скорости.
ХЗ. Сколько раз не меряли — табличные лексеры и парсеры работают фактически с той же скоростью, что построенные на if/switch/case. При том, что последние требуют кодогенерации ("Подход Немерла" (С)), а первые — нет.
Здравствуйте, alex_public, Вы писали:
_>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?
Можем. Большинство популярных DSL на сегодня — именно графические DSL, либо текстово-графические, например Mathcad.
Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?
Здравствуйте, Sinclair, Вы писали:
S>То есть для 3 и 4 просто зависимостей от мгновенных значений есть ещё необходимость всё-таки реагировать на события, или на их цепочки, определённым образом. Пока мне не очевидно, как это сделать хорошим способом. Не обязательно визуальным — важно обойтись без лишнего мусора, типа асинхронных таймеров и синхронных стейт-машин, описанных вручную.
Кстати, в Tweak который делали для Croquet предлагали такое:
onMouseDown
| oldColor |
<on: mouseDown>
oldColor := color.
color := Color yellow.
self waitUntil: #mouseUp.
color := oldColor.
Каждое событие обрабатывается в своём треде. "self waitUntil: #mouseUp" — блокирует тред.
Здравствуйте, VladD2, Вы писали:
WH>>Так у любого языка есть свой домен. VD>Ага. Разработка ПО, например. На фиг нужны такие знания?
Это и есть ЯОН.
VD>Проблема в том, что ты не понимаешь важности четкого определения терминов. Философия ни разу не помогла объяснить людям что-то. Она только путает.
Понимаю.
Но твое определение очень плохое.
Там вообще не ясно, что к чему.
У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.
VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.
Если ДСЛ создать проще чем библиотеку то нет.
VD>Зачем не вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?
О. Тут очень сильно от того что там происходит.
VD>Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.
Вот их можно решать ЯОНом.
Если задача не может быть качественно представлена функциями, то ее нельзя решать этим ЯОНом.
Это все что я пытаюсь сказать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
, это просто синтаксический сахар.
Нет. Уберите из C понятие вызова функции и вы увидите, какой получился копец.
Вызов — это нифига не синтаксический сахар для "встраивания" кода самой функции по месту вызова.
Вот, к примеру, чего нельзя сделать в SQL:
public IQueryable<Customer> SearchCustomer(IQueryable<customer> source, Predicate<string> searchCondition)
{
return
from c in source
where searchCondition(c.FirstName)
|| searchCondition(c.LastName)
|| searchCondition(c.CompanyName)
|| searchCondition(c.Description)
select c;
}
Если бы это было разрешено, то можно было бы писать потом такие запросы:
select * from SearchCustomer(customers, t like '%Armstrong%') order by FirstName
Вот чего нельзя сделать в SQL:
public IQueryable<T> SearchPerson<T>(IQueryable<T> source, string searchText)
where T: IPerson
{
from p in source
where p.FirstName.Contains(searchText)
|| p.LastName.Contains(searchText)
select p;
}
Если бы это было разрешено, то можно было бы писать потом такие запросы:
select FirstName, LastName from SearchPerson(Employees, 'John')
union all
select FirstName, LastName from SearchPerson(Customers, 'John')
union all
select FirstName, LastName from SearchPerson(Contacts, 'John')
Откуда, вы думаете, берутся шестистраничные запросы на SQL? Да ровно оттуда же: нет никаких возможностей по декомпозиции. Приходится всё писать в теле запроса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".
Это с чего это ты на Вы перешел. Я чем то обидел?
Ну я в 1С к сожалению не могу использовать все вкусности, только для прямых запросов. Насчет with спасибо. Уже начал смотреть. Но все равно SQL во многом сливает Linq, а в линке отсутствует куча возможностей SQL.
Это к тому, что так легко создавать ДСЛ. Это по сути единственная ДСЛ которая мне нужна
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
WH>>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ. WH>>И в институтах этому не учат. V>Вообще-то учат, как минимум на специальностях 2201 и 2202.
Так учат что у людей после этого и мыслей о ДСЛ не возникает.
V>Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.
Меньшинство? Фигасе. Да их тут армия.
V>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью. И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.
Вот только когда запрос становится чуть сложнее, чем на пару строк начинается беда.
Ибо в SQL нет средств декомпозиции кода.
WH>>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно. V>Знания тут не при чем. Это такой популярный алгоритм независимо от кол-ва знаний. Действительно, тенденция сравнивать, проверять, расчитывать и т.д. за последние лет 15 куда-то ушла. Не модно. Потому что "мощщи компов все проглотят" и прочая ересь, идущая с сегмента заказухи... которой постепенно заражалась вся индустрия.
Я не об этом. Многие задачи даже нельзя сформулировать пока ты их решать не начнёшь.
V>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.
А если тебе дать компилируемый, статически типизированный SQL имеющий средства декомпозиции запросов?
Это ведь не так сложно.
WH>>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое. V>Там точно DSL нужен, а не таблицы составляющих и коэффициентов?
Таблицами тут не поможешь. Ибо есть куча цветовых пространств преобразования, между которыми очень не линейны. Да хотябы RGB и sRGB. sRGB хорош для восприятия человеком. Но при попытке, например, отмасштабировать в картинку в этом цветовом пространстве появляется куча артефактов. Поэтому нужно переводить в RGB, масштабировать и переводить обратно. Если в картинке есть альфа-канал то там нужно еще кое что сделать. Иначе опять артефакты лезут.
Ну и не нужно забывать, что их у меня было 22 (точно не помню) писать 484 преобразования руками, мягко говоря, не хотелось. Так что я задал только несколько преобразований и по определенным правилам сгенерировал все остальные.
Посмотрел что получилось. И добавил еще несколько преобразований, чтобы углы срезать. И так несколько итераций.
А потом еще цветовые пространства появились.
Без ДСЛ я бы это не осилил.
Причем ДСЛ был очень циничен. Сами цветовые пространства описывались отдельным язычком. Но вот преобразования прямо в коде на С++.
После чего я пробегался по исходнику и собирал список базовых преобразований.
V>Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.
На входе программа. На выходе проезды по памяти, race condition'ы и тп. И все на основе статического анализа. Причем почти без ложных срабатываний.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
WH>>Без ДСЛ я бы это не осилил. C>Ум. А преобразования в виде графа фильтров? Типа как в GEGL?
Мне лень разбираться (я картинками уже не занимаюсь) но похоже идея у нас одна.
Только я всю работу проделал во время компиляции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Без ДСЛ я бы это не осилил. C>>Ум. А преобразования в виде графа фильтров? Типа как в GEGL? WH>Мне лень разбираться (я картинками уже не занимаюсь) но похоже идея у нас одна. WH>Только я всю работу проделал во время компиляции.
Плюс может быть в скорости работы (впрочем, непонятно насколько большой). Минус — в меньшей гибкости.
Здравствуйте, Sinclair, Вы писали:
S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".
Ты про CTE? Да вкусная вещь , особенно её рекурсивное использование. а вот её то в 1С нет. Частично приходится писать в темповые таблицы
Но там вроде есть ограничения использования только к одному запросу. А вомножестве нужно применение к пакету.
и солнце б утром не вставало, когда бы не было меня
S>select FirstName, LastName from SearchPerson(Employees, 'John')
S>union all
S>select FirstName, LastName from SearchPerson(Customers, 'John')
S>union all
S>select FirstName, LastName from SearchPerson(Contacts, 'John')
S>
На самом деле это тоже криво.
У тебя, по сути, меняются только имена таблиц.
Хороший язык должен иметь возможность свести это к чему-то типа такого.
[Employees, Customers, Contacts].Map(SearchPerson(_, 'John')).UnionAll().Select(FirstName, LastName);
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Плюс может быть в скорости работы (впрочем, непонятно насколько большой). Минус — в меньшей гибкости.
Мне гибкость была не нужна. А я не делаю больше чем необходимо. Ибо это глупо.
А вот производительность значение имела.
Так что я просто не стал думать о более гибких и менее производительных решениях.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Можем. Большинство популярных DSL на сегодня — именно графические DSL, либо текстово-графические, например Mathcad.
V>Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?
Хгм, тут речь шла именно о формате данных, в котором редактор сохраняет данные на диск. Т.е. то что сам редактор является своеобразным графическим DSL я с самого начала не сомневался (хотя слово language тут конечно несколько сомнительно, но это мелочи). Весь вопрос был в том, задаётся ли этот самый язык неким эфемерным способом через набор контролов, которыми манипулируют. Или же мы можем просто формально считать обычным текстовым dsl'ом тот самый формат, в котором нарисованный интерфейс сохраняется на диск?
Вот тут у меня и Sinclair мнения и разошлись. Но я не думаю что эту мелочь имеет смысл особо долго обсуждать — это скорее просто вопрос терминологии, что считать dsl, а что нет.
Здравствуйте, netch80, Вы писали:
O>> куда как более матанистые.
N>Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.
А не надо описывать грамматики с конфликтами. Не надо пользоваться всякими устарелыми LALR — есть прекрасный, человечный, понятный интуитивно LL(n), выразимый множеством простых и естественных способов, включая и ad hoc рекурсивный рукописный код. И вот это как раз намного прозрачнее и намного менее матанисто чем даже самый простой регвыр.
N>Чтобы перейти на уровень, где грамматика проще регулярных выражений, надо выучить нехилый пласт теории.
Вот честно — никогда этой самой теорией не владел, забыл все сразу за ненадобностью. А парсеры писать умудряюсь. Да, парсер какого либо хитровыгнутого языка вроде C++ я бы с ходу не написал, ну так надо быть садистом и мизантропом чтобы для DSL такой синтаксис выдумывать. Если синтаксис DSL не ложится на LL(1), то синтаксис плохой.
Здравствуйте, VladD2, Вы писали:
WH>>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
VD>Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.
Ну... JS не имеет встроенных ср-в ввода/вывода, зато имеет ср-ва для подачи хостом внешних ф-ий и переменных, которые скрипт видит как "свои". Т.е. язык остался тот же самый, с тем же синтаксисом и правилами, но стоит подать ему ф-ии общего назначения, и, согласно твоему определению, он превратится в язык общего назначения... А до этого кем был?
VD>Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.
Если бы не возможность произвольного импорта внешних модулей в VBA, или не поданная хостом ф-ия CreateObject, позволяющая создать любой COM-объект, то был бы вполне себе DSL.
VD>Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.
Вот. Об этом автор и говорил. К самому языку относят только его синтаксис, но тут выбор не разбежишься особо — в DSL приходится вкладывать синтаксические конструкции, которые есть и в обычных языках. Но возможности языка определяются доступным из него функционалом, а это уже не только синтаксис. Из скриптовых языков по умолчанию ничего не доступно. Это делает их удобной базой для создания DSL. Как популярный пример — куча DSL сверху LUA.
VD>А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.
Он и есть язык программирования. Только domain-specific, то бишь специально заточенный на узкую область. Как JS в браузере, после того, как в него DOM страницы подали.
Здравствуйте, gandjustas, Вы писали:
G>>>Покажи на примере чтоли? O>> Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает. G>Я уже говорил — разработка сайтов.
Это не для одного DSL задача. Слишком широкая. Формулируйте яснее, пожалуйста. Кроме того, я в этих ваших сайтах, вебах, куках и спамах разбираюсь как свинья в апельсинах, никогда этим не занимался и заниматься не собираюсь.
O>>>> PHP. Серьезно. G>>>PHP — язык общего назначения. O>> А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю. G>Я таки думаю что за DSL нужно считать именно domain-specific.
PHP, если я правильно понимаю, был создан для веб-разрабоки. Как простенький язык текстовых шаблонов. Я не знаю, что там еще в этой вашей веб-разработке нужно, но судя по популярности PHP, ASP, JSP и аналогов, банальные шаблоны всех устраивают.
G> То есть яызки которые имеют ярко выраженную предметную область и имеют некоторые средства, недоступные в этой области ЯОН.
Ну вот в PHP это языковое средство — это
<?php ... >
В языках "общего назначения" такого нет, хоть и можно прикрутить внешним препроцессором (как в ASP.NET или JSP). И тогда язык "общего назначения" становится шаблонным DSL.
G>В PHP нету ничего специального для работы с HTML или HTTP.
Не буду рассуждать о том, в чем не разбираюсь. Но для меня DSL — это язык, созданный под задачу. Насколько он "идеален" для этой задачи и насколько полно покрывает предметную область — это уже дело десятое. Мне интересны малые DSL, сделанные под очень простые, небольшие, четко сформулированные области, а "веб-разработка" — это глыба устрашающих размеров, на которую и смотреть-то по трезвому сознанию не охота.
G> А вот если razor взять, то очень даже есть. Поэтому первый — яон, а второй DSL.
Оба DSL, поскольку оба созданы специально для решения конкретной задачи, а не как "общие".
Здравствуйте, Gaperton, Вы писали:
G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
У вас абсолютно неверное представление о целях создания DSL. В первую очередь DSL нужны самим программистам. Чаще всего — тем же, кто их и создает, то есть, как правило делаются они для себя, и только потом уже для других.
DSL это самый мощный из известных способов упрощения решения сложных задач и избавления от копипасты. Не ООПы всякие и прочая расфуфыренная ентерпрайзная ерунда, а именно DSL. И, поскольку программисты (некоторые) не всегда дураки, они и не станут решать задачи на языках "общего назначения" — они будут делать под каждую маленькую задачу маленький DSL, возможно, поверх языка "общего назначения", а не городить тонны плохого boilerplate-кода.
Посмотрите, например, на исходный код LLVM — там этих DSLей довольно много, в том числе и очевидные внешние DSL (TableGen, на самом деле это даже не один язык а целая их коллекция). И они не для "программистов с на порядок меньшей квалификацией" сделаны, а для самих разработчиков LLVM, которые, полагаю, профессиональнее нас всех вместе взятых. Просто глупо это, правила instruction scheduling писать на "языке общего назначения", очень много однотипного табличного кода получится. А вот сгенерить этот код из полудекларативного описания — легче легкого. В результате добавление поддержки новых архитектур в LLVM становится тривиальной задачей. Если бы они еще и осилили DSL для упрощения pattern matching в C++ сделать, то избавились бы и от многокилометровых лесенок из if-ов (например, в instcombine pass), но тут скорее не на разработчиках вина, а на недостатках языка C++.
Про gcc и говорить не буду, там просто Лисп внутри, а на Лисп у здешней публики, как я уже догадался, сильнейшая аллергия.
G>Еще один пример из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.
Насколько я знаком с игровой индустрией, пишут их все же таки программисты. А Lua используется потому, что это офигенно удобный динамический язык, и разработка игровой логики на нем идет на порядки быстрее, чем если бы это был статически типизированный монстр с раздельной компиляцией вроде C++.
G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple. Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.
Самая популярная такая система — Matematica. У меня язык не повернется сравнивать ее семантику с бейсиком, хотя пользуются Математикой далеко не программисты. Это функциональный язык, построенный на правилах переписывания, ни разу не бейсик.
R — тоже функциональщина, и тоже очень популярен среди не-программистов. Бейсиком там и не пахнет.
G>И это закономерно, что базовая семантика этих языков тупа до безобразия.
"Базовая" семантика не обязана быть тупой. Главное, чтобы язык предоставлял тупой и очевидный синтаксический сахар, прячущий всю эту семантику вглубине.
Некоторые по этому пути вообще очень далеко зашли. В системе Stata по сути два языка — один, внешний — для конечных пользователей, финансистов там всяких, которые программированием заниматься вообще не должны, и второй (в который первый язык тупо транслируется) для "power users".
G> Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
Про Mathematica знает намного больше людей, чем про Lua. А уж матана там хватило бы на зверское убиение трех курсов физтеха.
Здравствуйте, netch80, Вы писали:
N>Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.
А вот на этом пути надо не перегибать палку. В некоторых промышленных CAD-ах так старались добиться "нечеткого" и "естественного" синтаксиса, что получились языки с тысячами ключевых слов и десятитомными документациями.
