language agnostic - lenguaje - ¿Para qué tipo de problemas escribes un DSL?

lenguaje dsl

Question

Solo tengo curiosidad por los lenguajes específicos del dominio. Los he visto varias veces en artículos, y parece que pueden usarse fuera de la seguridad o problemas de definición de datos bancarios.

Así que vengo a SO para tener algún aporte concreto.

¿Alguna vez usaste un DSL? Escribe uno. Si es así, ¿cómo se siente?

¿Cree que uno de sus proyectos podría ser mejor (más productivo, más fácil de mantener, ...) con un DSL?

Edit: Siento poner esto después, pero me refería a un DSL específico que usted mismo escribió. Es excluir Tex, HTML, Make, SQL. De hecho, la pregunta era más: "escribir un DSL"

Answer 1

¿Qué tal BNF como un DSL para generadores de analizador?

Answer 2

Creo que el DSL que la mayoría de nosotros usamos con mayor frecuencia es SQL, un pequeño lenguaje para la manipulación y extracción de datos.

Answer 3

Dos usos recientes de un DSL:

1. Uso de la biblioteca de construct , que básicamente define un DSL para describir estructuras binarias de datos (como formatos de archivo) y protocolos.
2. Implementando un DSL basado en Python para verificar el hardware. Este DSL presenta toda la infraestructura necesaria para escribir pruebas como "funciones de escenario" que pueden usar los componentes DSL subyacentes.

Answer 4

En mi experiencia, cualquier organización de ingeniería de software creará DSL en respuesta a problemas repetidos y al exceso de código de plantilla que se está escribiendo. Un breve extracto de mi experiencia personal:

• Compiladores de sistema de reescritura de abajo hacia arriba del compilador
• Generadores de ensamblador
• Generadores de código de objeto (implementados como una biblioteca C ++ con sobrecarga de operadores)
• Generador de simulador de CPU
• Dispositivo simulador modelo generador.
• Lenguajes de línea de comandos para herramientas interactivas

También tenga en cuenta que muchos formatos de archivo pueden considerarse DSL si lo observa detenidamente.

Hubo un buen artículo de Mark Shapiro en ACM Queue hace un tiempo sobre este fenómeno también.

Otro ejemplo más es la forma en que los usuarios terminan escribiendo grandes programas en cosas que no están destinadas a ello ... como bancos de prueba que usan el antiguo lenguaje de scripting del depurador "SNIFF".

Answer 5

En realidad, usas DSL casi todos los días sin saberlo ... HTML, make, XML, latex y muchos muchos idiomas de configuración ...

Me gusta tener un DSL declarativo que genera un montón de cosas ... Se siente bien ...

El impacto de un DSL es interesante pero realmente difícil de evaluar ... Si su DSL está bien diseñado para la comunidad objetivo (la comunidad objetivo es un punto realmente importante ...) en términos de lo que esta comunidad espera y hace bien el trabajo que se supone que debe hacer, se sentirá bien ...

Sin embargo, si diseñas un DSL sin conocer a la comunidad o si necesitan luchar constantemente con las limitaciones del idioma (un DSL aún puede estar completamente completo ...), va a doler ...

Answer 6

Esta podría ser una pregunta antigua, pero la pregunta en el título (en lugar de en el cuerpo) no ha sido respondida por nadie:

Hay dos instancias (dobles) en las que tiene sentido escribir un DSL:

• Cuando el dominio del problema se entiende muy bien y tiene vocabulario preexistente de sustantivos (objetos), verbos (acciones, combinadores, etc.) y adjetivos (atributos, modificadores).
• Cuando la solución-dominio se entiende muy bien y ...

Las expresiones regulares son un buen ejemplo de lo primero, mientras que los ensambladores-generadores son lo segundo. El lenguaje de programación de propósito general está ahí para el resto: cuando ni el dominio del problema ni el dominio de la solución se comprenden bien, las herramientas generales deben ponerse en práctica.

Answer 7

Fui una de las personas que trabajó en NUnit versión 2.0 y superior durante algunos años. Es un DSL escrito usando atributos de C # para describir pruebas unitarias. No es el ejemplo más obvio de un DSL, pero he llegado a considerarlo como uno. He escrito otros usando ANTLR e incluso MGrammar. La experiencia suele ser la misma. Tan pronto como se lo muestres a alguien más, ellos quieren hacer un montón de cosas que nunca pensaste. Eso es bueno, pero tienes que estar preparado para seguir adelante y agregar funcionalidad.

Ahora tengo la costumbre de pensar y escribir DSL con bastante frecuencia. El actual mapeador relacional de objetos que uso es un dsl. No es un lenguaje nuevo. Es puro C #, pero al pensar en el idioma del dominio, y ese dominio es más que un dominio de negocios, creamos un mini idioma para asignar objetos. Pensar en términos de DSL ha cambiado nuestro enfoque de la API y la creación de marcos.

Answer 8

Los DSL creados con Visual Studio DSL Toolkit se pueden usar para generar cualquier artefacto basado en texto a partir de una instancia del modelo de dominio definido por el DSL. Por supuesto, al estar dentro de Visual Studio en ese momento, si hay un compilador u otro procesador para el artefacto de texto, entonces puede ejecutarse automáticamente.

Algunos ejemplos son

• NORMA , un DSL para modelado de dominios conceptuales, basado en la notación de modelado de objeto-rol (ORM2)
• Web Service Software Factory , que utiliza tres DSL para modelar servicios web
• Diseñador de la sección de configuración : se utiliza para definir el esquema de los archivos de configuración XML y para generar las clases para exponer los datos de ellos.

Y, por supuesto, puedes crear el tuyo propio.

Answer 9

SQL es un buen ejemplo que dio Michael Dorfman . Otros que he usado extensivamente son:

• UIL - Edificio GUI
• Make - programa de construcción e instalación
• regexp - Coincidencia de patrones de cadena
• lex y yacc - analizador léxico y creación de compiladores

En cuanto a cómo funciona, creo que depende del idioma y el dominio. UIL es increíble para especificar GUI''s. Si hace lo mismo en el código Motif en línea, los errores de especificación de la GUI de que el compilador UIL se ve como un código perfectamente compilable para un compilador C o Ada. Eso hace que se pierda mucho más tiempo en la depuración. Además, simplemente luce más feo en el código de propósito general que usa las llamadas de Motif API.

Make puede llegar a ser una pesadilla, pero no hay muchas herramientas que puedan hacer lo que hace, y sospecho que todas tienen el mismo problema.

Las expresiones regulares son innecesarias para tareas muy simples y una pesadilla para las realmente complejas. Para aquellos en el medio, son una herramienta maravillosa.

Lex y yacc pueden ser muy útiles. Sin embargo, una persona que sabe lo que está haciendo puede crear analizadores y analizadores léxicos a mano con aproximadamente la misma cantidad de trabajo.

Answer 10

Todavía soy un estudiante, pero estoy realmente fascinado con el spirit

Lo he usado un poco a lo largo de mi curso de ''lenguajes de programación''. Así es como funciona, básicamente estás escribiendo EBNF.

texto alt http://img6.imageshack.us/img6/1461/reala.png

se convierte en esto en C ++ ;)

texto alternativo http://img6.imageshack.us/img6/8809/dsl.png

Answer 11

Tu pregunta está bastante bien sincronizada. Recientemente he escrito un DSL usando la herramienta Antlr . Antlr es un generador de analizador / lexer.
Permite la fácil construcción de DSL (y muchas otras cosas) y cuando se combina con StringTemplate (escrito por la misma persona) se vuelve muy poderoso en la generación de código. También puede apuntar a múltiples idiomas. Nuestro analizador y lexer está en C # (uno de los objetivos) aunque el valor predeterminado es Java.

Uno de los numerosos beneficios de Antlr son los mensajes de error descriptivos y el IDE / depurador (AntlrWorks) que le permite avanzar en su gramática y ver los árboles AST visualmente.

John Saunders sugirió a continuación el uso del kit de herramientas DSL de Visual Studio. En última instancia, encontré que esas herramientas están muy lejos de restringirse. Requerir una GUI, sin ninguna capacidad para describir fácilmente una gramática textual subyacente, simplemente parece ser inadecuado para mis necesidades.

Junto con el analizador / lexer DSL, también he escrito un servicio de Visual Studio Language, para proporcionar inteligencia, resaltado de errores, finalización de código y elementos / proyectos de plantillas.

Incluso si no implementas los extras, un DSL puede simplificar el trabajo repetitivo. Mi DSL apunta específicamente al marco CSLA , generando objetos de negocios fácilmente con toda la tubería, permitiendo a los desarrolladores preocuparse únicamente por la lógica de negocios.

Aquí hay un pequeño ejemplo de la DSL:

datadef Object1Datadef
{

   tables
   {
      MyTable:PK[MyTableID], column1, column2;
   }

}

root MyObject
{
    datadef Object1Datadef;

    read "all";
    write "admin", "superusers";

    int _Myvariable;    

}

Si su DSL le permite describir su dominio más rápido, más fácilmente y aumenta la productividad, entonces vale la pena.

Answer 12

Yo diría que hay bastante continuidad entre una API muy legible como una forma débil de DSL (lo que algunos llaman una interfaz fluida), un DSL interno como algo intermedio y un DSL externo completo definido por gramática en el otro extremo.

La forma más débil es algo que siempre trato de lograr (es decir, hacer que la API esté lo más cerca posible del dominio del problema). Un DSL en el otro extremo del continuo tiene mucho sentido si los no programadores utilizarán el software, por ejemplo, para ingresar datos.

Y con un marco como Xtext incluso un DSL externo completo, incluir un editor que Xtext sintaxis y la verificación de errores es mucho más fácil de implementar de lo que parece inicialmente.