DSLs: The Good, the Bad, and the Ugly Kathleen Fisher AT&T Labs Research

Background Hancock – DSL for constructing customer „signatures” from transaction streams. – Facilitated efficient, high-level programs. – Used in production for > 8 years PADS – Declarative DSL for describing ad hoc data. – Generate in-memory representation, parser, printer, XML conversion tools, statistical analyses... – Used at AT&T to vet and load data into databases. Transaction Data Hancock Signature Database Data Warehouse [15/Oct/2006:18:46: ] "GET /turkey/amnty1.gif HTTP/1.0"

The Good Targeted abstractions mean DSL programs express important information & hide details. – “You can really see what we’re talking about” – Programs are shorter: easier to audit, maintain. – PADS descriptions serve as living documentation. From declarative specifications, we can generate multiple artifacts: – parser, printer, XML translation, statistical analyses,... Compiler can ensure properties of programs: – Parser will return meta-data that describes errors.

The Bad and The Ugly Challenge of routine features – Include in DSL: replicate a lot of effort! – Borrow from ‘host’ language: have to process host language code. Lack of tools – DSLs often lack debuggers, profilers, IDE support, etc., because building them is labor intensive. Reluctant customers – Learning new languages is hard!