Здравствуйте, WolfHound, Вы писали:
WH>А для распространённых задач ДСЛи уже будут написаны.
Я тоже за DSL. Но и с DSL тоже куча (пока) нерешенных проблем.
Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры. Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.
Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?
Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.
Здравствуйте, WolfHound, Вы писали:
WH>Ты несешь очевидный, для любого кто делал ДСЛ, бред. WH>Библиотека не может повторить возможности ДСЛ просто по тому, что библиотека заточена под конкретный язык с конкретной моделью вычислений. И как следствие не может выйти за приделы возможностей языка, на котором написана. Единственный способ для библиотеки перейти на другую модель вычислений это интерпретатор другой вычислительной модели. Но это уже будет ДСЛ. Кривой. Тормозной. Многословный. ДСЛ!
и как, много ты уже моделей видел на практике? их по сути три: абстрактная машина, реляционная модель, редко но метко лямбда-исчисления. совсем редко всякий экстрим вроде пролога можно не рассматривать. Так вот, для покрывания подавляющей потребности в твоих дслях с моделями вычислений достаточно взять гибридный язык с поддержкой рефлексивной метаинформации рантаймом, например скалу или фшарп и усё, все модели как на ладони. ДСЛ не нужен!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема. G>>Ты считаешь по-другому, можешь обосновать? WH>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
А где учат хорошему?
WH>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.
Практика показывает обратное. Более-менее сложный компилятор сделать под силу единицам.
G>>Желательно с примерами? WH>Примерами чего? Насколько проще могут быть парсеры по сравнению с классическими подходами? WH>https://github.com/rampelstinskin/ParserGenerator WH>И это еще ранний этап разработки.
А приложения есть? Реальные, которые людям нужны.
WH>К нему еще декларативный типизатор будет приделан. WH>Так что создание языков станет вообще детской игрой.
Что-то слишком много будущего времени.
G>>не буду, а зачем ? WH>Те с тем что ДСЛ решает задачу лучше ты согласен.
Да, я никогда по-другому не говорил.
G>>Больше деталей, что на входе, что на выходе? G>>Сколько строк исходников? WH>Что это поменяет? Сотни связей и тысячи вариантов решения никуда не денутся.
Ну еще не факт что их нельзя обобщить.
Вот я и спрашиваю, сколько строк кода, что принимает на вход и что получается на выходе.
G>>Я пока вижу что ты написал генератор кода по каким-то исходным данным. WH>Под это определение попадают _все_ компиляторы.
Я имею ввиду генератор текста программы по структурированным данным. Это как-бы проще, чем полноценный компилятор из текста в байт-код или конкретные операции.
G>>Ну таких генераторов и сейчас немеряно, только бизнес-задачи они не решают, в основном утилитарный код генерят. WH>Это ты от недостатка кругозора так говоришь.
Я про бизнес разработку говорю. Там DSLи очень узкую и утилитарную функцию выполняет.
G>>Причем код как раз на языке общего назначения. WH>В качестве ассемблера они обычно весьма не плохи. Хотя тоже проблемы возникают. Например зачем мне проверки выхода за приделы массива если я и так знаю что генерируемый код за приделы массива никогда не полезет? Да и соглашения о вызовах обычно весьма гадкие и тормозные.
G>>Ты еще не привел фактов, которые подтверждают твое мнение. WH>Это как? 17 строк против 56 страниц это не факт? WH>А ведь я могу еще показать что мой генератор парсеров генерирует по простому ДСЛ. WH>И что характерно руками получится не намного меньше кода. WH>Если пошарить по интернету можно еще кучу примеров найти. WH>Но ты же на все скажешь, что это все академизм или еще какую отмазку придумаешь.
G>>Ограниченный срок и ресурсы, реальный value. WH>BLToolKit подойдет? Если мне не изменяет склероз, начинался он как раз как часть конкретного проекта. Ибо IT'у надоело писать руками маппинг объектов.
А где там DSL? В маппинге объектов как раз нету. А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код.
Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL.
WH>И да BLT это ДСЛ. Причем компилируемый.
Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
AVK>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается.
Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы.
А язык запросов в том же 1c непосредственно мапится на SQL.
Здравствуйте, Хвост, Вы писали:
Х>и как, много ты уже моделей видел на практике? их по сути три: абстрактная машина, реляционная модель, редко но метко лямбда-исчисления. совсем редко всякий экстрим вроде пролога можно не рассматривать. Так вот, для покрывания подавляющей потребности в твоих дслях с моделями вычислений достаточно взять гибридный язык с поддержкой рефлексивной метаинформации рантаймом, например скалу или фшарп и усё, все модели как на ладони. ДСЛ не нужен!
Ты даже не представляешь насколько ты смешон. The principal programming paradigms
Это только для языков общего назначения. И там еще не все перечислено.
Но есть и более конкретные языки. Например, этот https://github.com/rampelstinskin/ParserGenerator имеет свою ни на что не похожую модель вычислений. Чтобы ее эмулировать нужно, генерировать кучу кода или написать интерпретатор. И то и другое ДСЛ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
WH>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается. G>А где учат хорошему?
Нигде.
WH>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора. G>Практика показывает обратное. Более-менее сложный компилятор сделать под силу единицам.
Я планирую это исправить.
G>А приложения есть? Реальные, которые людям нужны.
Предыдущую версию (которая намного слабее) реально используют.
Эта появилась весьма недавно и находится в очень не стабильной фазе разработки.
Но и ее уже пытаются использовать.
G>Ну еще не факт что их нельзя обобщить.
Факт.
G>Вот я и спрашиваю, сколько строк кода, что принимает на вход и что получается на выходе.
На входе цветовые пространства и несколько трансформаций. На выходе все недостающие трансформации.
G>Я имею ввиду генератор текста программы по структурированным данным. Это как-бы проще, чем полноценный компилятор из текста в байт-код или конкретные операции.
Это как бы без разницы.
Особенно если есть языковой фреймворк с иерархией языков.
Например тот же ParserGenerator напрямую создает сборки .НЕТ. Текст генерируется по внутреннему представлению и только для отладки. Причем для этого всего лишь нужно было сказать компилятору, чтобы он этот текст сгенерировал. Кода писать не пришлось.
Но по факту это проще чем генерировать текст.
Ибо чуть менее чем всю работу делает компилятор немерла.
G>Я про бизнес разработку говорю. Там DSLи очень узкую и утилитарную функцию выполняет.
Это по тому, что у всех такие же стереотипы как у тебя.
Люди просто не рассматривают ДСЛ в качестве решения.
G>А где там DSL? В маппинге объектов как раз нету.
Маппинг объектов это и есть ДСЛ.
G>А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код.
Это по тому что:
1)Мелкософты сделали ужасное представление.
2)C# для такого не подходит.
Вот погляди на что способен немерле https://github.com/linq2db/linq2db/blob/master/Source/SqlBuilder/Optimizer.n
В какой ужОс это превратится на C# подумай сам.
И это весьма примитивный подход.
В Н2 все будет куда интереснее.
G>Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL.
IQueryable всю сложность и создает. А сгенерировать SQL не сложно.
WH>>И да BLT это ДСЛ. Причем компилируемый. G>Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду?
Нужно очень постараться чтобы не заметить там язык.
[PrimaryKey] public int ParentID;
[PrimaryKey] public int ChildID;
[Association(ThisKey = "ParentID", OtherKey = "ParentID")]
public Parent Parent;
[Association(ThisKey = "ParentID", OtherKey = "ParentID", CanBeNull = false)]
public Parent1 Parent1;
[Association(ThisKey = "ParentID", OtherKey = "ParentID2", CanBeNull = false)]
public Parent3 ParentID2;
[Association(ThisKey = "ParentID, ChildID", OtherKey = "ParentID, ChildID")]
public List<GrandChild> GrandChildren;
все эти атрибуты никакого отношения к C# не имеют.
Это декларативный язык маппинга.
А еще внутри BLT целый компилятор есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
G>Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы.
Это и есть одно из важнейших свойств ДСЛ.
Они не позволяют делать очень большой класс специфичных для предметной области ошибок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
G>>Я про бизнес разработку говорю. Там DSLи очень узкую и утилитарную функцию выполняет. WH>Это по тому, что у всех такие же стереотипы как у тебя. WH>Люди просто не рассматривают ДСЛ в качестве решения.
Ага, прямо ты один д'артаньян
G>>А где там DSL? В маппинге объектов как раз нету. WH>Маппинг объектов это и есть ДСЛ.
А присваивание не DSL?
G>>А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код. WH>Это по тому что: WH>1)Мелкософты сделали ужасное представление. WH>2)C# для такого не подходит.
А какие языки подходят? Что в них должно быть? C++ подходит?
WH>Вот погляди на что способен немерле https://github.com/linq2db/linq2db/blob/master/Source/SqlBuilder/Optimizer.n WH>В какой ужОс это превратится на C# подумай сам. WH>И это весьма примитивный подход. WH>В Н2 все будет куда интереснее.
Кроме pattern-matching ниче особенного нет. Или я не туда смотрю?
G>>Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL. WH>IQueryable всю сложность и создает. А сгенерировать SQL не сложно.
Придумай язык проще и не потеряй в мощности. Только так чтобы он был подмножеством mainstream языка, иначе толку нет.
WH>>>И да BLT это ДСЛ. Причем компилируемый. G>>Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду? WH>Нужно очень постараться чтобы не заметить там язык. WH>
WH> [PrimaryKey] public int ParentID;
WH> [PrimaryKey] public int ChildID;
WH> [Association(ThisKey = "ParentID", OtherKey = "ParentID")]
WH> public Parent Parent;
WH> [Association(ThisKey = "ParentID", OtherKey = "ParentID", CanBeNull = false)]
WH> public Parent1 Parent1;
WH> [Association(ThisKey = "ParentID", OtherKey = "ParentID2", CanBeNull = false)]
WH> public Parent3 ParentID2;
WH> [Association(ThisKey = "ParentID, ChildID", OtherKey = "ParentID, ChildID")]
WH> public List<GrandChild> GrandChildren;
WH>
WH>все эти атрибуты никакого отношения к C# не имеют. WH>Это декларативный язык маппинга.
Ты сам утверждал что языки общего назначения не имеют смысла и приводишь в пример код на языке общего назначения.
Ты или шляпу сними, или штаны одень.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы. WH>Это и есть одно из важнейших свойств ДСЛ. WH>Они не позволяют делать очень большой класс специфичных для предметной области ошибок.
Я же и говорю, утилитарная роль. Цель таких DSL не решение бизнес-задач, а решение сторонних задач, которые требуют много кода (иногда довольно тупого).
Роль dsl в решении бизнес-задач ты пока не показал. Это значит твой тезис о ненужности языков общего назначения не имеет реального обоснования.
Здравствуйте, gandjustas, Вы писали:
WH>>В Н2 все будет куда интереснее. G>Кроме pattern-matching ниче особенного нет. Или я не туда смотрю?
А что еще нужно для трансформации дерева?
Вся сложность написания LINQ провайдера и состоит в распознавании и трансформации деревьев.
Делать это на C# мягко говоря проблематично.
G>Придумай язык проще и не потеряй в мощности. Только так чтобы он был подмножеством mainstream языка, иначе толку нет.
Лол. Мелкософты встроили в C# ДСЛ для работы с данными.
G>Ты сам утверждал что языки общего назначения не имеют смысла и приводишь в пример код на языке общего назначения. G>Ты или шляпу сними, или штаны одень.
И что C# поймет, что тут написано и сгенерирует маппинг?
Нет. Этим занимается BLT.
А то, что C# позволяет создавать примитивные встроенные ДСЛ это его преимущество перед языками, которые это не могут. Но по сравнению с языками, которые заточены на создание ДСЛ это детский сад.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
G>Я же и говорю, утилитарная роль. Цель таких DSL не решение бизнес-задач, а решение сторонних задач, которые требуют много кода (иногда довольно тупого). G>Роль dsl в решении бизнес-задач ты пока не показал. Это значит твой тезис о ненужности языков общего назначения не имеет реального обоснования.
Если язык запросов не решение бизнес-задачи? То я тогда не знаю что такое решение бизнес задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Буравчик, Вы писали:
Б>Я тоже за DSL. Но и с DSL тоже куча (пока) нерешенных проблем.
Их нужно просто решать. Ибо если не решать (как тут некоторые предлагают) ничего не получится.
Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой?
Это правильный вопрос.
И на него довольно трудно сходу ответить.
Но у меня есть мысли.
Б>В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.
Просто мелкософты захардкодили в ЯОН конкретный ДСЛ.
А то что у ДСЛ кроме кодогенерации бывает еще и рантайм это далеко не новость.
Б>Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?
Тут в общем случае все плохо.
Ибо для того чтобы таким образом соединить ДСЛ они должны транслироваться в один язык.
Для SQL и регекспов это вполне возможно. Но для этого SQL сервер должен поддерживать такие фокусы.
Что на самом деле не так уж и сложно.
Б>Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.
Видно.
Есть такая абстракция называется линза.
Если не углубляться в матан это пара чистых функций которые однозначно отображают два множества друг в друга.
Все что нам нужно это для интересующих нас форматов данных (может быть больше двух) создать некий канонический формат данных. И для каждого из наших форматов сделать линзу в канонический формат.
После чего мы автоматом получим трансформации из каждого формата в каждый.
Ессно компилятор сможет генерировать нужные трансформации только тогда когда они действительно нужны и сильно оптимизировать их. Не генерировать же N^2 трансформаций даже тогда когда они не нужны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
AVK>>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается. G>Да, но почти всегда он довольно ущербен
Это с чем сравнивать. Как минимум, по мощности он обычно сопоставим с голым SQL, но работает в терминах прикладных метаданных, а не в терминах метаданных БД. Типичный пример — Entity SQL в EF.
G> и по сути нужен чтобы не дать программисту нарушить целостность платформы.
Не только. Он нужен прежде всего чтобы писать запросы, по возможности не вдаваясь в подробности хранения данных в конкретной БД.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>Что там будет клеем не важно. Да и не факт что он вообще понадобится.
Ну почему же... Как раз важно. Я собственно знаю только один беспроблемый способ интеграции dsl — когда он сам написан на том же языке что и основной код. Тогда это получается как просто подключение нетривиальной библиотеки. В других же случаях начинаются всякие ужасы.
WH>Re[2]: Веб фрэймворк для Nemerle
WH>Все это можно легко обобщить для произвольного ГУИ.
Нуу вот как раз для веба на мой взгляд какой-то новый gui dsl и не нужен. Там уже есть html+javascript — полноценная разметка и обработчики. Причём если взять всякие там jqueryui, то уже на уровне полноценного интерфейса.
А вот как на счёт gui dsl для обычных приложений? Хотя я смотрю такими темпами html+javascript станет gui dsl и для десктоп приложений. Уже даже MS в эту сторону движется...
_>>Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение. WH>Если у нас есть бинбинг к реактивной view model то не нужно. WH>Все само заработает.
Я к тому что обычные средства "размётки контролов" из различных инструментов построения интерфейсов десктопных приложений подразумевают только именно размётку. Максимум там указываются имя функций обработчикив из основного (не dsl) кода, и то не всегда. А на самом деле это не правильно, т.к. значительная часть реакций на сообщения состоит опять же только из gui действий. Т.е. по идее при их обработке не надо вылезать из gui dsl в движок, написанный на основном языке. Т.е. что бы вызовы из gui dsl в основной код касались уже только непосредственно работы. Вот если бы был такой gui dsl, то был бы смысл на него перейти. А пока, все эти "просто размётки" никому особо не нужны — лишняя сущность. Например мы предпочитаем пользоваться GUI редактором, генерирующим код непосредственно на системном языке. Всё равно руками его никто не правит, так что лишняя сущность типа языка размётки (это же тоже типа dsl) вообще не нужна.
Здравствуйте, alex_public, Вы писали:
_>Нуу вот как раз для веба на мой взгляд какой-то новый gui dsl и не нужен. Там уже есть html+javascript — полноценная разметка и обработчики. Причём если взять всякие там jqueryui, то уже на уровне полноценного интерфейса.
По сравнению с MVVM это все очень неудобно.
Все эти ковыряния в ДСМ просто жуть с ружжом.
_>А вот как на счёт gui dsl для обычных приложений? Хотя я смотрю такими темпами html+javascript станет gui dsl и для десктоп приложений. Уже даже MS в эту сторону движется...
Глупости это.
_>Я к тому что обычные средства "размётки контролов" из различных инструментов построения интерфейсов десктопных приложений подразумевают только именно размётку. Максимум там указываются имя функций обработчикив из основного (не dsl) кода, и то не всегда. А на самом деле это не правильно, т.к. значительная часть реакций на сообщения состоит опять же только из gui действий. Т.е. по идее при их обработке не надо вылезать из gui dsl в движок, написанный на основном языке. Т.е. что бы вызовы из gui dsl в основной код касались уже только непосредственно работы. Вот если бы был такой gui dsl, то был бы смысл на него перейти. А пока, все эти "просто размётки" никому особо не нужны — лишняя сущность. Например мы предпочитаем пользоваться GUI редактором, генерирующим код непосредственно на системном языке. Всё равно руками его никто не правит, так что лишняя сущность типа языка размётки (это же тоже типа dsl) вообще не нужна.
Ты зря отмахнулся от тех ссылок, что я тебе дал.
Идеология Model-View-ViewModel доведенная до логического конца как раз и есть такой ДСЛ. View и ViewModel это ГУИ ДСЛ. Model это основной код.
Причем тебе в 99% случаях не придется возиться с обработчиками. Все будет гораздо проще. Посмотри примеры.
И никгда не придется из кода ViewModel лезть во View. Те никакой возни с ДОМ и прочих ужОсов.
Мы просто мапим ViewModel на контролы, а система сама пересчитывает маппинг если ViewModel меняется. Таким образом, если мы хотим что-то изменить, то просто меняем ViewModel. Контролы перестроятся сами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>А нахрена когда есть уже готовые специалисты "общего назначения"? WH>Ответ в первом сообщении темы.
Это не ответ, это попытка уйти от реальности.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Хвост, Вы писали:
Х>я вот чот не вдупляю чем твои дсли лучше либы/пекейджа/сборки с набором неймспейсов/классов/функций, специфичных для этого самого domain? тем что у них fancy синтаксис? ололошеньки.
А ты попробуй в либу/пекейдж/сборку запихни HTML или SQL
Только с другой стороны, если язык будет позволять менять синтаксис, встраивать в себя HTML, SQL, абракадабру Васи Пупкина, блабладсл Пети из соседнего отдела и т.д. Бедному программисту Ване Иванову, только принятому на работу, придется учить все эти супермегаязыки.
Давайте немного отвлечемся. Представьте, каждый композитор, придумывает свою нотную нотацию, удобную только ему. Новому музыканту, чтобы сыграть его произведение, нужно будет изучить для начала его нотацию. Чтобы сыграть произведение другого композитора, нужно будет изучить новую нотацию и т.д.
Необходимость в общем языке нужна, как можно более универсальном, но с другой стороны польза от DSL тоже крайне важна. Это наглядно демонстрируют HTML, SQL, и прочие DSL'и.
Но мне видится оптимальным как раз такой симбиоз, general purpose language + external DSL (что мы на сегодняшний день и наблюдаем).
Мне крайне не нравится подход по максимуму нагрузить general purpose language, например, прибитый гвоздями в C# linq.
Мне крайне не нравится подход делать general purpose language с изменяемым синтаксисом, т.к. оно противоречит его природе general.
Подход Немерле изолировать DSL в отдельные сборки интересен, но на практике сильно не опробован (я имею большие команды, большие проекты).
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Здравствуйте, __lambda__, Вы писали:
___>Подход Немерле изолировать DSL в отдельные сборки интересен, но на практике сильно не опробован (я имею в виду большие команды, большие проекты).
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VoidEx, Вы писали:
VE>>А как бы стоило сделать на твой взгляд? WH>Никак. Языки общего назначения не имеют смысла. WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
WH>Вот буквально только что презенташка попалась. WH>http://suif.stanford.edu/~jwhaley/PLDITutorial.ppt WH>http://bddbddb.sourceforge.net/index.html WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора). WH>ДСЛ работал в 2 раза быстрее. Плюс на этом ДСЛ еще кучу кода, потом понаписали. Как следствие сэкономили десятилетия работы. WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.
WH>А для распространённых задач ДСЛи уже будут написаны.
Это "день потерять, за пять минут долететь"
Я практикую embedded DSL в таких языках как scala, nemerle — "пять минут потерять, потом за пять минут долететь". Это еще круче.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается. G>>Да, но почти всегда он довольно ущербен
AVK>Это с чем сравнивать. Как минимум, по мощности он обычно сопоставим с голым SQL, но работает в терминах прикладных метаданных, а не в терминах метаданных БД. Типичный пример — Entity SQL в EF.
eSQL не пример DSLя корпоративной системы. Кстати он сам очень ущербен, по сути умеет даже меньше, чем можно в Linq написать.
А ты сравни с запросами в SharePoint или CRM.
Там дофига усилий надо приложить чтобы простой запрос родить. При этом в случае CRM все это напрямую мапится на таблицы\колонки.
Получается что DSL усложняет решение, но дает программисту оставаться в контексте системы, обеспечивая некоторый уровень целостности и, возможно, обратной совместимости.
G>> и по сути нужен чтобы не дать программисту нарушить целостность платформы. AVK>Не только. Он нужен прежде всего чтобы писать запросы, по возможности не вдаваясь в подробности хранения данных в конкретной БД.
Дальше ER модели никто из них пока не ушел, так что по мощности они на уровне SQL. Некоторые правда допускают предикаты типа "Was Ever" или работы с особыми типами, но это скорее исключение, чем правило.
