Buscando evidencia científica de los beneficios de usar un DSL
https://stackoverflow.com/questions/1625608
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
La charla de Greg Wilson "pedazos de evidencia" ( http://www.slideshare.net/gvwilson/bits-of-evidence -2338367 ) discute la falta de evidencia detrás de las siguientes afirmaciones de que Martin Fowler ha avanzado como beneficios de usar un DSL:
" [usando un lenguaje de dominio específico] conduce a dos beneficios principales. El primero y más simple es la productividad mejorada del programador. El segundo ... es ... comunicación con expertos en dominios. - Martin Fowler en IEEE Software julio / agosto de 2009
Pregunta: ¿Hay algún estudio empírico que proporcione evidencia de una mejor productividad del programador o una mejor comunicación con expertos en el dominio del uso de un DSL?
Mucha gente que construye DSL no puede proporcionar una respuesta razonada a "¿por qué está construyendo un DSL?" y "¿por qué un DSL le ayudaría más que un modelo de objetos bien factorizado?" Escucho mucho "Lo estoy haciendo porque es genial y todos los demás lo están haciendo" - lo cual no es una respuesta racional. Creo que las DSL son útiles al menos parte del tiempo, pero que no es probable que sean una "bala de plata". eso debería ser usado indiscriminadamente. Me gustaría ver algunos trabajos científicos que describan cuándo se deben y no se deben usar las DSL, según la investigación empírica.
Solución
Buscando en Google, encontré un par de artículos interesantes:
Idiomas específicos del dominio en la práctica: Un estudio de usuario sobre los factores de éxito
Y me imagino que podría encontrar algunas referencias mejores a partir de Google Scholar ...
Otros consejos
Depende de lo que consideres que es un DSL.
Por ejemplo, ¿es css un DSL? Creo que sí, entonces obviamente puede facilitar el diseño de una página, ya que en HTML 3 usamos tablas para los arreglos y no teníamos la flexibilidad que tenemos ahora.
Si tiene un DSL para que los estudiantes puedan diseñar moléculas usando solo los símbolos atómicos (H20), entonces sería más simple que hacer la codificación usted mismo, ya que puede ver rápidamente la configuración molecular si proporciona los símbolos y tipos de vinculación, por ejemplo.
No conozco un documento que muestre de una forma u otra, pero, si su público objetivo no son programadores, entonces un DSL tiene sentido, por lo que podemos hacer que los contadores escriban su solicitud, utilizando su terminología, en lugar de tenerlos dar requisitos a los desarrolladores.
Las DSL han existido durante mucho tiempo, pero ahora se están volviendo más populares, por lo que el tiempo dirá cuándo hay más ejemplos de usos buenos y malos en cuanto a cuándo es mejor usarlo y cuándo es realmente perjudicial. No escribiría software de monitoreo médico con ningún DSL, por ejemplo.
Toda la premisa de "científico" En este caso es dudoso. Simplemente no hay forma de garantizar los criterios de "reproducible", "control (grupo)". requerido para un estudio empírico.
En general, en la programación empresarial no hay estudios empíricos serios sobre los beneficios de algo antes de su uso. Ya sea SQL, lenguajes orientados a objetos, lenguajes funcionales, recolección de basura, etc.
Estas cosas tienden a ser decididas por el mercado con el tiempo.
Por qué este es el caso es probablemente una combinación de dos razones. Una es que es muy costoso obtener un buen estudio empírico y es mucho más barato desde un punto de vista económico simplemente intentarlo. La otra es que cada situación es diferente, por lo que un estudio empírico tendría que comenzar limitando el problema en estudio de manera muy estrecha para tener una comparación adecuada entre usar un DSL y no usar uno, y el resultado final del estudio no sería muy útil más allá del tipo específico de problema que se eligió.
Creo que podemos decir con seguridad por experiencia que nada es una bala de plata, e insistir en una buena razón para un enfoque mejorará cualquier solución, porque incluso si un DSL ayudaría a una situación, si no sabe por qué lo está haciendo, no sabrá si lo está haciendo bien y puede terminar perdiendo todo el beneficio.
Esta es una pregunta sensata, y creo que hay problemas de definición, como "¿qué es un DSL?" Cuando una palabra de moda se vuelve "caliente" se convierte en una oportunidad de marketing y se divorcia de la ciencia subyacente, si hay alguna.
Hace algunos años, escribí un libro (Building Better Applications, ISBN 0-442-01740-5, que ya no se imprimía) en el que intentaba analizar el rendimiento, no solo de los programas, sino también de los programadores. Traté de verlo usando la teoría de la información.
Se me ocurrió una medida cruda de mantenibilidad, donde existe un problema como una estructura de conocimiento en la cabeza de alguien (no hay problema para que un tipo de IA lo diga), y su solución existe como una estructura textual procesada por una máquina. Lo que miro es la relación entre estas dos estructuras. Por ejemplo, si se produce un cambio en la descripción del problema mental, ¿cuántos cambios en el código fuente se requieren para transferirlo al texto del programa correctamente? Una forma simple de medir es diferir el código entre antes y después. Ahora, promedie esa medida sobre el espacio de cambios que es probable, y cuanto menor sea el promedio, más fácil de mantener es el código fuente.
Mi tesis fue que cuanto más fácil de mantener el código es, según esa medida, más se parece al modelo mental del dominio, por lo que es razonable llamarlo más "orientado a problemas". o más "específico de dominio". Una característica que noté de dicho código es que tiende a ser más una declaración del problema, en lugar de una solución del problema. La solución no reside en el lenguaje, sino en la implementación del lenguaje, la subestructura. Este es un eco, aunque no un acuerdo directo, con el concepto de "declarativo". frente a "imperativo" idioma.
Entonces, al tratar de responder a su pregunta, yo diría que nos alejemos de lo que la gente podría querer "DSL" significar y, en cambio, mirar una definición que sea al menos moderadamente inequívoca.
Como parte del desarrollo de esa idea, me topé con varias técnicas, una de las cuales es Ejecución diferencial , que parece ofrecer una buena capacidad de mantenimiento para codificar interfaces de usuario, y también reduce el tamaño del código fuente en aproximadamente un orden de magnitud. Mi teoría es que ese es un ejemplo exitoso de lo que podría ser un DSL.
No pretendo que la mantenibilidad se pueda lograr sin que el mantenedor tenga que subir una curva de aprendizaje. Creo que la mantenibilidad real tiene un precio para los programadores que tienen que aprender cosas que pueden no ser fáciles de entender, pero que una vez comprendidas tienen el valor deseado.
De los lingüistas Saphir y Worf, podemos aprender que las características gramaticales de un idioma influyen en nuestro pensamiento = si crea un DSL, estará pensando más en un dominio específico y probablemente en un propósito menos general. Se trata de abstracción, al igual que los lenguajes de programación de propósito general tienden a abstraerse de la máquina, por lo que podemos centrarnos más en algoritmos, estructuras y diseño que en el conjunto de instrucciones, modos de direccionamiento, tamaños de registro, etc.
No estoy tan seguro de que alguien haya hecho ningún estudio en la medida en que lo necesite. Sin embargo, mi experiencia es que crear un DSL puede ser costoso en primer lugar (posiblemente 2 veces o más esfuerzo que un modelo de objeto más simple para hacer lo mismo). Sin embargo, una vez creados, los desarrolladores obtendrían un beneficio inmediato al poder hacer las cosas más rápido con el DSL que con el modelo.
El problema con la pregunta es que trata todos los DSL como iguales. Algunos serían más fáciles de implementar, otros más difíciles, ya sea que uno esté haciendo interfaces fluidas / DSL internas o DSL externas conduciría a diferentes tiempos / costos de implementación.
El principal beneficio que podría no estar cubierto por tales estudios es la facilidad con que un DSL puede llevar a expresar e implementar código. También puede ayudar a otros a comprender la intención del código, posiblemente más fácil, y dado que la fase de mantenimiento del ciclo de vida del desarrollo de software es un componente tan importante del SDLC, esto podría generar beneficios mucho mayores (a largo plazo) que los que inicialmente se pierden al crear el DSL .
