Domain Specific Languages (DSLs) - In General and How PowerShell Relates

Domain Specific Languages (DSLs) - In General and How PowerShell Relates

  • Comments 4

While attending JAOO, I had the great pleasure to meet and talk with Martin Fowler and Neil Ford on the topic of Domain Specific Languages (DSLs).  Channel 9 videotaped that discussion and you can watch it HERE.

I'm quite passionate about DSLs - both FOR them and AGAINST them.  The details matter!

I have this concept called, "Beer Cardinality" and it applies to DSLs.  Here is the way it works:

Have no beers  => Yawn!
Have 1 beers    => What's the point?
Have 2-6 beers => Happy Happy!
Have 24 beers  => Vomiting, hangovers, regret regret regret

DSLs are awesome BUT if you have too many, it can lead to a nightmare.  Let me draw a distinction and be more precise - there are SYNTAXes and there are VOCABULARIES.  It is fine to have a zillion Domain Specific Vocabularies (DSVs) but you only want small set of Domain Specific Syntaxes. 

There is also a very interesting discussion around Internal vs External DSLs.  Internal DSLs are essentially DSVs for particular languages Javascript, C#, PowerShell etc.  External DSL are distinct, self-contained elements orthogonal to the engine and language used to implement the engine (which processes the DSL artifact).  The problem is that you want BOTH.  You want the syntax of an Internal DSL so you don't have to learn a set of skills which put your resume into the bit bucket.  You also want an external DSL so that you can create artifacts with a well define scope of effect to facilitate transferability of the artifact.  Consider these 2 cases: 

1) I give you a 20,000 line file written as an external DSL and that DSL can do exactly one thing - it can generate Strings. 
2) I give you a 20,000 line file that is Java, C#, JavaScript,etc and I tell you all that it does is to generate strings. 

Now I say, you have to run that on your production server.  Consider what level of QA you have to do in the 2 cases.  In case 1 - you KNOW with metaphysical certitude that the DSL can ONLY generate strings.   In case 2 - it can do anything but is optimized for generating strings.

See my point?

So what you want is both internal and external DSL.  Hmmmmmm, that would explain why we have the DATA segment as part of PowerShell V2.  This gives you the best of both internal and external DSLs.  Notice that in our DATA segments, you can specify -SUPPORTEDCOMMANDS - this gives you the ability to specify a DSV.   Yummmmmm! 

People have no idea of the power and flexibility that they are going to get with PowerShell V2.  It is going to be awesome!

 BTW - I went to Martin and Neil's talks and they are super smart guys and I highly recommend going to any talk they give.  Great stuff.  Truly enjoyable.  I didn't agree with it all (as you'll see from the interview) but it was all worth listening to.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post
  • PingBack from http://www.easycoded.com/domain-specific-languages-dsls-in-general-and-how-powershell-relates/

  • Would you mind giving me more clues about powershell blend with DSL?

    I can just find this one:

    http://blogs.msdn.com/powershell/archive/2007/06/18/using-a-dsl-to-generate-xml-in-powershell.aspx

    Will DSL become An important factor of powershell?

    Thanks

  • Bruce Payette shows a DSL in his book PowerShell in Action.

    A post with an example showing the Data segment in action this way would be great.

    First time I've seen domain specific vocabulary.

    Looking forward to the PDC announcements on Oslo and textual DSLs. Maybe PowerShell will play in that space?

  • Hmmm. Have to agree with the video on a lot of points... But first, background:

    My favourite language of all time, is a small thing called REBOL. Lovely wee thing with some nifty syntax and it tries... but not too hard to look a "little" human readable txt...

    One of the key concepts behind it that it can be used to write "Dialects", to target certain problems... So these are pretty much DSVs (I think I prefer the term "Dialect" over DSV... It also stops a computer geek like myself thinking of Seaquest... )

    But the Dialects that result can bear little or no resemblance to the original REBOL that they were coded in - or they can be word for word.

    I have trouble seeing how powershell is going to come up with new dialects, or program syntax, in order to get a new expressive language.  Maybe one doesn't need a totally new language/syntax every time, maybe one does? Maybe the noun-verb syntax and piping is all one every needs?

    I look forward to seeing more examples posted.

    And yes. Totally agree with the views on insignificant language syndrome!  REBOL? REBOL?? Who has ever heard of that! More importantly, why would some one give me a job to program in that! Mind you the TIOBE index is not too hot for a certain language these days - is it? :-)

    Sigh...

    P.S One of the features in REBOL is "parse" with is a syntax that allows one to write a BNF style character matching rules. Yes, pretty much exactly like regular expressions - except for the fact that one rule can include other rules, and even recursively include itself as a rule and so forth.

    This is a pretty nifty feature, maybe I should write a Parse DSV for powershell.....

Page 1 of 1 (4 items)