Over the last five years we have built mbeddr, a collection of integrated languages and language extensions built with the Jetbrains MPS language workbench. mbeddr consists of 81 languages, incl. IDE support, 34 of them C extensions. The mbeddr languages use a wide variety of notations – textual, tabular, symbolic and graphical – and the C extensions are modular; new extensions can be added without changing the existing implementation of C. mbeddr’s development has spanned roughly 15 person years so far, and the tool is used in practice and continues to be developed. This makes mbeddr a case study in language engineering of non-trivial size and complexity. In this keynote, I look back at mbeddr’s development to identify what worked well and what are still challenges in language engineering with a modern language workbench. I will address five areas: language modularity, notational freedom and projectional editing, mechanisms for managing complexity, performance and scalability issues and the consequences for the development process. I will close by highlighting a set of issues which need further research and engineering.

1. Markus Völter
voelter@acm.org
www.voelter.de
@markusvoelter
Language Engineering
Lessons Learned about
from the
Development
mbeddr of

2. First:
It‘s not just me!

4. Health & Medical
AutomoEve
Aerospace
RoboEcs
Finance
Embedded
Government
DOMAINS SoKware Engineering
Requirements Engineering
SpecificaEon and VerificaEon
ImplementaEon and Test
Mixed NotaEons and End User Programming
Informal -> Semiformal -> Formal
Languages + VerificaEon
OptmizaEons, Performance and Concurrency
Fundamentals: Editors, Type Systems, Trafos
User-Friendly IDEs, Tools
Safety and Security
Architecture
Science
Methodology
Language Engineering

5. Background:
MPS
1
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

6. Freely
define
integrate
them
languages and
Language
Workbench (MarEn Fowler, 2004)

7. powerful
ediEng
tesEng
refactoring
debugging
language definiEon
IDE definiEon
implies
+
groupware
Language
Workbench (MarEn Fowler, 2004)

8. support for
„classical“
programming
„classical“
modeling
and
+
Language
Workbench (MarEn Fowler, 2004)
There‘s no difference!

9. A Language Workbench –
a tool for defining, composing
and using ecosystems of languages.

10. [Language Workbench]
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...
Comprehensive Support for
many aspects of Language DefiniEon.

12. Parsing ProjecEonal EdiEng
[ProjecEonal EdiEng]

13. Regular Code/Text MathemaEcal
Tables Graphical
SyntacEc Flexibility
[ProjecEonal EdiEng]

14. Regular Code/Text MathemaEcal
Tables Graphical
SyntacEc Flexibility
[ProjecEonal EdiEng]

15. L2 L1
Separate Files In One File
Type System
TransformaEon
Constraints
Type System
TransformaEon
Constraints
Syntax
IDE
Language ComposiEon
[ProjecEonal EdiEng]

16. Language ComposiEon
[ProjecEonal EdiEng]

17. Background:
mbeddr
2
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

18. An extensible set of integrated languages
for embedded soKware engineering.

19. Composable extensions, Diverse notaEons

20. Smart Meter
Measures Voltage and Current
Computes Derived Values
Shows Data on LCD Display
Communicates through Networks
Precision is criEcal for CerEficaEon.
Evolvability is criEcal for it to be a viable business.
An Industrial Case Study
Developed with , a set of domain-
Specific extensions to C, plus an IDE.

21. Hardware Architecture
MSP430 F67791
25 MHz
256K Flash ROM
32K RAM
MSP430 F6736
25 MHz
128K Flash ROM
8K RAM
MQTT
UART
RS485
IrDA
DLMS/COSEM
Metrology ApplicaOon Logic

22. SoKware Architecture
Energy
data
Non-
Volatile
data
Mains frequency
measurement
Instantaneous voltage &
current sampling
RMS voltage & current
calculation
Power & power factor
calculation
Energy and consumption
calculation
Energy data
display
Multi-tariff &
billing periods
support
Magnetic
interference
protection
DLT645
calibraEon
commands
Load profile
support
Reset function,
historical data
recording
COSEM
objects/OBIS
codes
Anti-tampering/
anti-fraud
Last/average/
maximum
demand
Output relay
control
Watch-
dog
Clock
System
USCI
LCD
Line
Temperature
Provider
RTC
Flash
Memory
Timer ADC10SD24EEPROM
HAL
Calibration
Protocol
Rem. Device
Access Prot’l
...
Bin/Bcd
Converter
LCD format
Low-Pass
Filter
TickerModem Protocol
UTIL COMM
METROLOGY APPLICATION
No RTOS
Interrupt-Driven
One-Threaded Programming
Required Precision leads to
4096 Hz Sampling Rate
Interrupt-Triggered:
Measurement
Foreground Tasks:
App Logic, RTC

23. Size of the System
Common code runs on both processors, Metro runs on the
metrology processor and App runs on the applicaOon /
communicaOon processor.
+ roughly the same amount again for tests.
ca. 30,000 SLOC

24. Use of Extensions
All mbeddr C extensions used a lot.
Some extensions built specifically for SM.

25. A 5-minute
MPS tutorial
3
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

26. C Extension to dequeue a value
generated to

27. Structure

28. Editor + AcEons
Editor acEons to implement editor
behavior. Previously manually wrioen,
now generated from Grammar Cells.
See SLE Paper :-)

29. Constraints
Tree Constraints:
Scopes:

30. Type System
Checking Rules:
Typing Rules:

31. Behavior

32. Generators/TransformaEons

33. And many more...
IntenEons/Quick Fixes
Refactoring
Text Generators
Language Test Cases
Data Flow Graphs/Analyses
Debuggers
...

34. Modularity Fundamentally OO

35. Project
Stats
4
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

36. Total Effort
10
person years

37. Size of the Impl.
ca. 90,000 SLOC

38. Tests vs. ImplementaEon

39. Timeline of the Project

40. Kinds of Languages

41. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

42. 1 Language Modualarity
2 ProjecEonal EdiEng
3 Managing Complexity
4 Tool Scalability
5 Development Process
RQ
RQ
RQ
RQ
RQ

43. For a scienEfic treat-
ment with all caveats
and data and details,
check out the paper:
hop://bit.ly/2dvXnBF

44. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr
RQ
1 Language
Modualarity

45. Booom-Up Development

46. Some Hooks are known a priori

47. Some had to be added a posteriori
IAssignmentLike: =, +=, *=, etc.
IFuncEonLike: funcEon, method
IBinaryLike: +-*/ but also . ?: !
IVoidTypeContainer: funcEon, Kype
Conceptually this breaks modularity.
But it‘s like OO programming/frameworks.
So we deem it acceptable.

48. OvermodularizaEon!
Too much modularizaEon is also not helpful.
We had a lot of circular dep‘s,
solved via interfaces.
Not helpful.
Refactoring tough because of MPS bugs in Refactorings.

49. We used mostly Extension (+EC)
Fundamentally it works and scales.

50. Is Extension
ComposiEon
modular?
MulEple Extensions in C
No syntacEc or IDE issues.
Type systems compose well.
BUT: SemanEc InteracEons cannot be
staEcally guaranteed to be correct.

51. Is Extension
ComposiEon
modular?
NesEng in C/in each other
No syntacEc or IDE issues.
Type systems compose well.
BUT: SemanEc InteracEons cannot be
staEcally guaranteed to be correct.

52. Is Extension
ComposiEon
modular?
NesEng in each other
Adapter language Needed
Type system adapters needed
Adapter Language also deals
with semanEc interacEons.
Specifically design integraEons!
No modularity!

53. Yes, to the degree it can reasonably
be expected to be (third case!)
Is Extension
ComposiEon
modular?
But with the limitaEons that semanEcs
cannot be staEcally checked to be compaEble.
Might be solved in the (far) future when all
transformaEons are declaraEve and analyzable.

54. Composing Type Systems
DeclaraEve
L1 L2

55. Composing Type Systems
DeclaraEve
L1 + L2
Order Irrelevant

56. Composing TransformaEons
DeclaraEve
Order Relevant

57. Composing TransformaEons
DeclaraEve
Order Relevant
Simple extension: D extends I

58. Composing TransformaEons
DeclaraEve
Order Relevant
Independent extension:
D1 and D2 extend I

59. Composing TransformaEons
DeclaraEve
Order Relevant
Stacked extension:
D2 extends D1 and extends I

60. Composing TransformaEons
DeclaraEve
Order Relevant
Indep extension with gen dep:
We did not encounter this.
Hyp. Example: Method, FuncEon, Logging.

61. Gevng the ordering right can be a
challenge. We discuss debugging later.
Once correct, the system works well.
Composing TransformaEons

62. RQ
1 Language
Modualarity
mbeddr’s 34 C extensions indicate that MPS’ language modularity
works. It is useful for language understanding, tesOng and reuse.
In rare cases, modularity is compromised by necessary changes to
the base language and unwanted dependencies between
independent extensions.
Currently there is no way to detect (unwanted) semanEc
interacEons between independent language extensions through
analysis of their transformaOons.

63. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr
RQ
2 ProjecEonal
EdiEng

64. ProjecEonal EdiEng
Language ComposiEon

65. SyntacEc Flexibility is actually useful
for end users – see Smart Meter.

66. Different NotaEons for one AbstracEon.
State Machines

67. Different NotaEons for one AbstracEon.
State Machines
But: type checks and some acEons
based on AST, not on what is shown.
This can be confusing to users.

68. OpEonally projected syntax.
Requirements Traces

69. Decoupled NotaEonal PrimiEves
Sum & Trees
Math in C and KernelF
Trees for decisions
and feature models

70. Developing new notaEons.
MPS is Bootstrapped.

71. Editor Usability
Strongly ... Neutral ... Strongly
agree disagree
People prefer MPS over convenEonal IDEs
MPS more is more efficient than normal IDEs
MPS more is more producEve than normal IDEs
MPS makes it easier to create correct programs
MPS enforces a structurally correct AST
People benefit from language modularity
People benefit from the flexible notaEons
The experience with learning MPS is mixed.
It takes some Eme to get used to MPS
Based on an empirical study.

72. Significantly Improved Editor Usability
Based on an empirical study.
Generic
CommenEng
Grammar Cells
(see SLE Paper)
Paleoes and other
input support uEls.
Top-Down Progr.
via Target CreaEon

73. But sEll issues/differences in Editor Usability
SelecEng code is structural, not linear
Copy/paste of similar syntax but
different structure requires customizaEon
Grammar cells go a (very) long way, but
not *every* ediEng acEon is possible.
PasEng from text requires integraEon
of a parser (hooks exist), not automaEc
Very few complaints since we did the improvements.
We consider the problem mostly solved.

74. Version Control IntegraEon
Fundamentally File-based
We used git – worked well
diff/merge in MPS
Can‘t use outside tools (gerrit)

75. RQ
2 ProjecEonal
EdiEng
Two main benefits of projecOonal ediOng – language modularity
and a range of combinable notaEons – have been used extensively
in mbeddr. The anOcipated benefits have been observed.
Editor can be flexibly extended with new notaOonal styles with
acceptable effort, as exemplified by math, tables and diagrams.
The ability to use mulEple and parEal projecEons must be further
improved by integraOng with other language aspects, in parOcular,
editor acOons and type checks.

76. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr
RQ
3 Managing
Complexity

77. ProjecEonal EdiEng
Reduced Complexity
Language modularizaEon
No disambiguaEon code

78. [Language Aspects]
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...

79. [Language Aspects]
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...
A separate DSL for each aspect
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints

80. [Language Aspects]
A separate DSL for each aspect
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
Each language opEmized for its task.
In our experience, separate aspect DSL
increase producEvity – as DSLs should.

81. [Language Aspects]
A separate DSL for each aspect, but:
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
essnOally Java + X. Mostly ImperaOve

82. [Language Aspects]
A separate DSL for each aspect, but:
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
essnOally Java + X. Mostly ImperaOve
DeclaraEve? { Analysis?
OpEmizaEon?

83. [Language Aspects]
A separate DSL for each aspect, but:
DeclaraEve? { Analysis?
OpEmizaEon?
The non-declaraEveness leads to problems in
analysis (impact, debugging, verificaEons) or
opEmizaEon (caching).

84. [Language Aspects]
A separate DSL for each aspect. Debugging?
Editor

85. [Language Aspects]
A separate DSL for each aspect. Debugging?
TransformaEons

86. [Language Aspects]
A separate DSL for each aspect. Debugging?
Type System

87. [Language Aspects]
A separate DSL for each aspect. Debugging?
System.out.println(...);
All in all, the debugging experience is not
where it should be. Needs improvement.
All the rest...

88. [Language Aspects]
A separate DSL for each aspect, but missing aspects:
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
essnOally Java + X. Mostly ImperaOve
DocumentaOon
Debugger
Interpreter
...
Since MPS 3.3, one can define custom aspects.

89. MPS is bootstrapped.
meaning: it is built with itself.
it can be extended with itself.

90. MPS is bootstrapped.
meaning: it is built with itself.
it can be extended with itself.
DeclaraEve type mappings
Type Guards
Concise syntax, especially for recursive calls
Composable (just as languages)
AbstracEons for environments and stacks Interpreter

91. MPS is bootstrapped.
meaning: it is built with itself.
it can be extended with itself.
IncA
Restricted, DeclaraEve Language
Transformed to Paoerns
Executed incrementally
Very fast!

92. MPS is bootstrapped.
meaning: it is built with itself.
it can be extended with itself.
New primiEve editor cells for math, diagram, tables
More query-oriented than default MPS notaEons
NotaEon independent from Language
Editor

93. RQ
3 Managing
Complexity
Using a DSL for each language aspect works well based on our
experience, even though some aspects are missing and some are
not declaraOve enough to support meaningful analyses.
The support for debugging is spooy: it works well for
transformaOons, but debugging generator macros, behav- iors and
type system rules is very tedious.
The ability to extend MPS’ language definiOon DSLs with MPS
itself is a powerful approach for managing complexity, and we
have used it extensively, even though it has some limitaOons.

94. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr
RQ
4 Tool
Scalability

95. Editor Responsiveness
The bigger one root gets, the slower the
editor gets because more “stuff” must
be rendered:
- incrementally rendered, but sEll ...
- depends on the notaEon
- 3000 “lines” of C code
Split into several roots.
Impacts Language Design.

96. Editor Responsiveness
Code compleEon is extremely criEcal:
you can only enter what has been “put into”
the code compleEon menu. => Tree Constraints
Scopes

97. Type Checking and Constraints
Type checking is incremental, and happens
in the background.
Checks may run long – but are interruptable.
But both need locks on the repo: they can
lead to performance issues.
=> Cancellable Checks
Assessments
SelecEve Enabling
“Energy Saver Mode”

98. TransformaEon
The model with 128 roots corresponded to 68,400 LoC of generated C
code (for Plain C), 202,000 LoC (C + State Machines) and 198,000 LoC (C
+ State Machines + Units + Components).
GeneraEon Eme (in seconds)
# of roots with 1,000 nodes each

99. TransformaEon
GeneraEon Eme (in seconds)
# of roots with 1,000 nodes each
Time Size && Time Intermediate Model Volume ~ ~

100. RQ
4 Tool
Scalability
With ahenOon to root size and the distribuOon of code over
models, then systems of significant size can be built with MPS.
The performance of the type system (as it is evaluated in realOme
in the editor) and support for cross-model generaEon are the two
most criOcal ways of improving MPS performance.
During the development of languages we have not run into any
problems regarding performance or scalability (of editor, type
system or generator definiOons).

101. What can
we learn?
5
Lessons Learned
about Language
Engineering from the
Development of
mbeddr
RQ
5 Development
Process

102. TesEng the editor
No need to test if “parsing” works.
But you have to check if you can enter what
you need to enter, where you think it belongs.

103. TesEng the editor
No need to test if “parsing” works.
And you have to test if the the tree is con-
structure correctly when linear input is used.

104. TesEng the type system
Do typing rules and constraints work?
EssenEally check if the red squigglies
show up where you expect them.

105. TesEng semanEcs
Whenever possible, test semanEcs by
execuEon and test cases, and not by checking
(the structure of) the generated code.

106. TesEng semanEcs
Test case generaEon:
• Select a set of language extensions
• Randomly generate structurally sound programs
• If the type system finds errors in the program, discard
the program (because errors are correctly reported)
• If the program has no errors, try to generate and
compile it. If either generaOon or compilaOon fails, flag
this parOcular generated program as a failed test.
Helps finding inconsistencies in the mulE-
stage transformaEon process.

107. Version Control
Works. As long as you are willing to
use MPS for diff/merge.

108. CI Server IntegraEon
We successfully run all our builds, tests and
packaging on
However, the effort to get the MPS builds
to run there is too high
the usual build dependency hell
the MPS build language is not flexible enough
maybe iniEally not enough experience with “build stuff”
Also, builds tend to take (too) long.
a full mbeddr build takes 12 minutes on the server and ca.
30 minutes on a fast developer PC
Mixed bag!

109. Languages have version numbers
MigraEon of Models
Automated refactorings increment that
number; so can developers.
MigraEon scripts bring models up to date
based on the language versions.
Mixed bag!
This is already more than in most other
tools we know about. But it is clumsy and
someEmes slow.

110. RQ
5 Process
IntegraEon
Except for the missing test support for model migraOons and
single-step transformaOons, language tesEng works well; we have
achieved good coverage as demonstrated by a stable code base.
We have successfully integrated mbeddr’s build, test and
packaging with the Teamcity CI server, but the effort was too high,
parOally because of the inadequacy of MPS’ build language.
MigraEng models as languages change incompaObly is feasible
with manually scripted migraOons and their automaOc execuOon
based on implicitly-maintained language version numbers.

111. Concluding
Thoughts
6
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

112. C is a strange language
The details were
harder to build than
we iniEally thought.
But MPS can do it!

113. Language is not enough.
IDE, Debugger,
Analyses, Interpreter.

114. Tool Chrome hurts.
MPS „looks“ too complicated
for the prospecEve end user.

115. Onboarding devs.
It took 4 – 8 weeks to get
competent new devs on board.

116. OpEmizing Generators
is hard :-)

117. Modularity vs. OpEmizaEon
Global opEmizaEon are in
conflict with modularity
and extensibility.
Perhaps two generators?

118. Open vs. Closed World
How do you build trust
into a system that is
inherently extensible?

119. More DeclaraEveness
More declarariveness and inproved
ability to analyze language definiEon
code would help!

120. Shadow Models
We need incremental, real-Eme,
mulE-step, in-IDE transformaEons
for advanced analyses.

121. Change is hard.
ProspecEve users were hard
to convince to adopt mbeddr.

122. Wrap
Up
7
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

123. MPS is a capable LWB.
Overall we are happy and conEnue to use it.
It is definitely ready for real-world use
mbeddr – and this evaluaEon – is testament to that.
Many architectural desicisons are good...
ProjecEon, Aspect DSLs, Bootstrapping.
... but it has some weak points as well.
Internal complexity, imperaEveness, build, fat Java client.
A good choice for LE projects today.
Great starEng point for next gen LWBs :-)