Are you responsible for developing satellite on-board software? Are you the Dutch government and you have to efficiently implement the public benefits law? Are you a healthcare startup, developing companion apps that help patients through a treatment? Are you an insurance company struggling to create new, and evolve existing products quickly to keep up with the market? These are all examples of organisations who have built their own domain-specific programming language to streamline the development of applications that have a non-trivial algorithmic core. All have built their languages with Jetbrains MPS, an open source language development tool optimized for ecosystems of collaborating languages with mixed graphical, textual, tabular and mathematical notations. This talk has four parts. I start by motivating the need for DSLs based on real-world examples, including the ones above. I will then present a few high-level design practices that guide our language development work. Third, I will develop a simple language extension to give you a feel for how MPS works. And finally, I will point you to things you can read to get you started with your own language development practice.

1. Build your own
Markus Völter
voelter@acm.org
www.voelter.de
@markusvoelter
Why and How?

2. 1
Motivation

3. I just finished v3 of the requirements
document. But I am sure it will take
another two months of ping-pong
with IT to get the damn thing to run.
Aargh, another half-baked requirements
document. Those guys always rely on us
to “debug“ it and make it work.

4. The IT guys have decided to port the
system to mobile phones. We have to
do another re-write/-understand of all
the Fachlichkeit. Again!!
Well, yes, but we have to keep up with
the evolving technologies and new
platforms. No way around it!

5. Decouple Fachlichkeit and Technology!
so you can evolve both independently.
Represent Fachlickeit precisely/formally,
so you can analyze, test, simulate.
Use “friendly“ languages,
so domain experts can contribute directly.

6. Formal Language.
Checkable.
Understandable.
DSLDomain
Specific
Language

7. M1 M2 M3
L1 L2 L3
def := … def := ∃ ⊢ #$α def := … ....
LM ∃, ⊢, #, $, α
<meta> <meta> <meta>
<meta> <meta> <meta>
LANGUAGEDEFINITION

8. 2
Examples

9. Insurance Contracts
Insurance
Programs
Write formal code in a DSL
mixed with tables and text
Now with IDE support and executable tests
The same notation!
Specify/Program/Test/Debug

10. Public Benefits

11. Data Flow Programming

12. Tachograph Rules

13. Math
Insurance Math

14. Satellite Software

15. Healthcare

16. Healthcare

17. http://voelter.de/data/pub/MPS-in-Safety-1.0.pdf

19. 3
MPS Demo

20. (Meta-) Tooling
Language Workbench
Open Source, by Jetbrains
Very Powerful
Used for years by itemis and others
Vast Experience

21. (Meta-) Tooling
Language Workbench
Open Source, by Jetbrains
Very Powerful
Used for years by itemis and others
Vast Experience

22. MPS: Language Toolkit

23. MPS: Notational Freedom

24. MPS: Language Composition

25. MPS: Language Composition
Embedding/Extending the KernelF
functional language is key to DSL
development productivity.

27. TU Delft
itemis/Typefox
CWI Amsterdam
Solmi/Persiani
Rascal
The Whole
Platform
Other Language Workbenches

28. http://voelter.de/data/pub/LWB-ResultsAndBenchmarks.pdf

30. 4
Lessons Learned

31. A Language
is not Enough

32. Language
Great IDE
Analyses
Refactorings
Testing
Debuggers
Abstractions
Notations
Syntax Coloring
Code Completion
Goto Definition
Relevant
Good Errors
Aligned with Processes
Write Tests
Run them
Report Back
Animate Execution
Simulators
GOOD
GREAT

33. Influences on
the Language

34. Domain
Structure
Model
Purpose
Analyze, Generate
User
Skills
Software
Engineering
Practices
Non
Functionals
Permissions,
IP, Sharing
Tool
Capabilities
Notations,
Editing, Scale
Sep. of Concerns
Different Views
Get a better tool :-)
Refactor towards
Structure
Educate,
Put results in context

35. Domain
Structure
Model
Purpose
Analyze, Generate
User
Skills
Software
Engineering
Practices
Non
Functionals
Permissions,
IP, Sharing
Tool
Capabilities
Notations,
Editing, Scale
Sep. of Concerns
Different Views
Get a better tool :-)
Refactor towards
Structure
Educate,
Put results in context
Style!

36. How to make
People precise?

37. Precision
Programming
!=
{
Formulas, Rules
Data Structures
Tables
Values
}
Performance
Scalability
Robustness
Deployment

38. Training
is required.

39. Skills?

40. Organizations do not have
the necessary skills. True.
But...„
“
AI
Big
Data Agile R E
S T
So build it. Evolve. Hire. Buy.

41. Is this the next
legacy system?

42. „ “Today‘s software is
tomorrow‘s legacy system.
Or is it?

43. Language Tech 1
V1 V2 V3 ....
Evolution
Existing models become incompatble
with new language
ÞLanguage Versions
Migration Scripts
Runtime T 1
Generator 1

44. Language Tech 1
V1 V2 V3 ....
Evolution
Runtime T 1
Generator 1
Runtime T 2
Generator 2
Retargetting
Runtime Tech outdated, uncool or slow
ÞKeep Lang Technology
Keep Models
Build new Generator

45. Language Tech 1 Language Tech 2
....
Migration
V1 V2 V3 .... V4 V5 V6 ....
Evolution Evolution
Runtime T 1
Generator 1
Runtime T 2
Generator 2 Generator 3
Language Tech outdated, uncool
ÞBuild new Tool
Migrate Data Feasible, because it well-defined domain
semantics and free from „technology stuff“
Retargetting

46. „ “Today‘s software is
tomorrow‘s legacy system.
No, it is not.

47. In conflict
with Agile?

48. MD* and Agile is in Conflict.„ “
Project
Language
Development
System
DevelopmentDepend on, use
Project 1
Language
Development
Project 2
System
Development
Project N
…
Dep’d on, use
Later:
1
2

49. Project
Language
Development
System
DevelopmentDepend on, use
1
Framework
Library
Platform
Manage like any other
intra-project dependency.
Evolution of client code is
easier than for F/L/P because of
migration support!
MD* and Agile is in Conflict.„ “

50. Project 1
Language
Development
Project 2
System
Development
…
Dep’d on, use
Later:
2
Framework Library Platform
Manage like any other
3rd party depencency: Development Roadmap
Issue Tracker
Release Notes
...
MD* and Agile is in Conflict.„ “

51. Project 2
System
Development
3
Models and DSLs are
an Enabler for Agility: Integration of Domain Experts
„Living“ Requirements
Decoupled Fachlichkeit & Technik
MD* and Agile is in Conflict.„ “WTF?

52. Project 1
Language
Development
4
Leading LWBs are so productive,
you can literally sit with the domain
experts and interactively prototype
languages (and then clean up later)
I’ve looked at the
implementation of the
language in MPS, but I didn’t
find much. Is this all there is?
Where’s the magic?
[Customer]
MD* and Agile is in Conflict.„ “

53. Project 1
Language
Development
4
Leading LWBs are so productive,
you can literally sit with the domain
experts and interactively prototype
languages (and then clean up later)
I’ve looked at the
implementation of the
language in MPS, but I didn’t
find much. Is this all there is?
Where’s the magic?
[Customer]
MD* and Agile is in Conflict.„ “
Analyze Build Try out Cleanup
Stabilize Validate
1 to 3 days
1 hour

54. What about CI?

55. You integrate like any other
automatable CI step.

57. 5
Wrap Up

59. http://voelter.de/data/pub/voelterEtAl2017-buildingMbeddr.pdf

60. Separation of concerns is key
to avoid the legacy trap
DSLs can isolate business logic
completely from technical concerns
DSLs can help integrate domain experts
with communication/review or even coding
Language Workbenches enable DSLs
by reducing effort to build, compose and maintain them
DSLs are not in conflict with Agile
... to the contrary, DSLs are a powerful enabler!