Здравствуйте, Vain, Вы писали:
V>>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить? WH>>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент. V>А нахрена когда есть уже готовые специалисты "общего назначения"?
Это из той же серии что и "Нахрена лифты, когда есть лестницы?", "Нахреа роторные экскаваторы, когда есть лопаты?", "Нахрена компьютеры, когда есть счеты?"... И, главное, обоснование можно то же использовать — нахрена вифтеры, эксковаторщики, программисты, когда есть специалисты "общего назначения" у которых есть ноги, руки и голова которые отлично справляются с хождением по лестницам, рытьем лопатой и щелканье костяшками?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>1C 8 подойдет? G>>Ага, там совершенно тупая трансляция в SQL.
AVK>Ну да, обозвал тупым и все понятно. Запрос там строится в терминах одноэсных документов, проводок и т.п. И результат тоже возвращается ввиде объектов 1С.
Только все это 1-в-1 мапится на SQL, только имена переписываются.
AVK>>>Ну вот Парус 10 такой Реальный, не академический. G>>Ну пример приведи, я не пользуюсь парусом.
AVK>Ну вот что в тестах, к примеру, валяется:
Так это SQL. А где его собственный DSL?
AVK>>>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка. G>>В чем лучше? AVK>Во всем.
Ага, грузины лучше чем армяне
Аргументация на уровне детсада.
G>> Вот на примере SQL мы видим что dsl_и над ним не лучше. AVK>Это где ты такое увидел?
Везде. От eSQL\HQL до корпоративных систем.
G>>>> Если менее мощный, то надо или больше писать для достижения того же результата AVK>>>Попробуй доказать. G>>Так ты сам сказал что
G>>
G>>DSL как правило менее мощный, нежели сравнительно универсальный язык
AVK>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.
Тогда давай формализуем понятие мощности. Если рассматривать полноту по тьюригу, то ей не все dsl обладают , следовательно на них нельзя написать все.
Если мы рассматриваем мощность как выразительную силу языка, то есть возможности выразить некоторые вычисления наименьшим количеством конструкций этого самого языка, то очевидно что в менее мощном языке надо больше писать для достижения того же результата.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>>>Возьми пару известных систем и покажи где там eSQL AVK>>>1C 8 подойдет? G>>Ага, там совершенно тупая трансляция в SQL.
VD>Способ реализации DSL-я не влияет на его свойства. По любому DSL будет удобнее, а код на нем короче. Иначе никто не стал бы лепить DSL-и, над другими языками (и уже тем более над другими DSL-ями как в случае с SQL).
Это я не спорю, что есть некоторые DSL, код на которых короче, лучше итп
Я опровергаю мысль о ненужности языков общего назначения. Ведь если DSLя нет, то написать его никак не проще, чем код решающий задачу.
G>>>>Покажи некривой. Только реальный, не академический. AVK>>>Ну вот Парус 10 такой Реальный, не академический. G>>Ну пример приведи, я не пользуюсь парусом.
VD>Это твои проблемы. Иначе на основании того, что ты ничем не пользуешься можно "доказать" все что угодно. VD>Ты логику вообще проходил?
Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
WH>>>Когда этим кто-нибудь займется. Твой КО. G>>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано. G>>В чем проблема?
VD>Почему не придумали? Придумали и массу. Проблема только в том, что: VD>* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта. VD>* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты".
Я говорил тоже самое, со мной начали спорит
WH>>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД? G>>Это технически невозможно, сервер на другом компе стоит, порты закрыты. VD>Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете? VD>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?
Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.
А вот лазать руками по файловым базам, типа sqlce — было дело.
Здравствуйте, alex_public, Вы писали:
_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.
Сложный вопрос. ДСЛ может быть разным. В том числе ДСЛ может описываться набором объектов в ЯОН (языке общего назначения).
Тут важен факт наличия некой модели по которой генерируется код. Эта модель и есть по сути ДСЛ.
Визуальный редактор не всегда генеирирует код на ЯОН. Скажем тот же МС помучившись с генерацией и интерпретацией ЯОН-ов в ВинФормсах выбрала DSL основанный на XML в WCF. И сделано это было не потому что в МС ополоумили. Просто с генерацией ЯОН (и тем более с их чтением) были серьезные проблемы. А уж о рантайм-генерации и думать было сложно. На серевере это еще прокатывает (АСП.НЕТ), но на клиенте слишком много сложностей.
Кроме того в тех же ВинФормсах поддержка генерации ЯОН не полная. По сути поддерживается только подвид ЯОН-ов воспроизводящий нужную функциоальность. И при этом не делается многих проверок. Так что сгенерированный код может вполне оказаться не компилируемым. Сложность добавления поддержки нового языка тоже вилика. К тому же F#-у дизайнер винформсов так и не прикрутили (не смотря на ресурсы и знания МС).
_>И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?
Как раз лучше полноценный ДСЛ. Но по бедности создание ДСЛ-ей выливается в слишком большой геморрой. Генерация тоже выливается в геморрой. По этому народ чаще всего тупо плюет на эти подходы и долбит все руками (набирая тучу индокодеров). И только при частом изменении модели (см. выше) отдельные личности приходят к ДСЛ-ям/генерации кода по модели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>Если там можно будет писать какой-то достаточно сложный код (в рамках DSL, т.е. касающийся только GUI), а не просто делать размётку контролов, то да, это заметно удобнее было бы. А если у нас тут решается только задача "нарисовать" интерфейс, то все эти сущности уже лишними кажутся — проще кодогенерация из визуального редактора.
В ГУИ основные проблемы не нарисовать ГУИ, а связать его с данными и анимировать. Визуальный редакто поможет тебе только нарисовать статичный ГУИ. А две остальные проблемы нужно решать другими методами.
Паттерн MVVM решает две остальные проблемы, но при ручном его реализации приводит к довольно большому объему кодирования (бестолкового копипаста с изменениями) и/или к рантайм-высислениям которые нельзя проверить во время компиляции. Тут использование ДСЛ-ней и генерации кода может дать огромный выигрыш.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Формально тоже все в порядке. Выражения типа "язык танца" или "язык тела" не встречал? Языки вовсе не обязаны быть исключительно текстовыми.
Ага — Мальчик жестами показал, что его звали "Хуан".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
V>>>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить? WH>>>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент. V>>А нахрена когда есть уже готовые специалисты "общего назначения"? VD>Это из той же серии что и "Нахрена лифты, когда есть лестницы?", "Нахреа роторные экскаваторы, когда есть лопаты?", "Нахрена компьютеры, когда есть счеты?"... И, главное, обоснование можно то же использовать — нахрена вифтеры, эксковаторщики, программисты, когда есть специалисты "общего назначения" у которых есть ноги, руки и голова которые отлично справляются с хождением по лестницам, рытьем лопатой и щелканье костяшками?
Никто собственно не отменял прогресс. Но вы ставите знак равенства между прогрессом и дсл как что-то очевидное, не доказав что они вообще должны быть равны и равны вообще. А любые вопросы на тему почему они равны сводятся опять же к аппеляции что если не равны то это отказ от прогресса.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Факты про то что ни один старап не будет рисковать своим проектом...
Вот это ты сейчас хорошо пошутил. У стартапов весь смысл в риске ради возможного поблучения резких конкуретных преимуществ. По сему стартап не желающий рисковать исходно обречен. Ведь есть большие компании которые используют технологии с меньшим риском. Но у больших компаний есть другие конкуретные преимущества (ресурсы и маркетинг).
V>и как следствие кошельком чтобы проверять выстрелит ли дсл?
Кошелек то не их. В этом вся суть .
V> Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?
А зачем менять отлаженный код без надобности? Можно его обернуть в ДСЛ, или использовать ДСЛ в тех областях где код не так отлажен или его приходится постоянно колбасить руками (менять или писать новый).
V>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл.
Писать ДСЛ-и не должны все кому не лень. А вот использовать и изучать куда легче чем код написанный вручную.
Сейчас основная проблема в ДСЛ-подходе — это сложность разработки и сопровождения ДСЛ-ей, а так же низкое качество получаемых ДСЛ-ей (нет поддержки ИДЕ, низкая скорость, нет контроля типов, нет документации). Если их решить, то ДСЛ будет отличным решением для многих проблем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Хвост, Вы писали:
Х>и как, много ты уже моделей видел на практике? их по сути три: абстрактная машина, реляционная модель, редко но метко лямбда-исчисления.
Это универсальные модели. Они обладают одной проблемой на них можно выразить все что угодно, но на них это делать сложно. Для того чтобы преодолеть этот эффект сначала придумали ассемблеры, потом языки высокого уровня (общего назначения), а затем ДСЛ-и.
Х>совсем редко всякий экстрим вроде пролога можно не рассматривать.
Чёйта? Формальная логика вдруг перестала быть универсальной моделью для программистов?
Х>Так вот, для покрывания подавляющей потребности в твоих дслях с моделями вычислений достаточно взять гибридный язык с поддержкой рефлексивной метаинформации рантаймом, например скалу или фшарп и усё, все модели как на ладони. ДСЛ не нужен!
Жаль что этого не знали создатели F#-па которые для разработки компилятора F# написанного на F#-е использовали ДСЛ (генератор парсеров аналогичный yacc-у). Видимо им была не знакома тавоя замечательная теория.
И вообще, не ясно зачем тогда нужны эти Скалы и F#-ы, если по твоей теории для представления чего угодно достаточно лябда-исчислений или машины Тюринга.
Вот, к примеру, БэйнФак полон по тьюрингу. Так почему бы не писать код на нем, а не на Скале или F#-е?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.
Остается только понять почему VoidEx периодически троллит нас исповедуя, казалось бы, те же истины.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, D. Mon, Вы писали:
DM>Слова сомнения: DM>Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода. Его сделать сложнее (и дело отнюдь не в парсинге), поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.
Это не слова сомнения, а голос разума. ДСЛ ни разу не серебрянная пуля. Его создание и поддержка, даже на очень выскокоуровневом средстве (которым должен стать N2
Придумывать модель/язык, конечно же, имеет смысл только когда им можно выразить больше чем одно предложение.
Но такие задачи отнюдь не редки. И только наше неумение их выявлять, и крайне низкая производительность труда тех кто создает инструменты поддержки ДСЛ-ей делают этот подход крайне не распространенным.
Проблему выявления ДСЛ-ей (и их формализации) мы решить не в силах. Но упростить их "взлет" мы в состоянии. А это позволит экспериментировать, что в свою очередь, поможет и в выявлении ДСЛ-ей.
Так что тут нужно не критиковать, а прорабатывать научную и техническую базу.
На мой взгляд, как ООП и ФП, в свое время, ДСЛ-естроение должно занять свою нишу в инструментарии (в широком смысле этого слова) современного разработчика. Но для этого нужно изменить современные средства разработки и современные языки. Они реально тормозят прогресс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Это я не спорю, что есть некоторые DSL, код на которых короче, лучше итп G>Я опровергаю мысль о ненужности языков общего назначения. Ведь если DSLя нет, то написать его никак не проще, чем код решающий задачу.
Да это Вольфхаунд преувеличивает, как всегда. Он ультра-максималист.
Есть и туча задач которые не требуют языковой абстрации. Скажем одноразовые задачи или вычислительные задачи (где ДСЛ — это арифметика). Кроме того обычно между ДСЛ-ями нужен "клей". ЯОН (язык общего назначения) является таким клеем.
Кроме того ЯОН наиболее удобна форма в которую можно транслировать ДСЛ-и. В теории ДСЛ-и можно транслировать и в машинный код (или байткод), но делать это сложно. Обычно проще транслировать их в ЯОН, а уже ЯОН во что-то более низкоуровневое.
G>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.
Тебе уже привели примеры языков запросов из 1Эс и Паруса. SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.
VD>Тебе уже привели примеры языков запросов из 1Эс и Паруса.
1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.
VD>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.
Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается.
SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.
Здравствуйте, gandjustas, Вы писали:
VD>>Почему не придумали? Придумали и массу. Проблема только в том, что: VD>>* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта. VD>>* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты". G>Я говорил тоже самое, со мной начали спорит
Я тебя и цитировал. Только ты сравни цитаты. Они ведь не точные. Я там лопату добавил.
У ДСЛ-подхода есть две проблемы:
1. Сложность выявления ДСЛ-ей в прикладной задаче. Эта проблема опыта и образования. Если в универах начнут этому учить, то проблема исчезнет.
2. Сложность реализации и поддержки ДСЛ-ей. Это техническая проблема которую можно решить самим же ДСЛ-подходом.
WH>>>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД? G>>>Это технически невозможно, сервер на другом компе стоит, порты закрыты. VD>>Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете? VD>>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля? G>Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.
Это потому-что кто-то уже решил за тебя, что смысла использовать ISAM нет. И решил он это именно на том основании, что уже есть отличный ДСЛ радикально упрощающий взаимодействие с СУБД.
А межу прочем году так в 9х (точно не помню) мне один не глупый с виду дядька из одной именитой конторы втирал, что MS SQL (тогда еще совсем древний) дерьмо, так как у него доступ на ISAM уровне не документирован. А вот Б-трив — это супер, так как в нем он четко прописан.
G>А вот лазать руками по файловым базам, типа sqlce — было дело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vain, Вы писали:
V>Никто собственно не отменял прогресс. Но вы ставите знак равенства между прогрессом и дсл как что-то очевидное, не доказав что они вообще должны быть равны и равны вообще. А любые вопросы на тему почему они равны сводятся опять же к аппеляции что если не равны то это отказ от прогресса.
Все по сто раз доказано. Читайте Фаулера. Он все разжевал и разложил по полочкам.
Тут вопрос в сознании людей и в инструментах. Второе можно поправить. С первым все сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
___>>Только с другой стороны, если язык будет позволять менять синтаксис, встраивать в себя HTML, SQL, абракадабру Васи Пупкина, блабладсл Пети из соседнего отдела и т.д. Бедному программисту Ване Иванову, только принятому на работу, придется учить все эти супермегаязыки.
VE>Ему и так придётся.
Не придется, ему лишь нужно посмотреть на внешний интерфейс либы, которая задана в рамках этого же языка.
VE>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.
Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Да, я согласен. (спасибо за разъяснение). Я думаю путаница с 1С возникает потому, что это язык общего назначения, но с встроенными dsl. Хотя бы свой язык запросов там dsl. И потом методы работы с встроенными объектами — например Документы.Счет.СоздатьДокумент(), завязанные на контекст предметной области — вроде как тоже dsl. И кстати там была попытка сделать эквивалент запросам, но чего-то идею не развили. Например. Документы.Счет.Выбрать() суть обычная выборка — select Счет from Счет, хотя я считаю в этом есть смысл. Запросы бывают иногда на несколько страниц. Это основная проблема как мне кажется sql-подобных языков, при кажущейся простоте, довольно сложно прочитать большой запрос целиком.
Здравствуйте, VladD2, Вы писали:
VD>У ДСЛ-подхода есть две проблемы: VD>1. Сложность выявления ДСЛ-ей в прикладной задаче. Эта проблема опыта и образования. Если в универах начнут этому учить, то проблема исчезнет.
Наверно, тогда не выявления DSL, а 1) выявления их желательности, 2) выявления, что именно должно туда попасть.
G>>Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.
VD>Это потому-что кто-то уже решил за тебя, что смысла использовать ISAM нет. И решил он это именно на том основании, что уже есть отличный ДСЛ радикально упрощающий взаимодействие с СУБД.
VD>А межу прочем году так в 9х (точно не помню) мне один не глупый с виду дядька из одной именитой конторы втирал, что MS SQL (тогда еще совсем древний) дерьмо, так как у него доступ на ISAM уровне не документирован. А вот Б-трив — это супер, так как в нем он четко прописан.
Ну и он был прав. Там и тогда. Потому что мощность средней тогдашней машины даже уровня сервера была недостаточна, чтобы вытягивать накладные расходы языка в виде SQL до незаметного уровня, а алгоритмы реализации — чтобы обеспечить эффективную работу лучше, чем ручные операции.
Я в те времена пробовал SQL ещё в FoxPro 2-м-каком-то и долго плевался, потому что "это" убивало производительность на порядок. Хотя внешне всё красиво, мол, оно само собой строит реальный запрос, разбирает связи, вычисляет ограничения и оптимизирует поиск... документация была даже полна восторженных воплей по поводу какого-то суперхитрого метода Rushmore (что это, никто не раскрывал, но было похоже на метод немедленного прыжка к нужному ключу).
Возможно, в высококорпоративном мире с его подходами SQL был уже тогда единственным нормальным путём, но кто это мог получить *тут* на живых примерах? Массовая миграция на подходы с SQL — это уже конец 90-х, если не 2000-е.
Реальный, не академический.
