Здравствуйте, WolfHound, Вы писали:
G>>Ага. Но вот беда — в нем нет ответа на вполне конкретный вопрос, который тебе только что товарищ задал. Ты перечитай сообщение, на которое отвечаешь. WH>Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество?
А ДСЛ кто писать и поддерживать будет? И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>А ДСЛ кто писать и поддерживать будет?
Архитектор.
V>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?
Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент. Это намного проще, чем принято думать.
Он в проект дольше въезжать будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Gaperton, Вы писали:
G>>Ага. Но вот беда — в нем нет ответа на вполне конкретный вопрос, который тебе только что товарищ задал. Ты перечитай сообщение, на которое отвечаешь. WH>Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество? WH>Я тебя правильно понял?
вульфхунд, я с тебя пупею. дсл это же не только синтаксис, да? ещё семантика, угу? а семантику ты эту как будешь реализовывать? всё тем же объёмом кода, что и в случае с обычным подходом, или твой суперметагенератор автоматом тебе ещё и логику нагенерит? окстись. На выходе в обычном подходе ты получишь библиотеку, в подходе с дсл — собственно дсл, но разницы в результате окромя синтаксиса не будет совершенно. Я кажись очевидное же толкую, а ты всё упорото мантру свою повторяешь.
Здравствуйте, Хвост, Вы писали:
Х>вульфхунд, я с тебя пупею. дсл это же не только синтаксис, да? ещё семантика, угу? а семантику ты эту как будешь реализовывать? всё тем же объёмом кода, что и в случае с обычным подходом, или твой суперметагенератор автоматом тебе ещё и логику нагенерит? окстись. На выходе в обычном подходе ты получишь библиотеку, в подходе с дсл — собственно дсл, но разницы в результате окромя синтаксиса не будет совершенно. Я кажись очевидное же толкую, а ты всё упорото мантру свою повторяешь.
Ты несешь очевидный, для любого кто делал ДСЛ, бред.
Библиотека не может повторить возможности ДСЛ просто по тому, что библиотека заточена под конкретный язык с конкретной моделью вычислений. И как следствие не может выйти за приделы возможностей языка, на котором написана. Единственный способ для библиотеки перейти на другую модель вычислений это интерпретатор другой вычислительной модели. Но это уже будет ДСЛ. Кривой. Тормозной. Многословный. ДСЛ!
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Слова поддержки:
ребята с Software Engineering Radio такой подход пропагандируют уже много лет, они его называют Model Driven Development. DSL там используется как язык описания задачи в подходящих терминах, а вместо "компиляция" они говорят "кодогенерация". Смысл тот же, но не так пугает.
Кстати, Ruby on Rails — хрестоматийный уже пример именно DSLя, в данном случае DSeL (embedded language). Кто тут спрашивал DSL для веба? Забирайте. Еще хрестоматийней — makefile, тоже DSL.
Слова сомнения:
Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода. Его сделать сложнее (и дело отнюдь не в парсинге), поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.
Здравствуйте, D. Mon, Вы писали:
DM>Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода.
Дело в том что практически любое приложение состоит из кучи таких задач.
DM>Его сделать сложнее
Да я бы не сказал.
DM>(и дело отнюдь не в парсинге),
Еще в типизации и кодогенерации.
И то и другое можно сделать очень простым.
Так что сложность будет не больше чем при написании библиотеки.
А чаше даже меньше. Ибо не придется ломать голову над тем как нужную модель вычислений запихнуть в конкретный язык таким образом, чтобы не получить говнокод.
Скажу по секрету: обычно это не получается. И максимум что народу удается, это сделать так чтобы от кода откровенно не тошнило.
В случае с ДСЛ мы можем с чистой совестью генерировать говнокод. Всё равно его никто ни читать, ни тем более править не будет. Все что требуется от генерируемого кода это чтобы он правильно и быстро работал.
DM>поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.
Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
DM>>Его сделать сложнее WH>Да я бы не сказал. DM>>(и дело отнюдь не в парсинге), WH>Еще в типизации и кодогенерации.
И даже не в них, тем более, что их вообще может не быть (много ли кодогенерирует make?). Дело именно в обобщении задачи, нацеливании на решение не только имеющейся задачи, но и других из той же области. Иначе DSL будет одноразовым и не оправдает себя. Скажем, есть у меня задача посчитать определенную цепочку матричных операций. В ее конкретном случае часть матриц могут быть особенными (диагональными или симметричными или даже единичными), и эффективное решение может быть довольно простым. Если делать для этого DSL, возникнет желание научить его решать и другие похожие задачи с матрицами (ведь кому нужен DSL для одного частного случая), а в общем случае такой халявы с единичной матрицей не будет, нужно придумывать и реализовывать эффективные решения для намного более сложных задач, чем была изначально.
WH>Так что сложность будет не больше чем при написании библиотеки.
Да, мою мысль и к библиотеке применить можно. Но не все же пишут библиотеки, многие пишут конечные программы для частных задач.
DM>> Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит. WH>Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.
Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?
Здравствуйте, WolfHound, Вы писали:
WH>Дело в том что практически любое приложение состоит из кучи таких задач.
Ну так тогда у нас "приложения будущего" будут состоять из зоопарка dsl и системного языка, играющего роль клея между ними?
Кстати, вот конкретный пример. Я добавил в проект библиотеку для работы с регулярными выражениями — означает ли это что я добавил новый dsl (пусть и не мною созданный) в проект? )
WH>Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.
А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?
Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
Здравствуйте, WolfHound, Вы писали:
V>>А ДСЛ кто писать и поддерживать будет? WH>Архитектор.
А когда его не будет, то кто?
V>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить? WH>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент.
А нахрена когда есть уже готовые специалисты "общего назначения"?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, alex_public, Вы писали:
_>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?
_>Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
Здравствуйте, D. Mon, Вы писали:
DM>И даже не в них, тем более, что их вообще может не быть (много ли кодогенерирует make?). Дело именно в обобщении задачи, нацеливании на решение не только имеющейся задачи, но и других из той же области. Иначе DSL будет одноразовым и не оправдает себя. Скажем, есть у меня задача посчитать определенную цепочку матричных операций. В ее конкретном случае часть матриц могут быть особенными (диагональными или симметричными или даже единичными), и эффективное решение может быть довольно простым. Если делать для этого DSL, возникнет желание научить его решать и другие похожие задачи с матрицами (ведь кому нужен DSL для одного частного случая), а в общем случае такой халявы с единичной матрицей не будет, нужно придумывать и реализовывать эффективные решения для намного более сложных задач, чем была изначально.
А зачем ты собрался делать больше чем тебе нужно для конкретной задачи?
Прелесть ДСЛ в том, что ты можешь задать универсальный язык для работы с матрицами (это просто) и реализовать его только для той части, которая тебе нужна. Если ты вдруг напишешь что-то, что твоя текущая версия не поддерживает, то просто получишь ошибку компиляции.
Я так не раз поступал.
DM>Да, мою мысль и к библиотеке применить можно. Но не все же пишут библиотеки, многие пишут конечные программы для частных задач.
Ну да. Пишут конечные программы, используя кучу библиотек.
Про то, что в любой программе размером больше калькулятора появляется куча системного кода, который считай библиотека думаю рассказывать не надо.
DM>Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?
DVCS это интересная тема.
И там на самом деле можно очень легко найти, где можно применить ДСЛ с очень большой отдачей.
Все DVCS это по сути базы данных. Но очень конкретные. Типа как SQL серверы с несколькими фиксированными таблицами.
Но если подумать, то не сложно сделать обобщенную базу данных не уступающую конкретным.
При этом мы сможем в DVCS хранить не только исходники, но и трекер и вики и форум и отчеты continuous integration систем и много чего еще что обычно размазано по куче разных слабо связанных программ. При этом все это будет связано между собой. И можно будет простыми запросами к БД получить информацию обо всех активностях связанных с конкретным коммитом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>DVCS это интересная тема. WH>И там на самом деле можно очень легко найти, где можно применить ДСЛ с очень большой отдачей. WH>Все DVCS это по сути базы данных. Но очень конкретные. Типа как SQL серверы с несколькими фиксированными таблицами. WH>Но если подумать, то не сложно сделать обобщенную базу данных не уступающую конкретным. WH>При этом мы сможем в DVCS хранить не только исходники, но и трекер и вики и форум и отчеты continuous integration систем и много чего еще что обычно размазано по куче разных слабо связанных программ. При этом все это будет связано между собой. И можно будет простыми запросами к БД получить информацию обо всех активностях связанных с конкретным коммитом.
Да, fossil почти такой и есть. Внутри использует sqlite.
Здравствуйте, alex_public, Вы писали:
_>Ну так тогда у нас "приложения будущего" будут состоять из зоопарка dsl и системного языка, играющего роль клея между ними?
Что там будет клеем не важно. Да и не факт что он вообще понадобится.
_>Кстати, вот конкретный пример. Я добавил в проект библиотеку для работы с регулярными выражениями — означает ли это что я добавил новый dsl (пусть и не мною созданный) в проект? )
Ты добавил текстовый интерпретируемый ДСЛ.
_>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он? Re[2]: Веб фрэймворк для Nemerle
Все это можно легко обобщить для произвольного ГУИ.
_>Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
Если у нас есть бинбинг к реактивной view model то не нужно.
Все само заработает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Да, fossil почти такой и есть.
Видел я его.
Он тоже очень конкретный.
Там задано несколько конкретных сущностей и все.
Хотя по сравнению с другими конечно большой прогресс.
_>Внутри использует sqlite.
А вот это, честно говоря, весьма сомнительно. Он на больших базах тормозит жутко.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Никак. Языки общего назначения не имеют смысла. WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
давайте разберем такой проект — надо написать IM клиент, например для jabber'а
допустим у нас нет готовой библиотеки и мы пишем его с нуля
у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
где там можно применить DSL?
или возьмем пример побольше — браузер, типа firefox или chrome.
как дсл поможет при разработке браузера?
я это к тому, что у многих задач нет одного большого domain'а,
а есть много подзадач у каждой из которых свой domain, никак не связанный с остальными,
и написание десятка DSL никак не поможет.
я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define)
а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO
Здравствуйте, Abyx, Вы писали:
WH>>Никак. Языки общего назначения не имеют смысла. WH>>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
A>давайте разберем такой проект — надо написать IM клиент, например для jabber'а A>допустим у нас нет готовой библиотеки и мы пишем его с нуля A>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п. A>где там можно применить DSL?
Описание стандартных реакций и нестандартных реакций, начиная с правил переключения статуса, методов антиспама, правил расцветки сообщений в чат-румах...
A>или возьмем пример побольше — браузер, типа firefox или chrome. A>как дсл поможет при разработке браузера?
Вы эта... намеренно подставляетесь? Погуглите, что такое XUL.
A>я это к тому, что у многих задач нет одного большого domain'а, A>а есть много подзадач у каждой из которых свой domain, никак не связанный с остальными, A>и написание десятка DSL никак не поможет.
Поможет.
Вообще-то конфиг это уже DSL. Только маленький, не вырос ещё.
A>я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define) A>а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO
Термин "отладчик" обычно относится к тьюринг-полным языкам. Что от DSL не всегда требуется.
Здравствуйте, netch80, Вы писали:
A>>давайте разберем такой проект — надо написать IM клиент, например для jabber'а A>>где там можно применить DSL?
N>Описание стандартных реакций и нестандартных реакций
конечный автомат? тут конечно DSL может помочь
A>>или возьмем пример побольше — браузер, типа firefox или chrome. A>>как дсл поможет при разработке браузера?
N>Погуглите, что такое XUL.
Я в курсе что такое XUL, только вот он ни как не связан с "языками общего назначения".
Мы же не обсуждаем "ЯП vs языки разметки", мы обсуждаем "ЯП vs ЯП"
A>>я это к тому, что у многих задач нет одного большого domain'а, A>>а есть много подзадач у каждой из которых свой domain, никак не связанный с остальными, A>>и написание десятка DSL никак не поможет.
N>Поможет. N>Вообще-то конфиг это уже DSL. Только маленький, не вырос ещё.
Lua тоже когда-то был "просто DSL для конфига"
A>>я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define) A>>а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO
N>Термин "отладчик" обычно относится к тьюринг-полным языкам. Что от DSL не всегда требуется.
"debugger", ага. "bugs" наверное тоже относятся только к тьюринг-полным языкам.
