From Programming to Modeling And Back Again
Download as PPTX, PDF27 likes2,969 views
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.
![Projectionaltree… to text-lookalike (editor)… to other trees … [*]… to text](https://image.slidesharecdn.com/fromprogrammingtomodelingandbackagain-091104013255-phpapp02/85/From-Programming-to-Modeling-And-Back-Again-159-320.jpg)
From Programming to Modeling And Back Again
- 1. Programming fromtoModeling…and back againMarkus VoelterIndependent/itemisvoelter@acm.org
- 2. A Journey…
- 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
- 12. Programming LanguagesFormatsFrameworksenough.are notErlangC# C++PythonJavaDjangoRubyGroovyWPFFortranjsonCJEEJMSHTMLCSSRailsyamlXMLlift
- 16. So?
- 17. Modeling… Higher Level… Domain SpecificConcepts & Notations… Code GenerationInterpretation
- 18. Modeling… Higher Level… Domain SpecificConcepts & Notations… Code GenerationInterpretationSolvestheProblem!
- 19. But:
- 22. Different WorldsMix Models and Programs
- 23. Different WorldsMix Models and ProgramsAST Navigation & Query
- 24. Different WorldsMix Models and ProgramsAST Navigation & QueryIntegration of 3GL code
- 25. Different WorldsMix Models and ProgramsAST Navigation & QueryIntegration of 3GL codeCode Constraints
- 26. pareCom
- 27. pareCom
- 31. Define customQueryorNavigateorTransformLimited!Flexible!AST APIsStatic AnalysisRegex
- 32. CustomValidationorError ChecksLimited!Flexible!IDE pluginsStatic AnalysisOpen Compilers
- 33. DifferentRepresentationsandProjectionsLimited!Flexible!Text is TextCode FoldingTree ViewsVisualizations
- 38. Gets theGets someJob Done!Jobs done.some people doubt that…everybody agrees…
- 40. History?
- 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
- 45. It is time for …
- 46. … a Different Perspective
- 47. Programmingthe waywe doModeling?Modelingthe waywe doProgramming?
- 49. We don‘t want tomodel,we want toprogram!
- 50. We don‘t want tomodel,we want toprogram!… at different levels of abstaction… from different viewpoints… integrated!
- 51. We don‘t want tomodel,we want toprogram!… with different degrees of domain-specificity… with suitable notations… with suitable expressiveness
- 52. We don‘t want tomodel,we want toprogram!And always:precise and tool processable
- 53. Where do we go from here?
- 62. Programming Language Syntaxis notFLEXIBLEenough.
- 63. Big Language?withmany first class concepts!
- 64. Small Language?with a few, orthogonaland poweful concepts
- 65. abcdefghijklModular Languagewith many optional,composable concepts
- 67. Modular LanguageLikeframeworksandlibraries, but withsyntaxand IDE support
- 68. Not a new idea…
- 71. Growing A Language(Guy L Steele)
- 78. LanguageWorkbench(Martin Fowler)powerful+editingtestingrefactoringdebugginggroupwarelanguage definitionimpliesIDE definition
- 84. Viewpoints
- 116. (Seemingly)Simple ExampleAddingmatricesto C in an embeddedenvironment.
- 117. Currently:
- 118. Currently:Matricesnot supportedin XML format and generator
- 119. Currently:Tool teamwould have todo the extension… a lot of work… busy… one central tool
- 120. Currently:No real compiler supportin the resulting C code… type checks… operator overloading… generics (matrix<int>)… matrix syntax?
- 122. Better Solution
- 123. Better Solutiongeneric matrix and vector types
- 124. Better Solutionreal matrix and vector literals
- 125. Better Solutionsyntaxhighlights for vectors and matrices
- 127. Better Solution operatoroverloadingstaticoptimization… symmetrical matrices… identity matrix… diagonal matrices
- 129. Better Solutionaseparate language moduleused only bythose whoreally need it
- 131. In addition: PLE Variabilityannotatingvariabilityexpressionsto arbitrary regions
- 132. In addition: PLE Variabilityannotatingvariabilityexpressionsto arbitrary regions statically checked
- 133. In addition: PLE Variabilityannotatingvariabilityexpressionsto arbitrary regions project variant
- 140. Modeling as Programmig… (Mostly) Textual Notations… Concrete Syntax Storage… (Fancy) ASCII Editors… Read-Only Visualizations
- 144. Xtext-like Toolsprovide editor supportCustom EditorsTeamworkGoto DefFind RefsRefactoring
- 145. Limited toUnicodehow to handlenon-character symbols
- 146. Graphics !=Texttwo worlds…separate editors… per syntax/viewpoint… models can still be ref integrated
- 148. What if!combine languagessame seq<Char> asdifferent tokens?
- 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 combining languagesAlways Parsable.(well, almost. There are some corner cases…)
- 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 Language Element Identity.Unlimted language composition.
- 163. FlexibleNotationsTextuallike ASCIItreated the same}Graphicalcan be mixedbox & lineSemi-Graphicalmathematical
- 164. AutomaticIDE Extensiontool support is inherentfor languages build withprojectional toolslanguage definitionimpliesIDE definition
- 165. MultipleNotations… for the same conceptse.g. in different contextsor for different tasks
- 166. PartialProjections… different views… for different roles/people… only a particular variant
- 167. Storage!= Schema… store arbitraty meta datachange logconflicting informationvariability annotations… independent of language schema!… „aspects“, overlay
- 168. LiveProgramsthink: spreadsheeta change to one part of programcan lead to (dependent) changesin other parts
- 169. Tree Editing… is different 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 is not text… diff/merge must be in tool… existing text tools don‘t work
- 171. ProprietaryTools… no standards… no interop
- 173. AvailableTooling
- 177. Eclipse XtextBuilding Textual Editors
- 178. Eclipse XtextBuilding Textual Editors
- 180. Xtext: Gen. Meta Model
- 181. Xtext: Constraints
- 183. Xtext: Generated EditorCode Completion
- 184. Xtext: Generated EditorSyntax ColoringCustom KeywordColoring
- 187. Xtext: Generated EditorCode Folding
- 188. Xtext: Generated EditorGoto Definition Find ReferencesCross-File ReferencesModel as EMF
- 193. Develop a language to express it!
- 194. Language resembles architectural concepts…
- 195. Express the applications with the language.
- 199. Another Story…Architecture As Language
- 201. DEMO IBuilding DSLs with Eclipse Xtext
- 203. AvailableTooling
- 206. released inQ3 2009currently 1.1 RC1
- 208. Build new standalone DSLs
- 209. Build new standalone DSLsBuild DSLs that reuse partsof other languages
- 210. Build new standalone DSLsBuild DSLs that reuse partsof other languagesJava++(MPS comes with BaseLanguage)extend base language
- 211. Build new standalone DSLsBuild 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 ExampleResult behaves like a nativebase language construct
- 225. Language Extension ExampleResult behaves like a nativebase language construct
- 226. Language Extension ExampleTranslated to 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; }}
- 232. DEMO IBuilding DSLs with JetBrains MPS
- 234. AvailableTooling
- 237. Version 1.0 released inDec 15, 2008currently at 1.4
- 238. CommercialProduct
- 242. Statemachine ExampleTextual DSL Projection
- 245. Statemachine ExampleTwo projections side/side
- 246. Statemachine ExampleTwo projections side/side
- 248. Pension Workbench ExampleText Editing Domain
- 249. Pension Workbench ExampleInsurance Mathematics Domain
- 250. Pension Workbench ExamplePension Contract Rules Domain
- 251. Pension Workbench ExampleAll in one Document
- 252. Pension Workbench ExampleSymbolically integrated
- 255. A Journey….coordinatesweb email skypexinglinkedinwww.voelter.devoelter@acm.orgschoggladhttp://www.xing.com/profile/Markus_Voelterhttp://www.linkedin.com/pub/0/377/a31