JAOO - 'The Role of DSLs in Software Factories'
In this session Steve Cook from Microsoft spoke about DSL's and software factories.
Steve showed how visual studio could be used along with the DSL tools to graphically create new languages and then graphically 'write code' in those languages. What the demo did highlight are the issues around changing a DSL, what happens to code created in the previous version of the language? In a couple of cases Steve had to delete all the code he'd created, this was a shame because I think a lot of people came away remembering that rather than what might be quite a powerful technique. In fact it wasn't until a remark someone made later that evening that I saw past these issues.
This reminds me of the problems around managing message schema change, in the real world you don't get to delete the previous versions of a message, you have to find a migration path that allows backwards compatibility. So what happens once a DSL has been used to create a significant amount of DSL 'code' and we need to make changes to the language? Do we assume we designed the language correctly the first time and that we'll never need to change it? Business changes, the market changes, I think our DSL's are going to need to change as well.
Back to the session, the demo was all within visual studio and was largely graphical, I'm always wary of graphical tools, you often find you need expensive specialist skills or that the last 20% of the problem requires "customization". Whenever I've gone down the path it's always ended up with the generated code being dumped and us rewriting things test first, still there's always a first time but we underestimate the cost of customization at our peril.
To be honest I was a bit disappointed with the session because we didn't really get into the details, I also found myself wondering if the tool will cope with real world complexity better than some of the previous versions of visual studio features. Anyone who has tried to do complex sql queries and then generate data adapters will know where I'm coming from. That said it made me want to find out more and I'll certainly add these tools to my list of things to have a look at.
Steve showed how visual studio could be used along with the DSL tools to graphically create new languages and then graphically 'write code' in those languages. What the demo did highlight are the issues around changing a DSL, what happens to code created in the previous version of the language? In a couple of cases Steve had to delete all the code he'd created, this was a shame because I think a lot of people came away remembering that rather than what might be quite a powerful technique. In fact it wasn't until a remark someone made later that evening that I saw past these issues.
This reminds me of the problems around managing message schema change, in the real world you don't get to delete the previous versions of a message, you have to find a migration path that allows backwards compatibility. So what happens once a DSL has been used to create a significant amount of DSL 'code' and we need to make changes to the language? Do we assume we designed the language correctly the first time and that we'll never need to change it? Business changes, the market changes, I think our DSL's are going to need to change as well.
Back to the session, the demo was all within visual studio and was largely graphical, I'm always wary of graphical tools, you often find you need expensive specialist skills or that the last 20% of the problem requires "customization". Whenever I've gone down the path it's always ended up with the generated code being dumped and us rewriting things test first, still there's always a first time but we underestimate the cost of customization at our peril.
To be honest I was a bit disappointed with the session because we didn't really get into the details, I also found myself wondering if the tool will cope with real world complexity better than some of the previous versions of visual studio features. Anyone who has tried to do complex sql queries and then generate data adapters will know where I'm coming from. That said it made me want to find out more and I'll certainly add these tools to my list of things to have a look at.
0 Comments:
Post a Comment
<< Home