DSL Design - Best Practices (XtextCON 2015)

Transcript

1. DSL DESIGN Sven Efftinge
2. Why an External DSL • Write the thing you care in the way you want • Have compile time feedback, that understand your domain • Be cross platform / platform independent
3. DSL Design != GPL Design
4. A Good DSL makes editing simpler makes reading simpler improves stakeholder communication uses a familiar syntax nicely integrates into workflow tools and execution are fast is highly maintainable
5. DSL 
 A Powerful Programming Interface User Interface
6. Who does What Requirements Engineering
7. Use Existing 
 Domain Terminology
8. Use Familiar 
 SYNTAX
9. When To Sugar Be explicit and regular unless the concept is used often and well known
10. Never Change
11. class { visibility=public name="HelloWorld" members = [ method { visibility=public static=true returnType=void name="main" parameters = [ parameter { type = String varArgs = true name = args } ] ... } ] } public class HelloWorld { public static void main(String... args) { System.out.println("Hello World"); } } Generic vs. 
 Specific
12. Business Readable DSLs
13. Use Structure, use Whitespace
14. Be Regular
15. Keywords First reduces look ahead for 
 the parser & the reader visual anchor
16. Good Defaults
17. Multiple Files FTW a package or namespace is a logical container but
 not necessarily a physical! improves collaboration
18. Names! Simple name clashes are rare We think in names No more UUIDs!
19. Loose Grammar
20. Strict Validation
21. you ain’t gonna need it
22. Don’t Reinvent Expressions
23. Invasiveness • The outside view must only change 
 when the file changes physically • Bad Example: Xtend return types
24. Dynamic Scoping
 Never!
25. Preprocessors Nooo!
26. N-to-1 Code Generation source source generated No more incremental builds! OutOfMemoryException!
27. Questions