Open and Original Problems in Software Language Engineering

OOPSLE

Fourth International Workshop on Open and Original Problems in Software Language Engineering

15–16 March 2016, Osaka, Japan

Co-located with SANER’16 (formerly CSMR and WCRE)

Back to workshop programme

Language-Parametric Panel

Software language engineers have developed many methods and tools during the last decade, meant for both forward and reverse engineering: we create domain-specific languages, manipulate their definitions, cotransform related artefacts, analyse involved entities for a variety of causes, mine useful facts from codebases, boost performance of our algorithms, introduce new theories and challenge long-standing ones.

However, many questions remain pertaining language-parametricity of our techniques and interoperability of our tools. Please submit your position statement to this panel contributing on any of the following topics:

  • Software language agnostic engineering
  • Assessing applicability of software language engineering methods and tools
  • Framework interoperability and interchange formats
  • Experience reports on non-trivial combination of methods
  • Language-specific configurations of methods and tools
  • Anything else related to the view of a software language being just another input

Panelists

Felienne Hermans

Who needs DSLs if you can use a spreadsheet?


Hugo Brunelière

Model-based techniques have already been used since many years to elaborate on solutions for making tools and their underlying languages inter-operate. Thus, by means of metamodels and corresponding model transformations principally, concrete bridges have been built between various types of languages from well-known GPLs to more DSLs. However, despite many examples of their practical use (within the industry), such interoperability solutions often have significant limitations in terms of agility. They are generally quite static (e.g. embedding hard-coded mappings) and so do not react very well to continuous changes. For instance: What happens at tool-level when the bridged languages evolve over time, or when a new language support need to be added? What happens when the handled occurrences (or models) become bigger in size and/or more complex than they initially were?

In this context, I would advocate for going in the direction of lightweight interoperability approaches that would allow both the tools/languages and the bridging solutions to better adapt and scale up to changes in the environment. Model-based techniques provide interesting capabilities to support that but important progresses can still be made regarding the adaptability and scalability aspects (among others), notably related to (meta)modeling or model transformation to cite a few.