Designing a language is hard, and M won't change that

re: Designing a language is hard, and M won't change that

Clemens Szyperski — Thu, 20 Nov 2008 16:52:32 GMT

Oh, I forgot to address your first question -- "so the DSLs creatable with M are really more in the category of data transformation languages and not for example really suitable for defining rule logic and the like?"

A key idea behind M is that specific semantics, such as rule logic or workflow etc., is not part of or defined in M. It is defined by the runtime you choose to interpret/execute your models. Any given runtime will "understand" only a subset of your models, of course. And any given model may be interpreted by multiple runtimes for multiple purposes. This decoupling is fundamental to the Oslo approach - there isn't the one semantics baked into a model.

Therefore, DSLs are truly just syntactic sugar over your domain models and, thus, no more than, as you put it, data transformers: the DSL definition maps any valid DSL instance to the desired model instance(s).

re: Designing a language is hard, and M won't change that

Clemens Szyperski — Fri, 14 Nov 2008 19:35:55 GMT

@Frans:

I think we agree - designing a DSL is not easy and a parser generator, as such, doesn't make it easier. The details of the meta language do make a big difference (and we hope to make MGrammar a really good one), but it doesn't as such address the issue you bring up.

At that level, integrating MGrammar into the "M" story serves one purpose: _if_ you know how to think about and design DSLs that are essentially data transformers, _then_ we aim to offer a smooth story for how to do that in the context of "Oslo". (So, MGrammar is not targeting the scenarios of existing parser generators that are all far more general than MGrammar, with mechanisms such as arbitrary code actions on the RHS of productions.)

Something better, like "define DSLs by example" could likely be build on top, once we understand how to do that in the first place. (Ok, I shouldn't say "we" here, just because I don't understand how that could be done. :))

re: Designing a language is hard, and M won't change that

FransBouma — Thu, 13 Nov 2008 17:29:41 GMT

@Clemens:

so the DSLs creatable with M are really more in the category of data transformation languages and not for example really suitable for defining rule logic and the like?

My main point is that the route towards a grammar which reflects what the language has to be about is really a long route, despite the extra tooling: the main hurdle isn't addressed: how to get to the point that one can formulate a non-terminal (or M's equivalent) and it fits the goal of the language.

Imagine someone who wants to write a DSL for a narrow domain. How would that person start? Probably with writing out some example texts which represent valid input for the DSL. But then the problem starts: how to create grammar which is able to parse these inputs properly so an AST which is usable to interpret the input as it was meant and also how to make sure inputs which are wrong aren't accepted? That's a big step. Once that step is taken, the rest is 'easy': whatever tool you're using, writing the grammar out in the tool of choice isn't that hard compared to that initial step, and IMHO that step isn't addressed at all in oslo, so what's there is really just what's already available (perhaps more fancier and with more bells/whistles) with other parser generators/toolkits. It's that first step that counts.

re: Designing a language is hard, and M won't change that

Chris Sells — Wed, 12 Nov 2008 17:46:34 GMT

Saber, what were you looking for in the Oslo SDK CTP that you didn't find? Feel free to drop me a line so I don't miss your response: csells@microsoft.com.

re: Designing a language is hard, and M won't change that

Clemens Szyperski — Tue, 11 Nov 2008 16:16:53 GMT

Thanks all for providing useful feedback. Please allow us to listen in. :)

MGrammar is used to transform expressions made in a custom language (a DSL) into MGraph/MSchema definitions. As such, M DSLs are _not_ general languages. You do not define semantic actions - all semantics is derived from the meaning of the data schema you are translating the DSL to. This has two consequences in practice: (i) such DSLs compose much more easily, because, in the end, they either target shared schema or they don't; (ii) such DSLs are typically easier to design, because they are less demanding than intricate programming languages, especially from an exceptions/error-handling point of view.

We are still working hard on tooling and error diagnostics for MGrammar to ease the experience of defining your own DSL as much as we can. However, I'd still expect far more folks to be using rather than designing DSLs. There is no question that it takes skill to model a domain. There is also no question that it takes (different) skill to design a DSL.

re: Designing a language is hard, and M won't change that

FransBouma — Tue, 11 Nov 2008 10:03:17 GMT

@come again (real names would be great for a discussion, don't you think? ;))

I think it's a matter of definition then, because I see grammar as one of the founding pillars of a language design. So if you want to design a language, the grammar is one big part of it. I still find defining grammar as being hard, despite the fact that people claim it not to be, that was the point of my article.

re: Designing a language is hard, and M won't change that

come again — Mon, 10 Nov 2008 21:02:22 GMT

@frans: You the whole sentence. I didn't quite understand your comment.

Anyway, your entire article is about how M doesn't make parsing much easier. That is missing the point, since grammars and parsing is the easiest part design and implement (when you write a compiler or interpreter). If you had rounded it off by, say "and since parsing is the easiest part of a compiler/interpreter, qed", it would have made more sense.

But I agree language design is the hard part. Your article just doesn't mention it.

(btw, I'm not come on)

re: Designing a language is hard, and M won't change that

FransBouma — Mon, 10 Nov 2008 20:24:30 GMT

@come on: I don't you understand what I meant: the parsing is done by their parser, so yes, that's the easy part, as you (the user) don't deal with that. It's the language design which is the problem.

re: Designing a language is hard, and M won't change that

Come On — Mon, 10 Nov 2008 19:07:09 GMT

You're really missing the point. Parsing is the easiest part.

re: Designing a language is hard, and M won't change that

Saber Karmous — Fri, 07 Nov 2008 07:24:24 GMT

I share the same feeling as you Frans, but on a whole other level. I'm not a parser specialist, I know what they do, know how "hard" it is to make them. But it's not my daily job to create parsers, nor do I have the illusion that I'm able to create a new and sexy language.

What disappointed me is that Microsoft is taking this DSL thing in the wrong way. Microsoft is good at making easy and productive tooling. And I liked they what they were doing with their first DSL toolkit. Nice and easy DSL's for the masses.

Then it became very quiet, and all of a sudden Oslo pops ups. And in my eyes it's as if they were working on something nice, and then they had to go all "academicy". From my understanding it's suppose to be more flexible, but I really don't see whether this is gonna make my job easier or more productive.

When I saw people cheer about Oslo, I thought let's give it a look. I downloaded the current CTP and I what I found wasn't the same stuff they used @ the PDC.

So for me, when creating a DSL it's back to using GME again: No nonsense DSL model development that I understand, and which has proven to me in practice to be very productive and manageable. No Microsoft Don Box style hype, no marketing... Just stuff that works.