¿Qué es mejor que un DSL interno?

Un DSL interno basado en Scala 

A pesar de ser static typing su sintaxis le permite crear DSL internos tan legibles que los posibles con Ruby.  Scala la lleva.

Reflexiones sobre internal vs external DSL

Me toco durante Diciembre evaluar 3 formas de implementar ruteo y transformación de mensajes usando Sun OpenESB .  Sun provee 3 formas distintas de hacerlo:

• con la versión de producción actual:
• usando BPEL y llamadas a servicios vía WSDL para operaciones más complejas.
• usando Apache Camel dentro de OpenESB
• con la versión en desarrollo, llamada fuji, usando el Integration Flow Language (IFL).

IFL es un DSL externo y Camel usa DSL internos basados en Java , Spring-XML o Scala .  Comparando las soluciones pude hacerme una opinión sobre el DSL interno vs externo.

Primero algunos comentarios

• XML es un pésimo lenguaje para definir un DSL.  Una de las gracias de un DSL es que debe ser fácilmente legible y XML no permite eso porque agrega mucha sintaxis que no aportan nada para un ojo humano.

• IFL como DSL externo esta bien construido: 
• la sintaxis es super simple porque no tiene todos los adornos del lenguaje subyacente que hacen ilegibles un DSL sobre XML y que molestan en caso de Java..  
• Sun no incluyo en IFL sintaxis para programación más compleja, como por ejemplo para enriquecer un mensaje. En su lugar permite encapsular código jRuby que puede llamar a servicio Java vía Web Service.  El defecto de esta solución es que requiere usar muchos lenguajes distintos (IFL, Ruby, WSDL, Java).

• Camel usa 3 tipos de DSL internos:
• sobre Spring-XML: es ilegible.
• sobre Java: Java tiene una sintaxis inflexible para ser usado como base de un DSL interno:  principalmente el uso del punto y de los paréntesis para llamar a métodos   
• sobre Scala: creo que es un buen ejemplo de lo potente de la sintaxis Scala

• Los DSL internos de Camel basados sobre Java o Scala, permiten llamar todas las bibliotecas del lenguaje sin pasar por una interfaz WSDL o un lenguaje de scripting.  Es una ventaja considerable para anticiparse a la necesidad de crear extensiones.

Mi posición sobre interno vs externo

Los ESB son un ejemplo donde hay que pensar de antemano en como crear extensiones.  Es entonces, un buen caso de uso para probar lo potente del concepto DSL.

Por su simplicidad, me parece correcta la solución de DSL interno de Apache Camel.  Como el ESB va a ser configurado por un programador, la poca sintaxis Scala necesaria (como la definición de paquete y los import) no molesta mucho.

Si tuviera que implementar un DSL, mi primera opción sería entonces un DSL interno.

Riesgos de los DSL

El año pasado leí este articulo sobre los riesgos de crear un "external DSL" propio.  El articulo menciona el costo de mantener código no trivial como un riesgo importante y eso me hace sentido porque ya ocurrió antes, con los frameworks Java.  

Conozco algunas empresas que crearon en casa sus framework web, de persistencia o de DI en lugar de usar alternativas open source conocidas.  Ahora, estas empresas tienen que

• capacitar sus empleados en el uso de estos framework y me imagino que para estos empleados no le agrega valor mencionar este conocimiento en su curriculum.
  
• hacer evolucionar el framework con las tendencias nuevas como por ejemplo el uso de anotación y programación genérica,
• al revés, dejar de mantener el framework y no aprovechar las ventajas de las tendencias nuevas ante-mencionadas.
• migrar el código para usar framework más conocidos.

Estos mismos problemas existen también en el mundo de los DSL.  Para mitigarlos, el autor del articulo propone desarrollarlos en modalidad Open Source o desarrollarlos con una comunidad de empresa que comparten el mismo dominio de negocio.  En los comentarios del articulo y en este otro más antiguo se recomienda que el DSL sea bien acotado (no más de 1 día de aprendizaje) y estático (sin cambios futuros).

Me parece super razonable.

Otro excelente ejemplo de uso de Scala

Esta vez viene de Camel un software de EAI Open Source del grupo Apache. Este software implementa varios patrones de integración comunes.

¡Es casi el paraíso! Reemplazaron un horrible archivo de configuración Spring-XML con un DSL implementado en Scala.

Ya me convencí a 200%:

• Necesito conocer todos los detalles de Scala, es un lenguaje demasiado potente.
• Ya se para que usar los DSL: reemplazar los archivos de configuración XML o properties que tanto amo.
  

Buenos ejemplos en Scala

Cada vez me gusta más el lenguaje de programación Scala, pero es difícil encontrar buenos ejemplos. Los tutoriales en el sitio web son muy académicos y se pierde mucho tiempo a recordar o entender los algoritmos (a pesar que no es malo refrescarse la memoria de vez en cuando).

De todos los ejemplos más "de negocio" que encontré, este se destaca:

• El blogger inventa un DSL para compra/venta de acciones.
  
• En el primer blog, usa Scala para parsear mensajes o cualquier string externo a su programa.
  
• Luego, en un segundo blog, incluye el código DSL dentro del código Scala.

Encuentro estos ejemplos muy buenos por varias razones:

• Hasta ahora, había visto ejemplos de DSL en Ruby. No me puedo acostumbrar a los lenguajes dinámicos, así que me da mucho gusto poder usar para estos fines un lenguaje con "static typing" como Scala,
  
• Es increíble lo fácil crear parseadores,
• El blogger usa su DSL en reemplazo a mensajes en formato XML (otra razón para estar muy contento).
• Obligan a entender varias facetas del lenguaje.