Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Build your own Language - Why and How?

28 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Build your own Language - Why and How?

  1. 1. Build your own Markus Völter voelter@acm.org www.voelter.de @markusvoelter Why and How?
  2. 2. 1 Motivation
  3. 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. 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. 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. 6. Formal Language. Checkable. Understandable. DSLDomain Specific Language
  7. 7. M1 M2 M3 L1 L2 L3 def := … def := ∃ ⊢ #$α def := … .... LM ∃, ⊢, #, $, α <meta> <meta> <meta> <meta> <meta> <meta> LANGUAGEDEFINITION
  8. 8. 2 Examples
  9. 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. 10. Public Benefits
  11. 11. Data Flow Programming
  12. 12. Tachograph Rules
  13. 13. Math Insurance Math
  14. 14. Satellite Software
  15. 15. Healthcare
  16. 16. Healthcare
  17. 17. http://voelter.de/data/pub/MPS-in-Safety-1.0.pdf
  18. 18. 3 MPS Demo
  19. 19. (Meta-) Tooling Language Workbench Open Source, by Jetbrains Very Powerful Used for years by itemis and others Vast Experience
  20. 20. (Meta-) Tooling Language Workbench Open Source, by Jetbrains Very Powerful Used for years by itemis and others Vast Experience
  21. 21. MPS: Language Toolkit
  22. 22. MPS: Notational Freedom
  23. 23. MPS: Language Composition
  24. 24. MPS: Language Composition Embedding/Extending the KernelF functional language is key to DSL development productivity.
  25. 25. TU Delft itemis/Typefox CWI Amsterdam Solmi/Persiani Rascal The Whole Platform Other Language Workbenches
  26. 26. http://voelter.de/data/pub/LWB-ResultsAndBenchmarks.pdf
  27. 27. 4 Lessons Learned
  28. 28. A Language is not Enough
  29. 29. 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
  30. 30. Influences on the Language
  31. 31. 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
  32. 32. 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!
  33. 33. How to make People precise?
  34. 34. Precision Programming != { Formulas, Rules Data Structures Tables Values } Performance Scalability Robustness Deployment
  35. 35. Training is required.
  36. 36. Skills?
  37. 37. Organizations do not have the necessary skills. True. But...„ “ AI Big Data Agile R E S T So build it. Evolve. Hire. Buy.
  38. 38. Is this the next legacy system?
  39. 39. „ “Today‘s software is tomorrow‘s legacy system. Or is it?
  40. 40. Language Tech 1 V1 V2 V3 .... Evolution Existing models become incompatble with new language ÞLanguage Versions Migration Scripts Runtime T 1 Generator 1
  41. 41. 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
  42. 42. 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
  43. 43. „ “Today‘s software is tomorrow‘s legacy system. No, it is not.
  44. 44. In conflict with Agile?
  45. 45. 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
  46. 46. 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.„ “
  47. 47. 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.„ “
  48. 48. 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?
  49. 49. 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.„ “
  50. 50. 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
  51. 51. What about CI?
  52. 52. You integrate like any other automatable CI step.
  53. 53. 5 Wrap Up
  54. 54. http://voelter.de/data/pub/voelterEtAl2017-buildingMbeddr.pdf
  55. 55. 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!

×