During the last edition of the Language Workbench Challenge, and Code Generation we noticed that quite a significant part of the delegates were from the The Netherlands. We also concluded that despite the fact that the XText folks were not there this year, there is also quite a bit of language construction and code generation going on in Germany. Where last year (or was it two years ago), I discussed with Steven Kelly that a lot of DSL and code generation related things come from Europe, not so much from e.g. the United States, it seems that in Europe things start to narrow down to The Netherlands and Germany (and Jyväskylä) – or is this only because of the way in and locations where Code Generation and the Language Workbench Challenge are advertised? However, a fact is that quite a few Dutch people have build their Ph.D. theses around environments like Spoofax (Delft University), that Rascal is used extensively for training purposes at the University of Amsterdam, companies like Océ, FEI Company and ASML are increasing their MDD activities and Xtext and MPS are extensively being used in Germany. Actually, we should all attend another Ph.D. defense on June 18th, when Markus Völter is defending his thesis at Delft University. Hmmm, that’s Germany and The Netherlands again…
Today, we made a small update to the reference implementation of the LWC 2014 assignment. Now, the reference implementation includes a conditionalFormElementWidget, next to simpleFormElementWidget, which allows the use of individual conditional questions, without having to wrap them in a conditionalGroupWidget.
It’s a small change, that will not affect the models created by LWC participants, but it may affect their code generators if they want to use it. Did we cause problems for them now? Hopefully not – this is the type of change to be expected in a real life situation as well.
Updates are available in the LWC2014 Git repository: https://github.com/dslmeinte/LWC2014
That’s a question I never really asked myself, but I do get it from other people every once in a while, when I tell them about Code Generation, the Language Workbench Challenge or just model driven software development in general.
The answer could be summarized as ‘for the same reason a blacksmith needs a hammer and an anvil and a shoe maker needs a boot tree and a needle’. Every tradesman needs the right tools for the job.
Just imagine this: you are working on a piece of software and you find yourself repeatedly going to your customer to ask how they want your application to perform a certain task. Then, you find out that most of the implementations resulting for this are quite similar in nature and you decide to create a small DSL to address that fact and speed up your talks and your development.
Pah! Instead of repeatedly writing the same code, you now write small statements (either graphical or textual) that describe the problems your customer wants you to solve and from which you can generate working software. Nice!
Now, let’s take a step ahead. Suppose you are doing the same thing still, about a year later. Because of your good work, you now have more customers and each of them requests more features than the initial one, because you are doing a good job. In order to cover for that, you have set up a team of developers, because despite the use of DSLs and code generators, you can’t do it all by yourself.
And suddenly, you find yourself in a situation where the small models, because that’s what they are, that you expressed in your DSL start referring to each other, and being (re)used by multiple people on your team. Now which version of which model do you need for product A for customer B, and which one do you need for product C of customer D? And how do you solve the fact that people are making changes to the same model for different products of the same customer?
There are different solutions to that problem, but I reckon most of them involve (re)dividing up the models, and performing version control on them. Maybe even real configuration management, allowing you to mix and match different versions of models. If only you had the tools to support you in that – models are often not stored in text format, like traditional program code, so tools like diff and merge often don’t work, leading to all kinds of issues and additional manual labour.
In a similar fashion, you may run into problems not because your team grows, but because models go bigger – another reason to split them up and maybe start doing version control on the parts. Also, you may find that your models become better if certain parts are expressed in another, dedicated DSL (just think about a DSL for specifying the pages of an app, and another one to define application flow). How do you mix these DSLs in such way that you can easily define the models required to solve your customers problem and generate the code?
This is a very short and possibly rather abstract example, but it is exactly what the case we put up for the Language Workbench Challenge is about. We work with (sets of) domain specific languages, we work in teams, and we work on models that are getting bigger. That will only help us if we can do it efficiently, and if we use tools that help us with issues like the ones expressed above – which are distracting us from our real goal: solving the customer’s problem. These tools are the language workbenches we discuss and compare in the LWC workshop, for the fourth year in a row. So, if you are interested in this topic, because you work with domain specific languages, or are working on a workbench yourself – join us in Cambridge on April 8th, 2014. Registration details can be found here: and information about the workshop can be found here.
And while your at it – it’s worth considering combining a visit to this workshop with a visit to Code Generation, or vice versa.
See you all in Cambridge!
Today, we send out the confirmations of the accepted proposals for LWC 2014. We are very pleased to announce that the following Language Workbenches will be present at the workshop:
Let’s start of with a Happy New Year to the MDSD and LWB community, before bringing this week’s good news.
Over the weekend, we decided to extend the submission deadline for LWC 2014 papers by one week. The reason is plain and simple: the deadline was tight to begin with, and we learned that, despite explicit announcements, some teams missed the fact that a paper submission was added to the process this year.
The deadline for submitting papers is now January 10th, midnight. The deadline for response to authors will remain.
As promised, around November 29th we would publish the reference implementation of the questionnaire platform, as well as some guidelines for the team support and scalability issues. These can be found on Git, under https://github.com/dslmeinte/LWC20u14.
The file README.md that can be found there explains the design of the reference implementation, while the file scalability and teamwork.md gives suggestions and requirements (mainly for model size scalability) on how to deal with the focus assignment.
If you have any questions regarding this, please post them on the Google Group for the Language Workbench Challenge.
Meinte and Angelo will maintain the reference implementation and the focus assignment document – major changes will be largely avoided. If that is not possible, it will be announced here. Cosmetics and minors will appear on Git without further announcement.
Good luck with the assignment – and we hope to see you in Cambridge in a few months time!
About a week ago, we released the CfP for the Language Workbench 2014. As some people have pointed out, the rules are a bit more strict than in past years, because we feel we need to focus more on the actual subject of the LWC: Language Workbenches (LWB). There are many ways to do model driven development and code generation, of which LWB are only one. All of these are candidate to be discussed at the CodeGeneration conference, with which we have co-located the LWC.
However, we did find a small flaw in the CfP that may lead to confusion. The criteria state that
“participating tools should be language workbenches, that is, tools that are designed
specifically for efficiently defining, integrating and using domain specific languages in an
Integrated Development Environment (IDE). Embedded, fixed-language or library-based
solutions do not meet this criterion.”
I’d like to point out here (and have updated the CfP PDF accordingly) that the word EMBEDDED here refers to EMBEDDED DSLs, i.e. DSLs that are used to extend a (3GL) programming language, using macro’s, pragma or whatever facilities that programming language provides. It does not refer to embedding of a language workbench into an existing IDE that may also be used for other purposes than DSL creation and use, such as Eclipse or Visual Studio.
Should there be any other doubts or questions about the CfP, don’t hesitate to contact us via email@example.com!
Regards on behalf of the program committee,