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.

Envisioning the Future of Language Workbenches

11 views

Published on

Over the last couple of years, I have used MPS successfully to build interesting (modeling and programming) languages in a wide variety of domains, targeting both business users and engineers. I’ve used MPS because it is currently the most powerful language workbench, lots of things are good about iz, in particular, its support for a multitude of notations and language modularity. But it is also obvious that MPS is not going to be viable for the medium to long term future; the most obvious reason for this statement is that it is not web/cloud-based. In this keynote, I will quickly recap why and how we have been successful with MPS, and point out how language workbenches could look like in the future; I will outline challenges, opportunities and research problems. I hope to spawn discussions for the remainder of the workshop.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Envisioning the Future of Language Workbenches

  1. 1. Markus Völter voelter@acm.org www.voelter.de @markusvoelter Envisioning Future Language Workbenches
  2. 2. Where I come from I
  3. 3. Precision Programming != { Formulas, Rules Data Structures Tables Values } Performance Scalability Robustness Deployment + Tests
  4. 4. All languages shown in this talk are built with the open source JetBrains MPS language workbench.
  5. 5. MPS Language Workbench Language Workbench Open Source, by Jetbrains Very Expressive Used for years in industry Vast Experience
  6. 6. + Refactorings, Find Usages, Syntax Coloring, Debugging, ... MPS Language Workbench
  7. 7. MPS: Notational Freedom 100% crucial for acceptance in domain! Rabbit Hole Modeling is more than diagrams!
  8. 8. MPS: Language Composition SPLE on Language Level!
  9. 9. Language Patterns New Language GPL Extension Existing Domain Notation (Informal) Formalization Formalized Language Reuse GPL incl. Expressions and TS Add/Embed DS-extensions Compatible notational style Reduce to GPL Analyze Domain to find Abstractions Define suitable, new notations Rely on existing behavioral paradigm Reuse standard expression language Interpret/Generate to one or more GPLs Use existing notation from domain Clean up and formalize Generate/Interpret Often import existing „models“ Language Extension Patterns
  10. 10. Language PatternsLanguage Flavours
  11. 11. Language Concerns II
  12. 12. Realtime Incremental Transformations 1
  13. 13. Example Use Cases • Mapping of system models to model checkers for interactive verification of temporal properties • Flattening of component hierarchies for type checking • Flattening of hierarchical feature models for path expression evaluation • Weaving in of safety concerns into C code. • Desugaring of business DSLs to a core functional language; that core language would then feature an interpreter, a compiler and an integration with an SMT solver
  14. 14. What is Shadow Models? Functional transformation language with support for fixpoints Incremental execution upon change of input model Unidirectional, but with first-class support for lifting results Fully integrated into MPS IDE Code: https://github.com/JetBrains/MPS-extensions/tree/master/code/shadowmodels Docs: https://jetbrains.github.io/MPS-extensions/extensions/shadowmodels/
  15. 15. Mechanics Input Model Shadow Model ... ‚ User edits the input model A delta is propagated into the transformation engine A change on the shadow model is produced This triggers analysis or update of results in Shadow Model Results/messages are lifted back to input level Results are annotated to the input model Mightbestacked
  16. 16. Kf2 Core Interpreter Generator Verifier Sugar DSL1 DSL2 DSL3 ShadowModels • Minimal, Expressive Core • Functional • Reactive • Sugar on top • Interpter, Generator and Verifier below • Realtime-Trafo with Shadow Models
  17. 17. Kf2
  18. 18. Semantics 2
  19. 19. LWBs Semantics
  20. 20. LWBs Semantics
  21. 21. LWBs Semantics
  22. 22. LWBs + Semantics
  23. 23. Semantics Spec Interpreter Compiler Verifier Functional + Imperative + Reactive The tools exist: K, Funcons, VDM IDE Deployment Correctness But there is very limited integration with LWBs. Exception: Spoofax + Funcons
  24. 24. Semantics Grow on (imperative) C
  25. 25. KernelF Semantics Functional Interpreter Reactive Interpreter Several Projects / DSLs Grow on Functional Language...
  26. 26. KernelF Semantics Solver Model Checker Rules Engine Functional Interpreter Reactive Interpreter Several Projects / DSLs Lots of ideas J Grow on Functional Language... ... and other Foundations.
  27. 27. Liveness 3
  28. 28. Beyond Balls and Trees Not too much has happened since the legandary demo. Overlay program execution data Run tests and illustrate results in the background. Instance-based programming (Jonathan Edwards) That‘s it? What else can we do? Which LWB-support can be build?
  29. 29. Why do people like Excel?
  30. 30. Beyond Balls and Trees
  31. 31. Beyond Balls and Trees Not too much has happened since the legandary demo. Overlay program execution data Run tests and illustrate results in the background. Instance-based programming (Jonathan Edwards) That‘s it? What else can we do? Which LWB-support can be build?
  32. 32. Debuggers 4
  33. 33. Debuggers Different ones for different language paradigms Functional => Tree Imperative => Stepping Declarative => ?
  34. 34. Debuggers Different ones for different language paradigms Functional => Tree Imperative => Stepping Declarative => ? Often the (semantic reverse) of generation it has to recover DSL semantics for watches, views, breakpoints Related to simulators and „model animators“ No good tool support for building them! Realtime vs. Post Mortem
  35. 35. Language Parametrization & Interfaces 5
  36. 36. Language Composition
  37. 37. Language Composition Defining „abstract“ languages with holes Example: State machines with pluggable expression language What is the type of those that can be plugged in? Language Types or Interfaces / Megamodels Example: How do you descibe a „valid“ expression language? Does this include execution sematics?
  38. 38. Tool Concerns III
  39. 39. Guidance 6
  40. 40. Applications
  41. 41. Applications Modeling Toolvs. But not like that! Novice Users need Guidance!
  42. 42. Applications Modeling Toolvs. Novice Users need Guidance!
  43. 43. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? Roles
  44. 44. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? What should I do next? Roles Tasks, Workflow
  45. 45. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? What should I do next? How complete is my model? Roles Tasks, Workflow Model States
  46. 46. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? What should I do next? How complete is my model? What is the quality of my model? Roles Tasks, Workflow Model States Metrics
  47. 47. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? What should I do next? How complete is my model? What is the quality of my model? Roles Tasks, Workflow Model States Metrics Defined jointly with the language.
  48. 48. Permissions 7
  49. 49. Permissions Which user groups can see and edit which part of the model? Can we define views for showing parts or aspects of models. Proxies for „hidden details“?
  50. 50. Collaboration 8
  51. 51. Version Control Systems are a problem
  52. 52. Version Control Systems are a problem https://git-man-page-generator.lokaltog.net/ But file-based version control is often not suitable.
  53. 53. Google Docs Style Collaboration Realtime collaboration à la Google Docs Language/structure-aware Some level of transaction or isolation Some version of branching.
  54. 54. The cloud 9
  55. 55. Cloud Backend Local vs. „real“ Data Protection! LSP-style frontend.
  56. 56. Browser Frontends
  57. 57. Become more App-Like UI must be less like an IDE. Things must look slicker! It must be easier to integrate with web apps that are developed without the LWB: Microservice-style modeling „services“ Integration on common backend and also with non-model apps.
  58. 58. Bring in M0 Language DSLs Language Model User Data M0 M1 M2 M3 Part of the LWB Defined using the LWB Should feel like IDE Should be on the web Not feel like IDE Completely outside in generated App/DB
  59. 59. Bring in M0 Language DSLs Language Model M3 Part of the LWB User Data Bring into joint repository. Simplified Migration of models. MetaEdit+ does this.
  60. 60. Bring in M0 Language DSLs Language Model User Data M3 Part of the LWB Bring into joint repository. Simplified Migration of models. MetaEdit+ does this. User-data also needs (incremental) analysis, transformation and migration. Should also scale indefinitely. Why „externalize“ through generation etc?
  61. 61. Scale Down 10
  62. 62. Get Rid of IDE feel
  63. 63. Make it simpler. https://alarmingdevelopment.org/ In terms of UI But also in terms of paradigm. Is functional or imperative the answer?
  64. 64. Make it modular(er).
  65. 65. Explain Communicate Convince Educate BBonus
  66. 66. Maybe more important! ! How do we call what we do? How do we de-risk tools? What are the right paradigms? Computational Thinking End-User programming Case Studies

×