Bajado del blog de Enrique Amodeo Rubio
Ingeniero en Informatica
Después del tocho sobre REST de la semana pasada, ahora toca cambiar de tercio. Seguramente algunos de vosotros habréis oído hablar de los DSL o Domain Specific Languages. En particular este es un tema en el que vengo trabajando desde hace años, y que me ha resultado bastante interesante y productivo.
¿Qué son los DSL? Simplemente podemos considerar como DSL cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Este conjunto específico de problemas es el llamado dominio de aplicación o de negocio. La mayor parte de los lenguajes de programación no se pueden considerar DSL ya que no están diseñados para resolver un conjunto específico de problemas, sino para resolver cualquier tipo de problema. Son pues, lenguajes generalistas (o turing completos).
El usar lenguajes generalistas ha tenido bastante aceptación y éxito hasta el día de hoy, de hecho poseen una ventaja indudable: con dichos lenguajes podemos resolver cualquier tipo de problema. Sin embargo esta ventaja no es gratis, al contrario, hay que pagar un precio, que es que no todos los problemas son igualmente sencillos de resolver. De hecho, dependiendo del lenguaje generalista que usemos, un mismo problema es más sencillo o más difícil de resolver. Es gracioso que se hayan producido muchas controversias por cual es el mejor lenguaje, cuando en realidad unos lenguajes son buenos para una cosa y malos para otra, y que los principales defensores de un lenguaje sólo tienen en cuenta las tareas en las que su lenguaje favorito es bueno. Normalmente suelen ser las mismas tareas que ellos se encuentran en su día a día laboral. Por ejemplo, trabajar con listas o hacer algoritmos recursivos es muy simple en LISP, sin embargo en BASIC o COBOL no es tan sencillo. Supongo que en cambio, con COBOL es sencillo definir algoritmos de negocio. Otro ejemplo, generar una página web dinámica es relativamente sencillo en PHP pero más complejo en JAVA. ¡ Eh ! Espera, en JAVA hacer una página web está tirado, pones una JSP y entonces… No hombre, el lenguaje JSP no es lenguaje JAVA, es un DSL…
Si cada lenguaje puede resolver cualquier problema, pero no todos con la misma sencillez, es lógico pensar que para cada problema que tengamos, podemos buscar el lenguaje que mejor se adapte a él. Al fin y al cabo, hay que usar la herramienta adecuada para cada caso. En su momento algunas mentes preeminentes se dieron cuenta de que el problema consistía precisamente en que los lenguajes generalistas eran demasiado ambiciosos al tratar de poder solventar cualquier problema. De hecho sería más adecuado poder contar con lenguajes especializados en solucionar los problemas que tuviéramos a mano. Es la misma diferencia entre tener un cuchillo multiuso para cualquier cosa, o un set de cuchillo de postre, de carne, de pescado y un bisturí y elegir los cuchillos que mejor nos vengan. Si sé que ese día voy a practicar una operación a corazón abierto, y después comeré pescado, mejor me llevo el bisturí y la paleta de pescado (para ser cirujano hay que tener el estomago muy fuerte).
De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (esperamos que el 20% o menos) solucionarlos con lenguajes generalistas. Algunos pensareis que esto de anticipar los problemas que voy a tener es un poco irreal, pues ni mucho menos. Desde el punto de vista puramente técnico, existen problemas que voy a tener que resolver casi siempre:
Aunque parezca mentira, ya existen algunos DSL que conviven con nosotros, pero tal vez no hemos pensado en ellos como tales. Algunos ejemplos:
No quiero que os quedeis con la idea de que los DSLs son cosas que resuelven problemas “técnicos”. Hasta el momento he mostrado lo que son los DSLs “técnicos”, pero es que también existen DSLs de negocio. Existen muchos dominios de negocio, podemos tener aplicaciones de banca, de inversión en bolsa, tiendas electrónicas, seguros, etc. Por supuesto cada área se puede subdividir en dominios más pequeños. Por lo tanto parece una buena idea el poder definir DSLs de negocio, que nos permitan especificar, de forma sencilla y eficaz, los distintos conceptos, reglas y validaciones, de un dominio de negocio concreto.
Así pues, desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:
Sin embargo el enfoque DSL ha tenido un resurgimiento al introducirse el concepto de DSL interno. Un DSL interno es mucho más sencillo de construir, no difiere mucho de construir un framework, tal vez se necesita una dosis extra de uso de reflexión y metaprogramación, pero al fin y al cabo no tenemos que andar con gramáticas y demás. Por otro lado, al no ser en realidad más que un API del lenguaje anfitrión, el IDE nos va a proporcionar ayuda. Ciertamente no todos los lenguajes son lo suficientemente flexibles como para permitir construir un DSL interno. Es casi imposible hacerlo en COBOL o en C (que yo sepa). En JAVA la dificultad es media. Pero en algunos lenguajes como Groovy, ¡resulta sencillo! En general cuanto más flexible sea el sistema de tipos del lenguaje y su sintaxis, y cuanta más capacidad de metaprogramación tenga, más sencillo construir un DSL interno. Lenguajes como Groovy o Ruby son ideales para esto, mientras que lenguajes con tipado fuerte suelen ser más problemáticos.
Sin entrar en como construir un DSL interno, veamos algunos ejemplos en Groovy:
No esta mal, ¿eh? ¿Quién quiere hacer lo mismo con JSP o JAXB?
Desde otro punto de vista, ya sea usando DSL externos o internos, una de las cosas más interesantes es hacer DSL orientados a negocio. Esto puede ser un paso adelante a la hora de solucionar un antiguo problema del software: la mala comunicación entre usuario y desarrollador. Tradicionalmente se ha usado al analista de negocio para cubrir ese hueco, pero en la práctica los problemas de comunicación entre el analista de negocio y el desarrollador no son despreciables. Si pudiéramos escribir los requisitos de negocio, en un lenguaje de programación, pero que a la vez fuera legible por un cliente o en su defecto, el analista de negocio, se ahorrarían muchos malentendidos. Un opción muy de moda es el modelado visual, pero claro, será visual, pero sigue haciendo falta la habilidad de modelar formalmente, habilidad que no tienen muchos clientes y expertos de negocio. Ellos saben de su negocio, pero no necesariamente saben plasmarlo en un modelo visual. Otro problema es que si bien algunos dominios de negocio se prestan muy bien al modelado visual, otros no. ¿Cómo modelamos visualmente un portfolio de acciones y derivados? Finalmente, para modelar visualmente, suele ser necesaria una herramienta, normalmente cara. En este sentido los DSL son superiores a las herramientas de modelado visual. Por un lado, el DSL está desarrollado específicamente para el dominio de negocio, con lo que son fáciles de usar para definir el negocio. Por otro lado, no se necesita una herramienta visual. Y finalmente, no se pretende que el experto de negocio escriba el DSL, sólo que sea capaz de leerlo, entenderlo y validarlo, que es lo realmente importante, escribir código ya lo hacemos nosotros.
Veamos algunos ejemplos de DSL de negocio (seguimos con Groovy, ¡cómo me gusta!):
El hecho de usar DSL para agilizar la comunicación con el cliente produce una sinergia con el uso de TDD, BDD y MDD (Model Driven Development). En TDD y BDD, podemos definir los tests de aceptación directamente en nuestro DSL de negocio, con lo que las pruebas serán más fáciles de escribir y validar. Desde el punto de vista de MDD, el DSL de negocio no es más que una API montada sobre el modelo OO de negocio, que nos permite construir modelos de negocio usando un lenguaje cercano al negocio. O sea, si usamos MDD, deberíamos aprovechar el modelo de negocio como base para nuestro DSL, de hecho podríamos considerar el DSL como un API builder para construir instancias de modelos de negocio y operar con ellos.
Un último detalle, algunos pensareis que pongo demasiado énfasis en la legibilidad del código, pues bien, el caso es que el código se lee mucho más frecuentemente que se escribe. La lectura y comprensión del código es una acción más frecuente que la escritura de este, y por lo tanto prefiero favorecer la legibilidad con respecto a la escritura. Si lo pensáis bien, este es la razón de que cosas como la generación de código y los wizards, al final no suelan ser muy útiles en lo que realidad importa, el mantenimiento correctivo y evolutivo de la aplicación. En esto los DSLs dan una ventaja grande, ya que proporcionan legibilidad y a la vez suelen simplificar la escritura.
Ingeniero en Informatica
Después del tocho sobre REST de la semana pasada, ahora toca cambiar de tercio. Seguramente algunos de vosotros habréis oído hablar de los DSL o Domain Specific Languages. En particular este es un tema en el que vengo trabajando desde hace años, y que me ha resultado bastante interesante y productivo.
¿Qué son los DSL? Simplemente podemos considerar como DSL cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Este conjunto específico de problemas es el llamado dominio de aplicación o de negocio. La mayor parte de los lenguajes de programación no se pueden considerar DSL ya que no están diseñados para resolver un conjunto específico de problemas, sino para resolver cualquier tipo de problema. Son pues, lenguajes generalistas (o turing completos).
El usar lenguajes generalistas ha tenido bastante aceptación y éxito hasta el día de hoy, de hecho poseen una ventaja indudable: con dichos lenguajes podemos resolver cualquier tipo de problema. Sin embargo esta ventaja no es gratis, al contrario, hay que pagar un precio, que es que no todos los problemas son igualmente sencillos de resolver. De hecho, dependiendo del lenguaje generalista que usemos, un mismo problema es más sencillo o más difícil de resolver. Es gracioso que se hayan producido muchas controversias por cual es el mejor lenguaje, cuando en realidad unos lenguajes son buenos para una cosa y malos para otra, y que los principales defensores de un lenguaje sólo tienen en cuenta las tareas en las que su lenguaje favorito es bueno. Normalmente suelen ser las mismas tareas que ellos se encuentran en su día a día laboral. Por ejemplo, trabajar con listas o hacer algoritmos recursivos es muy simple en LISP, sin embargo en BASIC o COBOL no es tan sencillo. Supongo que en cambio, con COBOL es sencillo definir algoritmos de negocio. Otro ejemplo, generar una página web dinámica es relativamente sencillo en PHP pero más complejo en JAVA. ¡ Eh ! Espera, en JAVA hacer una página web está tirado, pones una JSP y entonces… No hombre, el lenguaje JSP no es lenguaje JAVA, es un DSL…
Si cada lenguaje puede resolver cualquier problema, pero no todos con la misma sencillez, es lógico pensar que para cada problema que tengamos, podemos buscar el lenguaje que mejor se adapte a él. Al fin y al cabo, hay que usar la herramienta adecuada para cada caso. En su momento algunas mentes preeminentes se dieron cuenta de que el problema consistía precisamente en que los lenguajes generalistas eran demasiado ambiciosos al tratar de poder solventar cualquier problema. De hecho sería más adecuado poder contar con lenguajes especializados en solucionar los problemas que tuviéramos a mano. Es la misma diferencia entre tener un cuchillo multiuso para cualquier cosa, o un set de cuchillo de postre, de carne, de pescado y un bisturí y elegir los cuchillos que mejor nos vengan. Si sé que ese día voy a practicar una operación a corazón abierto, y después comeré pescado, mejor me llevo el bisturí y la paleta de pescado (para ser cirujano hay que tener el estomago muy fuerte).
De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (esperamos que el 20% o menos) solucionarlos con lenguajes generalistas. Algunos pensareis que esto de anticipar los problemas que voy a tener es un poco irreal, pues ni mucho menos. Desde el punto de vista puramente técnico, existen problemas que voy a tener que resolver casi siempre:
- Definición de interfaces de usuario.
- Seguridad. Aquí podemos distinguir dos subproblemas separados: autenticación y autorización.
- Gestión transaccional.
- Persistencia.
- Queries.
- Validación.
- Definición de tests automatizados (no me puedo resistir a meter TDD con calzador, je, je)
- Análisis léxico y sintáctico de lenguajes (parser) para construir compiladores
Aunque parezca mentira, ya existen algunos DSL que conviven con nosotros, pero tal vez no hemos pensado en ellos como tales. Algunos ejemplos:
- SQL para definir queries.
- XML para transportar datos, y a veces nos viene bien para persistir.
- HTML para definir interfaces de usuario. Curiosamente este DSL se ha ido “extendiendo” para ir convirtiéndolo cada vez más en un lenguaje generalista. No es de extrañar que sea difícil definir aplicaciones usando enteramente HTML.
- CSS para definir interfaces de usuario a nivel de presentación pura.
- JSP. Para definir (otra vez) interfaces de usuario web.
- WSDL, para especificar interfaces de datos de servicios web.
- XML de configuración de spring, para definir grafos de objetos.
- XML de hibernate para hacer mapeo entidad/relación.
- jMock para definir Mock Objects.
- ANTLR para definir gramáticas LL(*)
- Expresiones regulares (no se puede vivir sin ellas)
No quiero que os quedeis con la idea de que los DSLs son cosas que resuelven problemas “técnicos”. Hasta el momento he mostrado lo que son los DSLs “técnicos”, pero es que también existen DSLs de negocio. Existen muchos dominios de negocio, podemos tener aplicaciones de banca, de inversión en bolsa, tiendas electrónicas, seguros, etc. Por supuesto cada área se puede subdividir en dominios más pequeños. Por lo tanto parece una buena idea el poder definir DSLs de negocio, que nos permitan especificar, de forma sencilla y eficaz, los distintos conceptos, reglas y validaciones, de un dominio de negocio concreto.
Así pues, desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:
- DSLs externos. Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR. Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.
- DSLs internos. En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos. Un excelente ejemplo de DSL interno es el propio jMock. Los DSL internos también son llamados “fluent interface” o “fluent API”. Yo, pobre de mi, no sabía que existía esta denominación, por lo que se me ocurrió llamar “API Sexy” a un DSL que había construido, con el consiguiente cachondeo de mis compañeros.
Sin embargo el enfoque DSL ha tenido un resurgimiento al introducirse el concepto de DSL interno. Un DSL interno es mucho más sencillo de construir, no difiere mucho de construir un framework, tal vez se necesita una dosis extra de uso de reflexión y metaprogramación, pero al fin y al cabo no tenemos que andar con gramáticas y demás. Por otro lado, al no ser en realidad más que un API del lenguaje anfitrión, el IDE nos va a proporcionar ayuda. Ciertamente no todos los lenguajes son lo suficientemente flexibles como para permitir construir un DSL interno. Es casi imposible hacerlo en COBOL o en C (que yo sepa). En JAVA la dificultad es media. Pero en algunos lenguajes como Groovy, ¡resulta sencillo! En general cuanto más flexible sea el sistema de tipos del lenguaje y su sintaxis, y cuanta más capacidad de metaprogramación tenga, más sencillo construir un DSL interno. Lenguajes como Groovy o Ruby son ideales para esto, mientras que lenguajes con tipado fuerte suelen ser más problemáticos.
Sin entrar en como construir un DSL interno, veamos algunos ejemplos en Groovy:
No esta mal, ¿eh? ¿Quién quiere hacer lo mismo con JSP o JAXB?
Desde otro punto de vista, ya sea usando DSL externos o internos, una de las cosas más interesantes es hacer DSL orientados a negocio. Esto puede ser un paso adelante a la hora de solucionar un antiguo problema del software: la mala comunicación entre usuario y desarrollador. Tradicionalmente se ha usado al analista de negocio para cubrir ese hueco, pero en la práctica los problemas de comunicación entre el analista de negocio y el desarrollador no son despreciables. Si pudiéramos escribir los requisitos de negocio, en un lenguaje de programación, pero que a la vez fuera legible por un cliente o en su defecto, el analista de negocio, se ahorrarían muchos malentendidos. Un opción muy de moda es el modelado visual, pero claro, será visual, pero sigue haciendo falta la habilidad de modelar formalmente, habilidad que no tienen muchos clientes y expertos de negocio. Ellos saben de su negocio, pero no necesariamente saben plasmarlo en un modelo visual. Otro problema es que si bien algunos dominios de negocio se prestan muy bien al modelado visual, otros no. ¿Cómo modelamos visualmente un portfolio de acciones y derivados? Finalmente, para modelar visualmente, suele ser necesaria una herramienta, normalmente cara. En este sentido los DSL son superiores a las herramientas de modelado visual. Por un lado, el DSL está desarrollado específicamente para el dominio de negocio, con lo que son fáciles de usar para definir el negocio. Por otro lado, no se necesita una herramienta visual. Y finalmente, no se pretende que el experto de negocio escriba el DSL, sólo que sea capaz de leerlo, entenderlo y validarlo, que es lo realmente importante, escribir código ya lo hacemos nosotros.
Veamos algunos ejemplos de DSL de negocio (seguimos con Groovy, ¡cómo me gusta!):
- Manejemos algo de dinero:
defaccount=people.find(id:'22').defaultAccoutif(account.balance >4000.pound +30.dollar)account.transferTo(accountId:'24',amount:20.euro +30.dollar -4.pound) - Ya que tenemos dinero, podemos invertir en bolsa:
people.find(id:'0345').buyOffer{buyPosition(desired:35.ibm, maxPrice:34.euro)buyPosition(desired:2.google, maxPrice:43.euro)buyPosition(desired:10.microsoft, maxPrice:15.euro)}
El hecho de usar DSL para agilizar la comunicación con el cliente produce una sinergia con el uso de TDD, BDD y MDD (Model Driven Development). En TDD y BDD, podemos definir los tests de aceptación directamente en nuestro DSL de negocio, con lo que las pruebas serán más fáciles de escribir y validar. Desde el punto de vista de MDD, el DSL de negocio no es más que una API montada sobre el modelo OO de negocio, que nos permite construir modelos de negocio usando un lenguaje cercano al negocio. O sea, si usamos MDD, deberíamos aprovechar el modelo de negocio como base para nuestro DSL, de hecho podríamos considerar el DSL como un API builder para construir instancias de modelos de negocio y operar con ellos.
Un último detalle, algunos pensareis que pongo demasiado énfasis en la legibilidad del código, pues bien, el caso es que el código se lee mucho más frecuentemente que se escribe. La lectura y comprensión del código es una acción más frecuente que la escritura de este, y por lo tanto prefiero favorecer la legibilidad con respecto a la escritura. Si lo pensáis bien, este es la razón de que cosas como la generación de código y los wizards, al final no suelan ser muy útiles en lo que realidad importa, el mantenimiento correctivo y evolutivo de la aplicación. En esto los DSLs dan una ventaja grande, ya que proporcionan legibilidad y a la vez suelen simplificar la escritura.
No hay comentarios:
Publicar un comentario