Languages for non-developers - invited keynote FedCSIS 2024

Productivity has improved each time programming languages have raised the level of abstraction. This trend continues today with languages that narrow the scope they address – referred to as domain-specific languages (DSLs). However, many of these DSLs are built by developers for developers and tend to concentrate on the solution domain rather than the problem domain. In this talk, I will advocate for languages to be aligned more closely with the problem domain, addressing the needs of domain experts. Such languages enable non-developers to capture and communicate their knowledge, and together with tools support testing, validation, and feedback. Tools can also transform precise knowledge representations into software code and other artifacts. I will provide examples of non-developer languages used by usability experts, safety engineers, insurance experts, and instrumentation experts. These languages differ from traditional programming languages as they aim to align more closely with the domain, representing knowledge through maps, diagrams, or tables rather than with plain text only. The talk will identify key characteristics of non-developer languages and discuss how creating them differs from programming languages. This leads us to envision the role of non-developers in language creation and identify domains in which non-developer languages are more suitable.

1. © 2024 JPT 1
Juha-Pekka Tolvanen
[email protected]
Languages for non-developers
what, how, where?

2. © 2024 JPT 2
Software everywhere
Software explosion
Software is eating the world
1950 1960 1970 1980 1990 2000 2010 2020

3. © 2024 JPT 3
Continuous growth of functionality

4. © 2024 JPT 4

5. © 2024 JPT 5
Source: NASA, July 20, 1969
Apollo GuidanceComputer
software in 36K words
(16-bit wordlength)
Lawn mower robot:
software upgrade: 527 MB
(.msipackage)

6. © 2024 JPT 6
Also complexity is growing faster than
software development productivity

7. © 2024 JPT 7
How to improve productivity?

8. © 2024 JPT 8
Solution?
◼More developers
◼New frameworks
◼Better tools
◼More automation
◼AI
◼?
◼Better languages, also for non-developers

9. © 2024 JPT 9
Solution?
API query: https://pxdata.stat.fi:443/PxWeb/api/v1/en/StatFin/tyti/statfin_tyti_pxt_13au.px
Statistics Finland's interface service with the licenseCC BY 4.0

10. © 2024 JPT 10
0111 1111
0100 0101
0100 1100
0100 0110
0000 0010
0000 0001
0000 0000
0000 0000
0000 0010
0010 0000
0000 0010
0000 0010
0000 0000
0000 0000
org100h
movah,9h
movdx,offsettext
int21h
ret
text: db ‘hello$’
int main(void)
{
printf("Hello\n");
return 0;
}
int main(void)
{
cout<<"Hello"<<endl;
return 0;
}
Transcript show:'Hello'.
Abstraction
Automation

11. © 2024 JPT 11
Flow diagram for ENIAC,
John von Neumann,
1950 Manuscript
Division, Library of
Congress (164)

12. © 2024 JPT 12

13. © 2024 JPT 13
General purpose

14. © 2024 JPT 14
Domain-specific

15. © 2024 JPT 15
Domain-Specific Languages
◼Narrow, very narrow
◼Aim for 100% fit with the problem domain
◼Raise the level of abstraction, hide unnecessary details
◼External and internal

16. © 2024 JPT 16
Gothic Security*
publicclassBasicStateMachineextendsStateMachineBuilder{
EventsdoorClosed, drawerOpened, lightOn, panelClosed;
CommandsunlockPanel, lockPanel, lockDoor, unlockDoor;
Statesidle, active, waitingForLight, waitingForDrawer, unlockedPanel;
ResetEventsdoorOpened;
protectedvoiddefineStateMachine() {
doorClosed.code("D1CL");
drawerOpened.code("D2OP");
lightOn.code("L1ON");
panelClosed.code("PNCL");
doorOpened.code("D1OP");
unlockPanel.code("PNUL");
lockPanel.code("PNLK");
lockDoor.code("D1LK");
unlockDoor.code("D1UL");
idle
.actions(unlockDoor, lockPanel)
.transition(doorClosed).to(active)
;
active
.transition(drawerOpened).to(waitingForLight)
.transition(lightOn).to(waitingForDrawer)
;
waitingForLight
.transition(lightOn).to(unlockedPanel)
;
.transition(drawerOpened).to(unlockedPanel)
;
unlockedPanel
.actions(unlockPanel, lockDoor)
.transition(panelClosed).to(idle)
;
}
}
*Fowler, Domain-Specific Languages, Addison-Wesley, 2008
EventdoorClosed =newEvent("doorClosed", "D1CL");
EventdoorOpened =newEvent("doorOpened", "D1OP");
EventlightOn=newEvent("lightOn", "L1ON");
EventdrawerOpened=newEvent("drawerOpened", "D2OP");
EventpanelClosed=newEvent("panelClosed", "PNCL");
CommandunlockDoorCmd=newCommand("unlockDoor", "D1UL");
CommandlockPanelCmd=newCommand("lockPanel", "PNLK");
CommandunlockPanelCmd=newCommand("unlockPanel", "PNUL");
CommandlockDoorCmd=newCommand("lockDoor", "D1LK");
StateMachinemachine=newStateMachine(idle);
StateactiveState=newState("active");
StateidleState=newState("idle");
StateunlockedPanelState=newState("unlockedPanel");
StatewaitingForDrawerState=newState("waitingForDrawer");
StatewaitingForLightState=newState("waitingForLight");
activeState.addTransition(lightOn, waitingForDrawerState);
activeState.addTransition(drawerOpened, waitingForLightState);
idleState.addAction(unlockDoorCmd);
idleState.addAction(lockPanelCmd);
idleState.addTransition(doorClosed, activeState);
unlockedPanelState.addAction(unlockPanelCmd);
unlockedPanelState.addAction(lockDoorCmd);
unlockedPanelState.addTransition(panelClosed, idleState);
waitingForDrawerState.addTransition(drawerOpened, unlockedPanelState);
waitingForLightState.addTransition(lightOn, unlockedPanelState);
machine.AddResetEvents(doorOpened);

17. © 2024 JPT 17
Domain-Specific Languages
◼Narrow, very narrow
◼Aim for 100% fit with the problem domain
◼Raise the level of abstraction, hide unnecessary details
◼External and internal
◼Not a new idea!
◼Applied also outside the software world!

18. © 2024 JPT 18
Mimic closely the domain
1 2
4
3
3
4
4
4
1
1
1
1

19. © 2024 JPT 19
Debug, confirming errors

20. © 2024 JPT 20

21. © 2024 JPT 21
1.Picked 200 cases
2.Then selected 100
(knowing who created them)

22. © 2024 JPT 22
Who implemented languages? (n=100)
51 %
17 %
32 %
in-house
external consultant
both

23. © 2024 JPT 23
Domains of the languages (n=100)

24. © 2024 JPT 24
Size of the metamodels (n=39)

25. © 2024 JPT 25
Primary language user (n=100)
9 %
27 %
8 %
1 %
55 %
Programmer
Domain expert
Between
Both
Unknown

26. © 2024 JPT 26
Primary language user (n=45)
20 %
60 %
18 %
2 %
Programmer
Domain expert
Between
Both

27. © 2024 JPT 27
Size and user (n=24)

28. © 2024 JPT 28
Size and language creator (n=39)

29. © 2024 JPT 29
A language for insurance experts
◼Key language elements:
–Product & product bundle
–Calculation basis
–Damage
–Insured object
–Danger
–Product cover
–Event
–Payment
–Policyholder
–Risk
–Insured person
–Tariff

30. © 2024 JPT 30
Languages for UX, usability experts

31. © 2024 JPT 31
Example: fish farm automation

32. © 2024 JPT 32
Example: heating system
Code
Autobuild
API desc
BoM
Deployment
guide

33. © 2024 JPT 33
4 railway DSLs

34. © 2024 JPT 34
Languages for safety (e.g. ISO26262)
◼Item
◼Hazard
◼Hazard event
◼Safety goal
◼Safety concept
◼Feature flaw
◼ASIL
–Exposure
–Severity
–Controllability

35. © 2024 JPT 35
How languages are created?
Modelingabstract syntax
concrete syntax semantics

36. © 2024 JPT 36
What is needed beyond metamodel
1.Concrete syntax matters
2.Involvement of language users = active participation
3.(Automated) support for language use
–Errors
–Warnings
–Guidance
–Simulation
–Animation
4.Expect evolution and co-evolution with work done

37. © 2024 JPT 37
1. Concrete syntax matters
◼Mimic the problem domain
◼Accepted by users
◼Symbols should use full range of visual variables*
* . y, T “ y ” N , EEE T E , . 35, . 6, 2009

38. © 2024 JPT 38

39. © 2024 JPT 39
2. Enable participation
◼Try early
–Examples of typical apps/features/systems, not metamodel
–Prototype, ready to throw away
–Narrow to minimum what is needed

40. © 2024 JPT 40
Case: manually tested to released

41. © 2024 JPT 41
2. Enable participation
◼Try early
–Examples of typical apps/features/systems, not metamodel
–Prototype, ready to throw away
–Narrow to minimum what is needed
◼Collaborative work: create & use DSL at the same time
–Ask to define notation
–Give (read-only or partial) access to the language
definition
◼Collect feedback
–Get feedback when language is used
–Via tool or even via the language itself

42. © 2024 JPT 42
3. Support for language users
◼Not only basics of language, but also covering
–Errors
–Warnings
–Guidance
–Views
–Animation
–Simulation
◼Examples
–Tutorials
–Typical cases

43. © 2024 JPT 43
Graphical
Animationof
Run-timeValues

44. © 2024 JPT 44
*Kelly, Tolvanen. Automated Annotations in Domain-Specific Models: Analysis of 23 Cases. STAF Workshops, 2021

45. © 2024 JPT 45
4. Evolution and Co-evolution
◼Domain evolves
◼Users learn
◼External requirements must be met
➢Language evolves
➢Existing work must evolve too
◼Ideally, updates automatically
–Manual work and transformations are often not practical

46. © 2024 JPT 46
Evaluation framework: 4 aspects*
2 Location
of Change
↓
1 Nature of Change
Add Rename Remove Change
Metamodel 1 4 7 10
Constraints2 5 8 11
Notation 3 6 9 12
4 Scale for scoring co-evolution:
1.When creating a new artifact, editor does
not open or gives errors
2.Editor opens without functionality
3.Editor allows creating a new artifact but
support for viewing and editing
earlier artifacts is incomplete
4.Editor opens and asks for human
intervention to finalize co-evolution
4½ if existing models behave and
generate, and deprecation guidance is
provided where needed
5.Editor opens with fully co-evolved
earlier artifacts
1 Nature of Change
Add Rename Remove Change
3 Location adversely impacted
•Metamodel, Constraints, Notation
•Generators, Tool, Models
* Tolvanen and Kelly. Evaluating Tool Support for Co-Evolution of Modeling
Languages, Tools and Models. ACM/IEEE MODELS Conference companion, 2023

47. © 2024 JPT 47
What about tools?
◼6 ways to get the tools we need for our language
1.Write own modeling tool from scratch
2.Write own modeling tool based on frameworks
3.Metamodel, generate modeling tool skeleton, add code
4.Metamodel, generate full modeling tool over a framework
5.Metamodel, output configuration for generic modeling tool
6.Integrated modeling and metamodeling environment
◼Single-user, collaborative
◼Versioning (not as traditional VCS), a domain-specific
◼Easy to access and learn, supported, training etc.

48. © 2024 JPT 48
Tooling

49. © 2024 JPT 49
Tools in different domains*
* Ozkaya, M., Akdur, D., What do practitioners expect from the meta-modeling tools?
A survey, Journal of Computer Languages, Vo 63, 2021

50. © 2024 JPT 50
Where to apply? Where not?
◼Timing is crucial
–At certain times organizations are ready for the change
◼Repetition
–Product line, configurable product, many similar features
◼Domain knowledge is substantial
–Business/domain rules have a big role, domain
experts/subject matter experts needed
◼Not if:
–No repetition, new domain, unstable domain, multiple
organizations involved, no resources to create languages

51. © 2024 JPT 51
Cost of language creation:
industry cases*
* Tolvanen and Kelly. Effort Used to Create Domain-Specific Modeling Languages.
ACM/IEEE Conference on Model Driven Engineering Languages and Systems, 2018

52. © 2024 JPT 52
Concluding remarks
◼Languages for non-developers allow wider range of people
to participate in developing software systems
–Define, check, validate, collaborate, test etc.
◼Languages for domain-experts must:
–Raise abstraction above code, close to the problem domain
–Apply rich knowledge representations (maps, diagrams etc.)
–Provide more than just spec creation features, like guidance,
k , m , m …
◼Modern tools assist in creating and using languages

53. © 2024 JPT 53
Thank you
Questions?
Comments?
Counterarguments?
Experiences?
Contact: [email protected]

54. © 2024 JPT 54
About me: Juha-Pekka Tolvanen
◼Works for MetaCase
–Provider of modeling and code generation tool MetaEdit+
◼Acts as a consultant for creating modeling languages
–100+ DSL solutions
◼Co-author of a book on
Domain-Specific Modeling, IEEE-Wiley
◼PhD in computer science,
adjunct professor
◼Enjoys sailing and skiing