martes
sep262006
Domain Specific Languages ¿buena o mala idea?
martes, septiembre 26, 2006 at 10:19AM
Los Domain Specific Languages (DSL) son lenguaje de programación construidos por los propios programadores "a medida" para resolver un determinado problema, de ahí su nombre: son un lenguaje específico para un determinado dominio. Dentro de la plataforma Java, por lo de ahora, no son demasiado populares ya que no sería fácil construir uno. Pero en los lenguajes de programación dinámicos, como Ruby, que dan soporte a la construcción de extensiones de lenguaje y, por tanto, a DSLs sí lo son.
En la actualidad existe bastante controversia sobre si "son buenos o son malos los DSLs". En InfoQ ( un portal casi recién creado de prensa tecnológica que está llamado a convertirse en uno de los grandes por la gran cantidad de colaboraciones y apoyos que tiene, entre ellos el de Floyd Marinescu, antiguo editor de TSS) han publicado un artículo recopilación donde se exponen varios puntos de vista sobre este tema (artículo creado por Marinescu, por cierto).
Joel Spolsky ha empleado un DSL para solucionar problemas de despliegue y mantenimiento de aplicaciones. Su proyecto fue un éxito y, por tanto, está a favor de ellos. Mark Dominus afirma que los patrones de diseño son una muestra de deficiencias en un lenguaje . Por tanto, debemos buscar formas de mejorar los lenguajes y los DSLs son el camino adecuado. Ralph Johnson, uno de los autores del libro de patrones GoF, no está de acuerdo con este punto de vista.
Buko Obele está en contra de los DSLs porque no permiten controlar adecuadamente el cambio a lo largo del tiempo. El ha desarrollado varios de estos lenguajes y, cuando los requerimientos del sistema cambian, se ha visto obligado a cambiar el lenguaje (cosa que tiene bastante sentido: si has diseñado un lenguaje muy adaptado a un problema y el problema cambia el lenguaje deja de ser adecuado). Obele se encontró con que cada vez perdía más tiempo reescribiendo estos lenguajes.
Otro problema que yo les veo es el mantenimiento al largo tiempo: si has creado tu propio lenguaje nadie lo conoce y cualquier persona que entre en el proyecto tendrá que aprenderlo. Por otro lado, el lenguaje debe documentarse exhaustivamente o se corre el riesgo de que si todos los que lo conocen abandonan la empresa nadie sabe cómo trabajar con él. Generar documentación también consume tiempo.
También pueden tener un efecto pedagógico negativo: alguien que empieza a programar por primera vez en Ruby en un proyecto en el que se emplea un DSL al final del proyecto no sabrá Ruby ya que no será capaz de distinguir qué es parte de Ruby y qué era parte de lenguaje de la compañía.
Aunque ahora a lo mejor nos parece que en la plataforma Java esto ni nos viene y nos va, con la gran cantidad de lenguajes dinámicos que están surgiendo dentro de la propia plataforma esto pronto será un tema de discusión. ¿Alguien ha construido/empleado alguna vez un DSL? ¿cuál es tu opinión sobre ellos?
En la actualidad existe bastante controversia sobre si "son buenos o son malos los DSLs". En InfoQ ( un portal casi recién creado de prensa tecnológica que está llamado a convertirse en uno de los grandes por la gran cantidad de colaboraciones y apoyos que tiene, entre ellos el de Floyd Marinescu, antiguo editor de TSS) han publicado un artículo recopilación donde se exponen varios puntos de vista sobre este tema (artículo creado por Marinescu, por cierto).
Joel Spolsky ha empleado un DSL para solucionar problemas de despliegue y mantenimiento de aplicaciones. Su proyecto fue un éxito y, por tanto, está a favor de ellos. Mark Dominus afirma que los patrones de diseño son una muestra de deficiencias en un lenguaje . Por tanto, debemos buscar formas de mejorar los lenguajes y los DSLs son el camino adecuado. Ralph Johnson, uno de los autores del libro de patrones GoF, no está de acuerdo con este punto de vista.
Buko Obele está en contra de los DSLs porque no permiten controlar adecuadamente el cambio a lo largo del tiempo. El ha desarrollado varios de estos lenguajes y, cuando los requerimientos del sistema cambian, se ha visto obligado a cambiar el lenguaje (cosa que tiene bastante sentido: si has diseñado un lenguaje muy adaptado a un problema y el problema cambia el lenguaje deja de ser adecuado). Obele se encontró con que cada vez perdía más tiempo reescribiendo estos lenguajes.
Otro problema que yo les veo es el mantenimiento al largo tiempo: si has creado tu propio lenguaje nadie lo conoce y cualquier persona que entre en el proyecto tendrá que aprenderlo. Por otro lado, el lenguaje debe documentarse exhaustivamente o se corre el riesgo de que si todos los que lo conocen abandonan la empresa nadie sabe cómo trabajar con él. Generar documentación también consume tiempo.
También pueden tener un efecto pedagógico negativo: alguien que empieza a programar por primera vez en Ruby en un proyecto en el que se emplea un DSL al final del proyecto no sabrá Ruby ya que no será capaz de distinguir qué es parte de Ruby y qué era parte de lenguaje de la compañía.
Aunque ahora a lo mejor nos parece que en la plataforma Java esto ni nos viene y nos va, con la gran cantidad de lenguajes dinámicos que están surgiendo dentro de la propia plataforma esto pronto será un tema de discusión. ¿Alguien ha construido/empleado alguna vez un DSL? ¿cuál es tu opinión sobre ellos?
Reader Comments