programming-languages - programming - tiobe software bv

Lenguajes específicos de dominio vs. biblioteca de funciones (8)

Esto puede ser subjetivo, no lo sé: tengo este problema, que estoy equiparando al "¿qué lenguaje para este proyecto?" Pregunta, ya que parece que no puedo resolverlo.

Me encargaron escribir un libro sobre un determinado dominio (digamos una rama muy específica de la física) para una comunidad con conocimientos técnicos, pero que no son programadores. Es un libro sobre este subconjunto de algoritmos que utilizan día tras día.

Para esto, dada mi audiencia, he estado jugando con la idea de definir un DSL, en lugar de hacer que aprendan el idioma X, y discutir los algoritmos desde este punto de vista, en lugar de hacerlo en un idioma determinado o en un pseudocódigo.

La pregunta es, entonces: ¿cuáles son algunas indicaciones de que lo que necesita es un DSL en lugar de una biblioteca de funciones a las que se debe llamar desde un lenguaje bien establecido y de propósito general?

Gracias.

EDIT : sugerencias hasta ahora a favor de DSL:

Escudo de la complejidad del lenguaje de propósito general.
Hacer "programador" más productivo en su dominio.
Haga que los conceptos del lenguaje sean altamente intuitivos para los novatos en la programación. (Sólo pensé en esto ahora)

Tu audiencia no son programadores.
Usted está apuntando a un campo específico.
Necesitan hacer el trabajo.

Elegiría un DSL sobre un lenguaje de propósito general.

Creo que dependerá de escribir un DSL y lenguajes de programación funcionales, ya que, según mi experiencia, los físicos tienden a ser bastante competentes en Fortan o Matlab.

Es posible que desee probar esos idiomas para sus ejemplos, ya que le permitirá ingresar a los algoritmos, ya que puede ayudar a aquellos que son más técnicos.

Como mencionó Mitch Wheat, los DSL son buenos cuando desea ocultar los detalles al usuario.

En última instancia, lo vería de esta manera: un DSL (como cualquier lenguaje de programación) es un conjunto de tokens e idiomas léxicos que puedes usar para explicar cómo hacer algo. Implícito dentro de ese conjunto de tokens es un conjunto de expresiones idiomáticas.

La idea de cualquier idioma es que seleccione uno apropiado que facilite la expresión de los algoritmos esperados.

Un buen ejemplo son los lenguajes de informe (por ejemplo, Natural). Esto se debe a que los informes tienen expresiones idiomáticas comunes como grupos, condiciones de ruptura, etc. Cualquiera que haya hecho eso en un lenguaje de propósito general le diría que puede ser realmente tedioso hacer cosas como condiciones de descanso, pero ciertamente es posible.

Entonces, la pregunta que debe hacerse es la siguiente: ¿existen expresiones comunes que sean tediosas, difíciles o extremadamente verbosas de expresar en un lenguaje de propósito general? También debería preguntar: ¿existe algún subconjunto particular de funcionalidades en el que esté más interesado que se beneficie al convertirlo en un concepto de lenguaje? Esto podría ser cosas como vectores y matrices para el álgebra lineal (con las operaciones apropiadas) o lo mismo para el cálculo integral / diferencial o las ecuaciones diferenciales.

Lo que realmente le gustaría tener al final con un DSL es donde, digamos, un programa de 500 líneas podría expresarse como 50-100 líneas de su DSL y esto se aplica a la mayoría de los algoritmos "esperados". Supongo que es un poco como la normalización en el modelado de datos, donde el objetivo es eliminar los grupos que se repiten. Escribir las mismas 10-20 líneas de código con una pequeña variación sugiere un lenguaje común.

En cuanto a una biblioteca de funciones, esa es una vista más limitada de la misma cosa (en última instancia), excepto que una biblioteca de funciones es simplemente un paquete de comportamientos diferentes. Eso supone que usted define una biblioteca de funciones como eso y no incluye jerarquías de objetos complejos, cierres, etc. Si lo hace, entonces la línea entre una "biblioteca de funciones" y un DSL está borrosa.

Pensaría en una biblioteca de funciones como, por ejemplo, el conjunto de funciones matemáticas que existen en la mayoría de los idiomas modernos (pecado, cos, raíz cuadrada, etc.). Así que supongo que todo se reduce a:

Paquetes de código -> biblioteca de funciones
Modismos comunes -> DSL

Pienso que el propósito de un DSL era abstraer detalles y permitir que un programador (o implementador) sea productivo manteniendo su cabeza en el dominio, por así decirlo.

Si desea explicar los detalles de una colección de algoritmos, me quedaría con uno de los sospechosos habituales (C ++?).

Una consideración importante es si su audiencia ya usa predominantemente un solo idioma. Si es así, la elección se ha hecho por usted!

Otra cosa que tal vez quiera considerar, es que al elegir un lenguaje popular popular, su libro es aplicable a una audiencia más amplia, sin tener que "aprender" un DSL.

Puede elegir un DSL para que coincida exactamente con el dominio con el que está tratando. Los programadores pueden sentirse cómodos con un lenguaje de propósito general y aplicarlo en muchas situaciones. Sus no programadores pueden beneficiarse de un lenguaje que sea directamente relevante para ellos. También puede ser más fácil para ellos entender si las palabras clave y los conceptos coinciden con su experiencia.

Como la mayoría de las cosas, es una compensación. Un DSL debería ser más fácil para su audiencia, pero podría ser más trabajo para usted.

Puede usar un DSL para desacoplar un conjunto de operaciones relacionadas del idioma de llamada.

Si desea proteger a sus usuarios de la complejidad del lenguaje de propósito general (o restringir su acceso a ese idioma porque podrían abusar de él), diseñe un DSL.

Pero si desea que las operaciones se utilicen de una manera integrada con el idioma de llamada, utilice una biblioteca de funciones (u otros operadores).

Tiene que sopesar el grado en que puede proporcionar una notación más limpia contra el hecho de que nadie comenzará a conocer la notación que utiliza. En teoría, es posible que pueda seguir la notación que este grupo usa en general tan bien que es "intuitivamente obvio", pero a menos que sean diferentes de la mayoría de los físicos, eso probablemente no funcionará bien. Muchos usan cosas como los caracteres griegos y / o hebreos que no están presentes en un teclado típico.

Si utiliza un DSL, ¿está preparado no solo para implementarlo, sino también para pasar una buena parte de su vida manteniéndolo? ¿Tiene los recursos para ir más allá del lenguaje adecuado y proporcionar el tipo de infraestructura para que se convierta en una herramienta de desarrollo útil? Si se va a utilizar para un desarrollo real, probablemente necesitará un depurador. También es posible que desee considerar un nuevo IDE (si es realmente diferente) o adaptar un producto existente para que funcione (por ejemplo, crear un modo especializado para emacs o un complemento para Eclipse).

Si inventas un DSL, ¿qué tan probable es que la gente realmente lo use? Si ya hay algo completamente arraigado, desplazarlo probablemente será bastante difícil. Crear un nuevo lenguaje que llene un vacío es mucho más fácil que reemplazar algo que ya está en uso. Por otro lado, si realmente hay un vacío, esto puede indicar que simplemente no hay mucho mercado; es posible que su audiencia no esté particularmente interesada en convertirse en desarrolladores de software.

Usa psuedo-code para explicar tus algoritmos. Eso sería más genérico que usar un lenguaje de programación de propósito general con API de biblioteca.

¿Qué tan complejo crees que tendrá que ser tu DSL? ¿Tomará mucho para que los lectores se familiaricen con él?

Aunque podría llenar la parte de atrás de su libro con el código fuente de la biblioteca para llenar esas páginas.