Downloaded 421 times
![Projectionaltree… to text-lookalike (editor)… to other trees … [*]… to text](https://image.slidesharecdn.com/fromprogrammingtomodelingandbackagain-091104013255-phpapp02/75/From-Programming-to-Modeling-And-Back-Again-159-2048.jpg)
Uploaded byMarkus Voelter
From Programming to Modeling And Back Again
This document discusses programming languages and modeling. It notes that programming languages are not expressive, high-level, abstract, domain-specific, or modular enough. It proposes addressing this by using modeling with higher-level, domain-specific concepts and notations, and code generation from models. However, modeling and programming tools have traditionally been separate worlds. The document envisions a future where modeling and programming are integrated by mixing models and programs, and developing languages and tools that support programming at different levels of abstraction from different viewpoints. Enabling technologies could include advanced parser generators and projectional editing, while available tools mentioned include Eclipse Xtext and JetBrains' Meta Programming System for developing domain-specific languages.
More Related Content
Similar to From Programming to Modeling And Back Again
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
From Programming to Modeling And Back Again
- 1. Programming fromtoModeling…and backagainMarkus VoelterIndependent/[email protected]
- 2.
- 3.
- 4.
- 5. Programming Languagesare notexpressiveenough.ErlangC#C++PythonJavaRubyGroovyFortranC
- 6. Programming Languagesare nothigh-levelenough.ErlangC#C++PythonJavaRubyGroovyFortranC
- 7. Programming Languagesare notabstractenough.ErlangC#C++PythonJavaRubyGroovyFortranC
- 8. Programming Languagesare notdomain-specificenough.ErlangC#C++PythonJavaRubyGroovyFortranC
- 9. Programming Languagesare notenough.ErlangC#C++PythonJavaRubyGroovyFortranC
- 10.
- 11.
- 12. Programming LanguagesFormatsFrameworksenough.are notErlangC#C++PythonJavaDjangoRubyGroovyWPFFortranjsonCJEEJMSHTMLCSSRailsyamlXMLlift
- 13.
- 14.
- 15.
- 16.
- 17. Modeling… Higher Level…Domain SpecificConcepts & Notations… Code GenerationInterpretation
- 18. Modeling… Higher Level…Domain SpecificConcepts & Notations… Code GenerationInterpretationSolvestheProblem!
- 19.
- 20.
- 21.
- 22. Different WorldsMix Modelsand Programs
- 23. Different WorldsMix Modelsand ProgramsAST Navigation & Query
- 24. Different WorldsMix Modelsand ProgramsAST Navigation & QueryIntegration of 3GL code
- 25. Different WorldsMix Modelsand ProgramsAST Navigation & QueryIntegration of 3GL codeCode Constraints
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32. CustomValidationorError ChecksLimited!Flexible!IDE pluginsStaticAnalysisOpen Compilers
- 33. DifferentRepresentationsandProjectionsLimited!Flexible!Text is TextCodeFoldingTree ViewsVisualizations
- 34.
- 35.
- 36.
- 37.
- 38. Gets theGets someJobDone!Jobs done.some people doubt that…everybody agrees…
- 39.
- 40.
- 41.
- 42. ModelingProgramming… (Mostly) Textual Notations… Concrete Syntax Storage… (Fancy) ASCII Editors… Read-Only Visualizations
- 43. ModelingProgramming… (Mostly) Graphical Notations… Abstract Syntax Storage… Projecting Editors… Different editable views for model… (Mostly) Textual Notations… Concrete Syntax Storage… (Fancy) ASCII Editors… Read-Only Visualizations
- 44.
- 45. It is timefor …
- 46. … a DifferentPerspective
- 47. Programmingthe waywe doModeling?Modelingthewaywe doProgramming?
- 48.
- 49. We don‘t wanttomodel,we want toprogram!
- 50. We don‘t wanttomodel,we want toprogram!… at different levels of abstaction… from different viewpoints… integrated!
- 51. We don‘t wanttomodel,we want toprogram!… with different degrees of domain-specificity… with suitable notations… with suitable expressiveness
- 52. We don‘t wanttomodel,we want toprogram!And always:precise and tool processable
- 53. Where do wego from here?
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62. Programming Language SyntaxisnotFLEXIBLEenough.
- 63. Big Language?withmany firstclass concepts!
- 64. Small Language?with afew, orthogonaland poweful concepts
- 65. abcdefghijklModular Languagewith manyoptional,composable concepts
- 66.
- 67. Modular LanguageLikeframeworksandlibraries, butwithsyntaxand IDE support
- 68. Not a newidea…
- 71. Growing A Language(GuyL Steele)
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 116. (Seemingly)Simple ExampleAddingmatricesto Cin an embeddedenvironment.
- 117.
- 118. Currently:Matricesnot supportedin XMLformat and generator
- 119. Currently:Tool teamwould havetodo the extension… a lot of work… busy… one central tool
- 120. Currently:No real compilersupportin the resulting C code… type checks… operator overloading… generics (matrix<int>)… matrix syntax?
- 122.
- 123. Better Solutiongeneric matrixand vector types
- 124. Better Solutionreal matrixand vector literals
- 125. Better Solutionsyntaxhighlights forvectors and matrices
- 126.
- 127. Better Solution operatoroverloadingstaticoptimization…symmetrical matrices… identity matrix… diagonal matrices
- 128.
- 129. Better Solutionaseparate languagemoduleused only bythose whoreally need it
- 131. In addition: PLEVariabilityannotatingvariabilityexpressionsto arbitrary regions
- 132. In addition: PLEVariabilityannotatingvariabilityexpressionsto arbitrary regions statically checked
- 133. In addition: PLEVariabilityannotatingvariabilityexpressionsto arbitrary regions project variant
- 135.
- 138.
- 139.
- 140. Modeling as Programmig…(Mostly) Textual Notations… Concrete Syntax Storage… (Fancy) ASCII Editors… Read-Only Visualizations
- 141.
- 142.
- 143.
- 144. Xtext-like Toolsprovide editorsupportCustom EditorsTeamworkGoto DefFind RefsRefactoring
- 145. Limited toUnicodehow tohandlenon-character symbols
- 146. Graphics !=Texttwo worlds…separateeditors… per syntax/viewpoint… models can still be ref integrated
- 148. What if!combine languagessameseq<Char> asdifferent tokens?
- 149.
- 150. Traditionally:Language ::= Token* | Rule*;
- 151. Traditionally:Language ::= Token* | Rule*;Token ::= Character*;
- 152. Traditionally:Language ::= Token* | Rule*;Token ::= Character*;Rule ::= Token* | Rule;
- 153. Traditionally:Language ::= Token* | Rule*;2 Phases:1. Global Tokenization(aka Scanning)2. Grammar Recognition(aka Parsing)
- 154. Modern:Language ::= Rule*;Rule ::= Char* | Rule*;1 Phase:Grammar Recognitiondirectly on char*
- 155. ScannerlessParsingNo Ambiguitywhen combininglanguagesAlways Parsable.(well, almost. There are some corner cases…)
- 157.
- 158. text… to tree…to textParser-based
- 159. Projectionaltree… to text-lookalike(editor)… to other trees … [*]… to text
- 160. Programming as Modeling…(Mostly) Graphical Notations… Abstract Syntax Storage… Projecting Editors… Different editable views for model
- 161. Programming as Modeling…(Mostly) Graphical Any kind of Notations… Abstract Syntax Storage… Projecting Editors… Different editable views for model
- 162. LanguageCompositionThere‘sno parsing.Unique LanguageElement Identity.Unlimted language composition.
- 163. FlexibleNotationsTextuallike ASCIItreated thesame}Graphicalcan be mixedbox & lineSemi-Graphicalmathematical
- 164. AutomaticIDE Extensiontool supportis inherentfor languages build withprojectional toolslanguage definitionimpliesIDE definition
- 165. MultipleNotations… for thesame conceptse.g. in different contextsor for different tasks
- 166. PartialProjections… different views…for different roles/people… only a particular variant
- 167. Storage!= Schema… storearbitraty meta datachange logconflicting informationvariability annotations… independent of language schema!… „aspects“, overlay
- 168. LiveProgramsthink: spreadsheeta changeto one part of programcan lead to (dependent) changesin other parts
- 169. Tree Editing… isdifferent from editing text… try to make it feel like text… takes some gettingused tobut: for more flexible notations a more general editing paradigm is needed
- 170. InfrastructureIntegration… storage isnot text… diff/merge must be in tool… existing text tools don‘t work
- 171. ProprietaryTools… no standards…no interop
- 173.
- 174.
- 175.
- 176.
- 177.
- 178.
- 179.
- 180. Xtext: Gen. MetaModel
- 181.
- 182.
- 183. Xtext: Generated EditorCodeCompletion
- 184. Xtext: Generated EditorSyntaxColoringCustom KeywordColoring
- 185.
- 186.
- 187. Xtext: Generated EditorCodeFolding
- 188. Xtext: Generated EditorGotoDefinition Find ReferencesCross-File ReferencesModel as EMF
- 189.
- 191.
- 192.
- 193. Develop a languageto express it!
- 194. Language resembles architecturalconcepts…
- 195. Express the applicationswith the language.
- 199. Another Story…Architecture AsLanguage
- 201. DEMO IBuilding DSLswith Eclipse Xtext
- 203.
- 204.
- 205.
- 206. released inQ3 2009currently1.1 RC1
- 207.
- 208.
- 209. Build new standaloneDSLsBuild DSLs that reuse partsof other languages
- 210. Build new standaloneDSLsBuild DSLs that reuse partsof other languagesJava++(MPS comes with BaseLanguage)extend base language
- 211. Build new standaloneDSLsBuild DSLs that reuse partsof other languagesJava++(MPS comes with BaseLanguage)extend base languagebuild DSLs that reuse partsof BaseLanguage
- 212. Language Extension ExampleJava+ Extension
- 213. Language Extension ExampleOldJavaJava+ ExtensionReadWriteLock l = …l.readLock().lock();try { //code} finally { l.readLock().unlock();}
- 214. Language Extension ExampleOldNewJavaJava+ ExtensionReadWriteLock l = …l.readLock().lock();try { //code} finally { l.readLock().unlock();}ReadWriteLock l = …lock (l) { //code}
- 215. Structure Editor Typesystem Generator
- 216. Structure Editor Typesystem Generator
- 217. Structure Editor Typesystem Generator
- 218. Structure Editor Typesystem Generator
- 219. Structure Editor Typesystem Generator
- 220. Structure Editor Typesystem Generator
- 221. Structure Editor Typesystem Generator
- 222. Structure Editor Typesystem Generator
- 223. Structure Editor Typesystem Generator
- 224. Language Extension ExampleResultbehaves like a nativebase language construct
- 225. Language Extension ExampleResultbehaves like a nativebase language construct
- 226. Language Extension ExampleTranslatedto regular Java codebased on the generatorpackage jaxdemo.sandbox.sandbox;import java.util.concurrent.locks.Lock;public class DemoClass { private Lock lock; public DemoClass() { try { this.getLock().lock(); SharedResouce.instance().doSomething(); } finally { this.getLock().unlock(); } } private Lock getLock() { return this.lock; }}
- 228.
- 229.
- 230.
- 232. DEMO IBuilding DSLswith JetBrains MPS
- 234.
- 235.
- 237. Version 1.0 releasedinDec 15, 2008currently at 1.4
- 238.
- 239.
- 240.
- 241.
- 242. Statemachine ExampleTextual DSLProjection
- 243.
- 244.
- 245. Statemachine ExampleTwo projectionsside/side
- 246. Statemachine ExampleTwo projectionsside/side
- 248. Pension Workbench ExampleTextEditing Domain
- 249. Pension Workbench ExampleInsuranceMathematics Domain
- 250. Pension Workbench ExamplePensionContract Rules Domain
- 251. Pension Workbench ExampleAllin one Document
- 252. Pension Workbench ExampleSymbolicallyintegrated
- 254.
- 255. A Journey….coordinatesweb email[email protected]://www.xing.com/profile/Markus_Voelterhttp://www.linkedin.com/pub/0/377/a31