40 likes | 184 Views
DSLs: The Good, the Bad, and the Ugly . Kathleen Fisher AT&T L a bs Research. Background. Data Warehouse. Hancock DSL for constructing customer „signatures” from transaction streams. Facilitated efficient, high-level programs. Used in production for > 8 years
E N D
DSLs: The Good, the Bad, and the Ugly Kathleen Fisher AT&T Labs Research
Background Data Warehouse • 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 207.136.97.49 - - [15/Oct/2006:18:46:51 -0700] "GET /turkey/amnty1.gif HTTP/1.0" 200 3013
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!