Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DSL Design - Best Practices (XtextCON 2015)
Search
Sven Efftinge
May 20, 2015
Technology
0
1k
DSL Design - Best Practices (XtextCON 2015)
Sven Efftinge
May 20, 2015
Tweet
Share
More Decks by Sven Efftinge
See All by Sven Efftinge
Life of a Resource (XtextCON 2015)
svenefftinge
0
320
Future of Xtext (with Sebastian Zarnekow)
svenefftinge
0
18k
Other Decks in Technology
See All in Technology
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
100
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
0
130
本が全く読めなかった過去の自分へ
genshun9
0
710
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
5
590
OPENLOGI Company Profile
hr01
0
67k
KubeCon + CloudNativeCon Japan 2025 に行ってきた! & containerd の新機能紹介
honahuku
0
120
怖くない!はじめてのClaude Code
shinya337
0
300
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
2
680
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
230
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
180
解析の定理証明実践@Lean 4
dec9ue
1
200
論文紹介:LLMDet (CVPR2025 Highlight)
tattaka
0
240
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
We Have a Design System, Now What?
morganepeng
53
7.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Designing for humans not robots
tammielis
253
25k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
YesSQL, Process and Tooling at Scale
rocio
173
14k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Transcript
DSL DESIGN Sven Efftinge
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
DSL Design != GPL Design
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
DSL A Powerful Programming Interface User Interface
Who does What Requirements Engineering
Use Existing Domain Terminology
Use Familiar SYNTAX
When To Sugar Be explicit and regular unless the concept
is used often and well known
Never Change
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
Business Readable DSLs
Use Structure, use Whitespace
Be Regular
Keywords First reduces look ahead for the parser &
the reader visual anchor
Good Defaults
Multiple Files FTW a package or namespace is a logical
container but not necessarily a physical! improves collaboration
Names! Simple name clashes are rare We think in names
No more UUIDs!
Loose Grammar
Strict Validation
you ain’t gonna need it
Don’t Reinvent Expressions
Invasiveness • The outside view must only change when
the file changes physically • Bad Example: Xtend return types
Dynamic Scoping Never!
Preprocessors Nooo!
N-to-1 Code Generation source source generated No more incremental builds!
OutOfMemoryException!
Questions