jueves, 30 de junio de 2005
Domain-Specific Languages: An Annotated Bibliography1
Domain-Specific Languages: An Annotated Bibliography1 y Domain-Specific Languages son dos páginas sobre DSLs a tener en cuenta. La primera contiene una bibliografía extensísima.
Language Workbenches: The Killer-App for Domain Specific Languages?
Language Workbenches: The Killer-App for Domain Specific Languages?. Se trata de un artículo de Martin Fowler sobre lenguajes específicos del dominio y lo que él denomina "Language Oriented Programming", comentando diferentes aproximaciones a este tipo de desarrollo: Intentional Software, Meta-Programming System, Software Factories y Model Driven Architectures.
Algunos comentarios sobre el artículo de Martin Fowler se recogen en este artículo de Ehud Lamm. Entre los comentarios que se hacen sobre el tema en este último artículo hay una referencia a la siguiente entrada de The Pragmatic Programmers, titulada Never Build an Application. Se pone en duda mucho la mantenibilidad de las aplicaciones creadas en base a DSLs construidos con estos Language Workbenches (LW). De hecho Fowler comenta en su artículo que sería deseable que estos entornos no utilizaran un método propio de especificación de lenguajes, sino que compartieran uno propio, de forma que lo desarrollado en un LW se pueda utilizar en otro. En este sentido, MetaCET, al tratar el modelo del lenguaje como un modelo OO más, permite compartir este modelo entre diferentes aplicaciones.
Thomas Mäder, en su comentario al artículo de Ehud indica que lo que los LW pretenden no es sólo un editor con resaltado de sintaxis, sino algo más allá: depuración a nivel del DSL, etc.
Serge Bureau menciona el problema de crear múltiples DSLs: nadie será capaz de entender los programas escritos por otros, porque estarán llenos de dialectos. Más aún, las empresas tendrán que enseñar a los programadores que se incorporen una multitud de pequeños lenguajes. Por otro lado: ¿no deben estos lenguajes estar más cercanos al dominio del problema? Siendo así, ¿por qué habrían de ser más complicados? Deberían incluso ser autoexplicativos. Esto mismo lo dice Juha-Pekka aquí.
Patrick Gotthardt menciona el problema de tener muchas sintaxis diferentes para lo mismo (y pone el ejemplo de los miles de ficheros de configuración que hay en linux, cada uno con su sintaxis particular). Dos cosas: a) modela el lenguaje sin preocuparte de la sintaxis, b) pon una sintaxis que sea lo más conocida posible por los que van a usar el lenguaje (y como ejemplo lo de los patrones: !! o <%).
Algunos comentarios sobre el artículo de Martin Fowler se recogen en este artículo de Ehud Lamm. Entre los comentarios que se hacen sobre el tema en este último artículo hay una referencia a la siguiente entrada de The Pragmatic Programmers, titulada Never Build an Application. Se pone en duda mucho la mantenibilidad de las aplicaciones creadas en base a DSLs construidos con estos Language Workbenches (LW). De hecho Fowler comenta en su artículo que sería deseable que estos entornos no utilizaran un método propio de especificación de lenguajes, sino que compartieran uno propio, de forma que lo desarrollado en un LW se pueda utilizar en otro. En este sentido, MetaCET, al tratar el modelo del lenguaje como un modelo OO más, permite compartir este modelo entre diferentes aplicaciones.
Thomas Mäder, en su comentario al artículo de Ehud indica que lo que los LW pretenden no es sólo un editor con resaltado de sintaxis, sino algo más allá: depuración a nivel del DSL, etc.
Serge Bureau menciona el problema de crear múltiples DSLs: nadie será capaz de entender los programas escritos por otros, porque estarán llenos de dialectos. Más aún, las empresas tendrán que enseñar a los programadores que se incorporen una multitud de pequeños lenguajes. Por otro lado: ¿no deben estos lenguajes estar más cercanos al dominio del problema? Siendo así, ¿por qué habrían de ser más complicados? Deberían incluso ser autoexplicativos. Esto mismo lo dice Juha-Pekka aquí.
Patrick Gotthardt menciona el problema de tener muchas sintaxis diferentes para lo mismo (y pone el ejemplo de los miles de ficheros de configuración que hay en linux, cada uno con su sintaxis particular). Dos cosas: a) modela el lenguaje sin preocuparte de la sintaxis, b) pon una sintaxis que sea lo más conocida posible por los que van a usar el lenguaje (y como ejemplo lo de los patrones: !! o <%).
viernes, 3 de junio de 2005
args4j: Home
args4j: Home
Parsea la línea de comandos y además permite asociar argumentos de la entrada a atributos mediante anotaciones.
Parsea la línea de comandos y además permite asociar argumentos de la entrada a atributos mediante anotaciones.
Suscribirse a:
Comentarios (Atom)