Domain Specifc Languages
summary
Claims that internal DSL fluent APIs cut developer effort versus writing a full lexer/parser, and that external DSLs require ugly, massive parsing code. Shows concrete tools and outcomes: using Gherkin with Behat for business-readable tests, building an Interface Distiller plus an Expression Builder (code on GitHub) to generate interfaces, using Symfony YAML parsing to drive an HTML code-presentation generator, demonstrating Zend DB style SQL abstraction and mockery examples, and concluding the parser route is powerful but often external parser mess and costly.
AI-written summary · about
chapters (25)
- 0:00Microphone
- 0:55PHP
- 1:35About Tobias
- 2:20About Gordon
- 2:49DSL
- 4:50DSL Sequel
- 5:37DSL for the Web
- 8:07Java
- 8:40Why create a DSL
- 10:28Noiseless
- 11:13Regular Expressions
- 13:40gherkin
- 15:57behead
- 20:06Interface Distiller
- 22:13Semantic Model
- 24:38Fluent Interface
- 27:09CLE Interface
- 34:38Summary
- 40:01Why
- 40:35API vs DSL
- 43:38Internal DSL
- 44:34Quiz
- 45:25Simple DSL
- 47:38Effort
- 48:39Problems
related talks
01h 10mDomain Specific Languages: Molding Ruby
29mIntegrating Language Engineering into the Software Development Process
53mDeveloping DSLs in a pragmatic way
38mDSLs, Code Generation, and New Domains for Ruby
59mWriting Domain Specific Languages with Python
25mMore DSL, Less Pain
18mTowards a Language-parametric DSL for Refactoring (Short Paper)
07mNew Ideas: Automated Engineering of Metamorphic Testing Environments for Domain-Specific Languages