¿Cuándo debo usar un lenguaje específico de dominio? [cerrado]

Question

Me gustaría recibir orientación práctica sobre cuándo debería usar un Lenguaje específico del dominio . He encontrado recursos sobre ventajas y desventajas, pero ¿qué tipo de proyecto justificaría su uso?

Parece que hay una gran inversión en tiempo para crear y mantener un DSL, así que, ¿en qué espacio de la aplicación obtendré un retorno de la productividad de mi inversión de tiempo?

Editar: Parece que el uso más común de DSL es para formatos de archivo para el estado de datos persistentes, ¿qué pasa con el uso de un DSL para la lógica y estructura del programa (quizás generación de código)? ¿Cuándo es esto factible?

Editar # 2 Principalmente pregunto cuándo vale la pena crear un DSL específico. Por supuesto, deberíamos utilizar los DSL existentes tanto como sea posible para ahorrar tiempo.

Answer 1

Hay muy pocas buenas razones para crear otro DSL. El mundo está lleno de lenguajes especiales.

Piensa junto con estas líneas.

1. Resuelve el problema con un lenguaje de propósito general como Python, Java, C ++ ... lo que sea.

2. Optimice esa solución para eliminar las características comunes y crear una biblioteca de clases realmente agradable, realmente elegante y realmente extensible.

3. Optimice esa biblioteca de clases para enfatizar "ortogonalidad". Asegúrese de que todas las funciones funcionen bien juntas, sin ningún problema.

4. Si solo necesita simplificar la sintaxis, cree un contenedor de secuencias de comandos alrededor de su bonita biblioteca de clases. Este es tu DSL. Para Python, esto es fácil, ya es un lenguaje dinámico. Para Java, hay cosas que puede aprovechar. Para C ++ puede ser un poco trabajo construir este entorno flexible de scripting.

5. Si aún necesita más optimización, considere escribir un compilador para su DSL.

Answer 2

El artículo Cuándo y cómo desarrollar lenguajes específicos del dominio proporciona consejos sobre solo este tema, al igual que el libro de Martin Fowler 2010 Idiomas específicos del dominio .

Answer 3

En primer lugar, me gustaría use un DSL cuando el dominio del problema contra el que se está desarrollando es un dominio ampliamente conocido, y algunos expertos en negocios de ese dominio ya han pasado por grandes longitudes para construir tal DSL para que no tenga que atravesar las longitudes usted mismo para resolver todos los problemas que ya han resuelto.

Si está pensando en creando una DSL, consideraría hacerlo si su negocio se realiza en un área muy particular y gasta la mayor parte de su tiempo centrado en un dominio de problema específico. Si rebota haciendo aplicaciones para dominios con múltiples problemas, entonces no recomendaría adoptar ese enfoque.

Por ejemplo, si su negocio es muy sencillo en la creación de solicitudes de impuestos, podría ser una buena idea construir un sistema tributario DSL. Esto permitiría que su idioma no solo sea utilizable por usted en sus diversas solicitudes de impuestos, sino que también sea comercializable (utilizable) por otras empresas de su industria que quieran hacer cosas similares que está logrando.

Por supuesto, debe sopesar los costos / beneficios de construir un DSL frente a un marco sobre un lenguaje ya existente.

Answer 4

Una situación que viene a la mente es cuando los requisitos requieren un nivel muy alto o improbable de personalización / configuración . Por lo tanto, proporcionaría una especie de modelo de secuencias de comandos contra un DSL.

Toma un ensamblaje de automóvil " brazo " por ejemplo, sería imposible proporcionar un modelo de configuración para admitir varias configuraciones de fábrica. (detectar esto, no detectar eso, cuando esto suceda, haga esto ... etc.)

Pero compilar una nueva aplicación con lógica especializada para cada cliente probablemente no sea un buen camino a seguir. Entonces, en este caso, crea un pequeño marco que se convertiría en una especie de DSL, y luego por cada brazo robótico que vende, escribe una pequeña aplicación en su DSL y la guarda junto con el software central que compila y ejecuta su DSL guiones en su lugar. O mejor aún, las herramientas para programar el DSL se incluyen junto con el brazo robótico para que su cliente pueda "programar". el brazo en el DSL que creaste.

Un ejemplo del mundo real que me viene a la mente es Yahoo Pipes (podría considerarlo un DSL) o la directiva robots.txt para rastreadores web automatizados, por ejemplo. Puede que no sean un DSL completo, pero demuestran dónde DSL podría ser útil.

Answer 5

Bueno, alguien tiene que decirlo, así que aquí va:

Algunos consideran que Lisp es el lenguaje específico del dominio para el dominio cualquier . Un DSL bien soportado y muy extensible.

En algunos casos, diseñar un DSL a partir de Lisp (o un lenguaje similar como Haskell) en realidad podría proporcionar mucha potencia con un mínimo esfuerzo y, por lo tanto, valdría la pena. Las DSL no siempre necesitan ser grandes cargas de mantenimiento.

Answer 6

Lo más obvio es que definitivamente debes usarlos cuando el idioma ya existe y está bien soportado. Los principales ejemplos de esto son UIL para el desarrollo de GUI basado en Motif y crear compilaciones de software.

Si tiene que hacer el suyo, yo diría que para buscar dominios se requiere un gran esfuerzo para especificar las cosas correctamente, y donde su compilador realmente no puede encontrar la mayoría de los errores, pero un compilador específico de dominio podría . Las GUI son un gran ejemplo, ya que la mayor parte del trabajo consiste en configurar el diseño, y generalmente hay muchas maneras de hacer llamadas C ++ sintácticamente válidas que no tienen ningún sentido para su sistema GUI subyacente (por ejemplo: tratar de incrustar un diálogo completo widget dentro de un botón).

Encuentro que UIL es particularmente una gran ganancia para el desarrollo de GUI porque un compilador de UIL puede encontrar errores en una especificación de GUI que solo parece un buen código compilable normal para un compilador de C ++. El hecho de que esté bien soportado significa que el código es fácil de transportar entre plataformas e incluso constructores de GUI.