Сообщение Re[4]: За счет чего выстреливают языки? от 14.07.2015 19:41
Изменено 14.07.2015 19:50 Геннадий Васильев
Здравствуйте, jazzer, Вы писали:
ГВ>>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
J>Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL.
J>Другой хороший пример DSL — описания грамматик для парсера.
J>Еще один хороший пример DSL — UML (например, для описания конечного автомата).
J>И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
J>Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт.
J>В данном случае "каждый" — это каждая команда.
J>Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
В принципе, не бесспорно, но в основном согласен. Однако, обрати внимание — почти во всех перечисленных тобой случаях хорошо очерчена задача, которую решает та или иная система, и эта задача выходит за пределы собственно построения DSL:
— Регэкспы — анализ текста по регулярным выражениям (принципы анализа, скорость разбора, а потом уже способ записи);
— Грамматики — построение анализатора для другого языка (как строить, из каких примитивов и т.п.);
— UML — опять таки, сначала ставится задача переноса конструктивных элементов UML на код, а потом уже — форма записи в текстовом виде;
— Математика — ну, здесь ещё более или менее, хотя сама по себе задача не сказать, чтобы очень распространённая;
— API — здесь понятно, сначала строится сама библиотека для каких-то отвлечённых (от DSL) целей.
То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. Отсюда попытка сместить акценты в сторону самого построения DSL приводит слушателей, скажем так, в замешательство, т.к. контекст расширяется, и получается то, о чём я написал выше:
ГВ>>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
J>Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL.
J>Другой хороший пример DSL — описания грамматик для парсера.
J>Еще один хороший пример DSL — UML (например, для описания конечного автомата).
J>И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
J>Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт.
J>В данном случае "каждый" — это каждая команда.
J>Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
В принципе, не бесспорно, но в основном согласен. Однако, обрати внимание — почти во всех перечисленных тобой случаях хорошо очерчена задача, которую решает та или иная система, и эта задача выходит за пределы собственно построения DSL:
— Регэкспы — анализ текста по регулярным выражениям (принципы анализа, скорость разбора, а потом уже способ записи);
— Грамматики — построение анализатора для другого языка (как строить, из каких примитивов и т.п.);
— UML — опять таки, сначала ставится задача переноса конструктивных элементов UML на код, а потом уже — форма записи в текстовом виде;
— Математика — ну, здесь ещё более или менее, хотя сама по себе задача не сказать, чтобы очень распространённая;
— API — здесь понятно, сначала строится сама библиотека для каких-то отвлечённых (от DSL) целей.
То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. Отсюда попытка сместить акценты в сторону самого построения DSL приводит слушателей, скажем так, в замешательство, т.к. контекст расширяется, и получается то, о чём я написал выше:
это что, каждый на своём языке будет писать?
Re[4]: За счет чего выстреливают языки?
Здравствуйте, jazzer, Вы писали:
ГВ>>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
J>Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL.
J>Другой хороший пример DSL — описания грамматик для парсера.
J>Еще один хороший пример DSL — UML (например, для описания конечного автомата).
J>И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
J>Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт.
J>В данном случае "каждый" — это каждая команда.
J>Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
В принципе, не бесспорно, но в основном согласен. Однако, обрати внимание — почти во всех перечисленных тобой случаях хорошо очерчена задача, которую решает та или иная система, и эта задача выходит за пределы собственно построения DSL:
— Регэкспы — анализ текста по регулярным выражениям (принципы анализа, скорость разбора, а потом уже способ записи);
— Грамматики — построение анализатора для другого языка (как строить, из каких примитивов и т.п.);
— UML — опять таки, сначала ставится задача переноса конструктивных элементов UML на код, а потом уже — форма записи в текстовом виде;
— Математика — ну, здесь ещё более или менее, хотя сама по себе задача не сказать, чтобы очень распространённая;
— API — здесь понятно, сначала строится сама библиотека для каких-то отвлечённых (от DSL) целей.
То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. Отсюда попытка сместить акценты в сторону самого построения DSL приводит слушателей, скажем так, в замешательство, т.к. контекст расширяется, и получается то, о чём я написал выше:
Update: Собственно, в качестве примера DSL ещё неплохо приводить лисповский LOOP и лисповский же FORMAT. Вот уж, где собрано всё, что могло присниться и привидеться, но опять таки, оба этих "языка" заточены под конкретную задачу и сам по себе язык не сказать, чтобы представлял какую-то особую проблему.
ГВ>>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
J>Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL.
J>Другой хороший пример DSL — описания грамматик для парсера.
J>Еще один хороший пример DSL — UML (например, для описания конечного автомата).
J>И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
J>Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт.
J>В данном случае "каждый" — это каждая команда.
J>Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
В принципе, не бесспорно, но в основном согласен. Однако, обрати внимание — почти во всех перечисленных тобой случаях хорошо очерчена задача, которую решает та или иная система, и эта задача выходит за пределы собственно построения DSL:
— Регэкспы — анализ текста по регулярным выражениям (принципы анализа, скорость разбора, а потом уже способ записи);
— Грамматики — построение анализатора для другого языка (как строить, из каких примитивов и т.п.);
— UML — опять таки, сначала ставится задача переноса конструктивных элементов UML на код, а потом уже — форма записи в текстовом виде;
— Математика — ну, здесь ещё более или менее, хотя сама по себе задача не сказать, чтобы очень распространённая;
— API — здесь понятно, сначала строится сама библиотека для каких-то отвлечённых (от DSL) целей.
То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. Отсюда попытка сместить акценты в сторону самого построения DSL приводит слушателей, скажем так, в замешательство, т.к. контекст расширяется, и получается то, о чём я написал выше:
это что, каждый на своём языке будет писать?
Update: Собственно, в качестве примера DSL ещё неплохо приводить лисповский LOOP и лисповский же FORMAT. Вот уж, где собрано всё, что могло присниться и привидеться, но опять таки, оба этих "языка" заточены под конкретную задачу и сам по себе язык не сказать, чтобы представлял какую-то особую проблему.