towards multi lingual programming environments
play

Towards Multi-lingual Programming Environments Tijs van der Storm, - PowerPoint PPT Presentation

S oftware Analysis And Transformation Towards Multi-lingual Programming Environments Tijs van der Storm, Jurgen Vinju [Science of Computer Programming, 2013] (a grand challenge for SLE) TOPLAS 1985 Most programming environments are much


  1. S oftware Analysis And Transformation Towards Multi-lingual Programming Environments Tijs van der Storm, Jurgen Vinju [Science of Computer Programming, 2013] (a grand challenge for SLE)

  2. TOPLAS 1985 “Most programming environments are much too complex.“ “… bringing the total number of languages that must be mastered to at least four.” “One way of simplifying … is to reduce the number of mode-dependent languages…” “A programmer interacting with a typical computer systems has to be something of a polyglot” SWAT - S oftWare Analysis And Transformation

  3. 2017; a web app in Eclipse • Java code • hibernate.properties • pom.xml • @Java annotations • .classpath • HTML • .project • PuppetFile (bash++++) • META-INF/MANIFEST.MF • Jenkinsfile (Groovy) • JSP templates • 13 languages , excluding the editor commands, the • SQL schema definitions refactoring UI, etc. etc. SWAT - S oftWare Analysis And Transformation

  4. Project Complexity each of these artefacts have semantics which influences the • Programs in quality of the software product Programming languages • Client code and configuration files for the artefacts depend on each using frameworks and other in order to arrive at the libraries expected result • Build scripts and meta- data • the artefacts must co-evolve Deployment scripts and meta-data • Meta-features; editing and refactoring, analysis the artefacts’ supporting tools evolve (independently) SWAT - S oftWare Analysis And Transformation

  5. What to expect? • But, that’s all hand-waving. • Example: 80% of all Java Maybe it’s not so bad! Let’s projects use the Reflection just: API in a ‘harmful’ manner [Landman2017] • ignore the problem • 99% of all Java programs • or, quickly solve it depend on such Reflection via libraries. • Well, we really don’t know • Reflection currently breaks all what real software looks like… available IDE features in Java (some of us might…) IDEs SWAT - S oftWare Analysis And Transformation

  6. 2017; IDE features • syntax highlighting, outlines • browsing use/def links • browsing call links • refactoring (!) • type checking (!) • debugger (!) SWAT - S oftWare Analysis And Transformation

  7. 2013 SCP “In this paper we propose to view the de facto multiplicity of languages that a programmer is subjected to as a single, federated language.” “What is the syntax of this language? What is its semantics?” “How do we model name resolution, declarations, uses, control flow, data flow, and types for this language?” “Given answers to these questions, we will have a principled method of modeling cross language semantic dependency.” SWAT - S oftWare Analysis And Transformation

  8. Challenges • Understand (i.e. “model”) the • Supporting, beyond syntax full dependence relation • Static semantics integration between collaborating software artefacts written in • Dynamic semantics different existing software languages “in a broad sense” integration • Derive common tool support • For legacy systems (of for each “federated language” systems) which is the de-facto • Under continuous evolution composition in each project SWAT - S oftWare Analysis And Transformation

  9. Key enabler? SLE • Uniform representations of • “Generating Interactive intermediate semantic Programming models, given by a shared Environments” [Lang 1986] meta-modeling language • We should know how to do • A generic identification this then. mechanism of language • Or otherwise, we have artefacts at different levels of granularity sticked our necks out far enough to have to find • All kinds of relations/Graphs out. SWAT - S oftWare Analysis And Transformation

  10. Some Serendipity… • • Some frameworks already “solve” part of the data providers are notoriously problem dynamic and highly variable • • .NET CLR LINQ provides a unified static and dynamic semantics for all of them • common language run-time • if you model LINQ, you may have enough details for any IDE support • common calling convention • Excellent design sometimes solves the • cross-language dependencies are problem; if that design becomes the de- modelled into the underlying semantics of factor standard, we can charge ahead. (almost) al .NET languages • Ruby-on-rails? • LINQ SWAT - S oftWare Analysis And Transformation

  11. But.. harmful abstractions • What about Java & Scala? That should be easy too right? • The inter-language calling convention is obscure (at best) • In Scala people write powerful libraries (embedded DSLs) • On the JVM bytecode level then? • too much highly dynamic code (generated to work around Java’s/JVM static type system and give Scala more modularity) [Tip 2014] • No free lunch • model static semantics for every version of the Scala compiler • and learn the semantics of the Scala libraries in use • and every version of Java and its relation to the JVM SWAT - S oftWare Analysis And Transformation

  12. Harmful abstractions everywhere • Hibernate! That’s used everywhere and it maps OR to OO and back. Let’s start there. • mmmm…. right.. • “Hurdles in Multi-Language Refactoring of Hibernate Applications” [Lämmel et al. 2011] “Different programming languages can be involved in the implementation of a single 6 pages software application. In these software applications, source code of one programming language interacts with code of a different language. By refactoring an artifact of one 14 citations programming language, the interaction of this artifact with an artifact written in another programming language may break. We present a study on refactoring an software application that contains artifacts of different languages.” SWAT - S oftWare Analysis And Transformation

  13. The universal “solution” • Brilliant plan: • map all languages to a universal AST • build all tools for this AST • brought down quadratic connections to linear • problem solved! • Except, that it hides complexity elsewhere and increases complexity • semantics of AST nodes matters greatly (“import”, “&&”) • cross-language dynamic semantics much, much harder than (partial) static semantics • mapping back to the original abstraction level may be impossible (no apparent BX) • who will write all the “Hibernate to UAST compilers?” • Well, then we make the mapping a lot shallower, syntactic even. • ok. but then it’s just broken. go away. SWAT - S oftWare Analysis And Transformation

  14. 
 The ‘what-if’ solutions • Linguistic middleware (e.g. ToolBus) • Language-as-a-library (e.g. SugarJ, Silver, …) • Projectional editing (e.g. MPS) • Model Driven Engineering (e.g. EMF, Gemoc) . “… [these] assume a future world in which all software will be written in a more integrated fashion, or a world in which all existing software will be transformed into the new integrated perspective.” “ In [this] proposal the multiplicity of artifacts remains as it is. We take the reverse engineering stance towards the languages, and the forward engineering stance towards their IDE: to make all their syntactic and semantic inter-relations manifest. “ 
 SWAT - S oftWare Analysis And Transformation

  15. Towards Real Solutions • What about the reverse Engineering field? LB’s like ASF+SDF, TXL and • DMS, Eli have always been similar goals! similar solutions? applied to reverse engineering • MOOSE, KDM, M3, MoDisCO, Rigi, … as well as forward engineering • They give a real head start. • Their goals are design recovery and are often much fuzzier as a result • A refinement is necessary • Still, there is a lot of tools and ideas and experience out there to benefit from • generic data-dependence frameworks The two application fields have • system dependence graphs to come together to make multi-language IDEs come true • agile parsing • We should to study first (a lot) before we start designing SWAT - S oftWare Analysis And Transformation

  16. Solution Elements • Unique Universal Identification of Source Code Artefacts: loc superCl = java+interf://java/util/List; • universal notion of identity enables tracking through language barriers • Normalized graphs: rel[loc,loc] invocations = …; • many-to-many for modeling natural inaccuracy of static semantics • normalized for unanticipated re-combination • M3: Language adapters with detailed static models [Izmaylova 2012] • Java, C++, Javascript, PHP • Datalog-style inference rules (DOOP, Bravenboer 2011) SWAT - S oftWare Analysis And Transformation

  17. CROSSMINER H2020 EU project DiRuscio, Vinju, Kolovos, Degueule, etc. • Continuation of “OSSMETER” (multi-information source quality analysis of open-source projects) • IDE of the future: providing right advice at the right time • Wisdom of the crowds (information from open-source code, issue trackers, stackoverflow, …) • Multi-language by necessity • Funding a part of the multi-language IDE vision now • Modeling PL (Java, C++, Javascript) • Modeling [IDE] plugin and deployment architectures (Eclipse P2) • Modeling cloud deployment infra-structures (Puppet) SWAT - S oftWare Analysis And Transformation

  18. There is quite a lot more to talk about… SWAT - S oftWare Analysis And Transformation

  19. Truly Multi-lingual IDEs https://youtu.be/50A9wjJ40Dk SWAT - S oftWare Analysis And Transformation

Recommend


More recommend