home > plop > 2006 > Papers > Notes > 43-notes.php

PLoP 2006 Shepherded Papers

Notes on Paper 43: REJECTED

This is for Bruce Trasks paper on Language - Editor - Generator.

This is a light "I don't recommend for workshopping right now" recommendation. (I could be persuaded otherwise.)

The author worked well with me and was clearly interested in his topic. We had good discussions, but in total, we only got one revision done.

I feel it may be too early for this paper to benefit well from a writer's workshop. I consider myself an expert on this topic and would disagree on a fair amount of assumptions and decisions, which suggests to me that further discussion and clarification what the actual patterns are is warranted.

But, on this one I'm glad, that this is only a recommendation and you have to make the final call whether it meets your upper and lower bar for a workshop :-)

Bruce, thanks for the work and the good discussions!

Dirk


At 31.07.2006, Dirk Riehle wrote:

Hi Bruce,

PLoP recommendation is upon us---appended is the last email I got. Is this what I should base my recommendation on?

Thanks,
Dirk

At 11.07.2006, bruce.trask@mdesystems.com wrote:

Understood. Thanks Dirk!


-------- Original Message --------
Subject: RE: Your PLoP paper...
From: Dirk Riehle <dirk@riehle.org>
Date: Tue, July 11, 2006 3:19 am
To: bruce.trask@mdesystems.com
Cc: phruby@microsoft.com,trask@mdesystems.com
>Interesting. I was hoping to convey this operational inevitability
>in that the a good solution to programming using general purpose
>languages against complex platforms, is the creation of domain
>specific languages and its attendant machinery. In fact, given the
>sheer comlexity of systems, today it really seems like the only
>solution, hence the inevitability. Is this not coming across?
For me it was still too meta. Not sure there are specific points I
could refer to. When you write above "sheer complexity leads to only
this solution"---that is descriptive and it actually requires you
know the pattern already.
> > You break writing style when you go from your descriptive prose
> to your first-person account of consulting experiences;
> > that first-person account reads quite sales-pitchy too me.
>Yes. I did change person there. Ralph Johnson loved the story and
>told me to put it in the paper. Do you think it belongs?
Fair enough. Caught me by surprise, maybe if you make this visually
stronger, people will see and recognize the break.
> > Personally, I think being precise when writing is important, more
> so if you consider yourself a meta-modeling guy.
> > Example: In the background section, you write "the purpose of the
> pattern is to capture this approach".
> > A pattern is not an approach. (If so, how would a type hierarchy
> look like where pattern is a subtype of approach?)
> > Another example is the quote from the Software Factories book
> where you say "the language... models the abstractions..."
> > People actively model stuff, languages are used to do modeling.
>
>Is the word "solution" better than "approach"? A pattern is a
>solution. Perhaps that is a better word.
There are many definitions of the word pattern :-) Despite my talk
about being less descriptive, I actually like "abstraction from
recurring form" better than (abstraction from problem) solution. I
used "approach != pattern" as an example to suggest you read your
paper with that precision regarding wording. (I think it is
important, but of course you may disagree.)
>Regarding the quote. I am taking the the definition of the language
>to be the "domain model" and from that folks model and those models
>are used as metadata
>or pass to generator to automate software development down the food
>chain. This is described on p. 217 in Software Factories. Do you
>disagree with this approach or did I just do a bad job of writing it?
Uh, I got that confused. I thought you had meant language to be a
language and domain model to a model that is not a meta-model. Yes,
please reread and rephrase this with this possible confusion in mind.
Actually, this should happen very early, and terminology should
remain consistent throughout the paper.
>t wasn't my intention to underestimate or discount existing
>work. Which parts came across that way?
Where you talk about existing technologies like frameworks, it felt
that way too me. It naturally happens: You want to motivate a new
pattern, so you need to create space by showing the weaknesses of
existing approaches. Better would be to show strengths and weaknesses
of existing approaches, because that brings out forces, showing how
the use of a framework e.g. is a pattern, bringing the whole space
closer to a pattern language.
Hope this helps,
Dirk