Mix: Getting my head around Oslo, M and MGrammar
I've been trying to get my head around "M" and "MGrammar" and "Oslo." I put the names in quotes as I'm not sure what's a codename and what's not. ;)
Oslo Developer Center on MSDN - The hub of all things "Oslo"
I had an opportunity yesterday to do a SharedView with Doug Purdy on his Mix talk. The talk is Developing RESTful Services and Clients with "M" and it's Friday at 9. He'll be doing it with Chris Sells as Code Monkey. Doug and Chris are an animated pair and their talks are a hoot.
When I've seen Oslo talks before, it's seemed like a lot of hand-waving and talk of things transforming into SQL and magic and elves. I told Doug it was too high level and that'd I appreciate something really concrete that I could really start to grok. So he focused on "M" - their new modeling language. I've done some simple DSL (Domain Specific Languages) so I figured this would be a good place to start.
Also, I took a bunch of screenshots (secret - don't tell!) while I was in this LiveMeeting/SharedView of Doug's demos. This part is making sense to me.
Here's a screenshot of their editor. Don't sweat the tools too much, but it's basically Emacs with a .NET heart written in WPF using IronPython for plugins. They call it Intellipad. You can do this stuff from the command-line, though. It's lightweight and quiet.
NOTE: The Intellipad editor is using the same WPF Editor in Visual Studio 2010. Nice to see folks sharing components. How is it all plugging together? MEF. Bam!
Anyway, on the left there, is a sentence "Scott is 36 years old." Actually my wife says I'm 35, so my bad there. Anyway, that sentence is a DSL - a Domain Specific Language. It's a DSL only because we decided it was. Just now.
In the middle there is the MGrammar (in a .mg file). (Good video on MGrammar here)
This is kind of like Lex and YACC, but more general, and it quickly gets away from the dirty text parsing part of things and into the model much faster than they do.
The MGrammar in the middle describes our new DSL for expressing info about People. I can now say "Fred is 12 years old..." etc. Now I've got a simple DSL that I can consume and anyone can right. Still, a DSL isn't useful unless you can DO something with it.
On the right, in the third window pane is a tree of the output of this DSL with the MGrammar applied. Now I've got an object (or series of them) with properties that I can do something with.
Now, we could give the system more info about these People. Like, give them an Id that's an Int32, make sure the system knows Age is an Int32 also, etc. There's all sorts of constraints like this that are much richer than a DB. This is the "modeling" part. We express what something is as simply as possible.
OK, so fast forward and switch gears to something more concrete. You're probably familiar with cURL. It's a the command-line tool for messing with URLs from the command line. You can GET, POST, etc with this nice command-line tool.
They created an example they're calling MURL to show how one could create a Domain Specific Language for talking to URL endpoints. Stated differently, MURL is a REST client built with their tools in very little code.
In this shot, he's got the MURL DSL on the left, looking like HTTP initially. Just GET url, for now. Then he adds to the language and makes it so he can do things like "secure using" with names and passwords. Then he adds POST support with payloads, etc. He can make his little language look like whatever he wants.
In this screenshot, he's made ? mean GET and ! mean POST, etc.
Some DSLs we use all the time are:
- SQL - "select * from whatever"
- XPath - "//something/else[@cool = 'neat']
- RegEx - "%(&^%&^$#%#$@#$*@#((**$#$%"
And we often use these DSLs and their associated "engine" from our .NET code. That means, I could use MURL (or any other DSL and its engine I create) from my existing .NET code.
See the "runtime.Parse" statement in the screenshot below? I'd probably change the name and make it a one liner like "Murl.Do()" but you get the idea. Then the result is just XML I could go to town on.
Here he's using his MURL language from inside ASP.NET MVC to do some work. Don't get mired in the fact that he's just doing an HTTP GET to an endpoint. You might be all (and I was too) "ya, I can use Web Client for that." The idea would be you could create languages that can more easily expressed in a DSL than in C#.
When I worked in banking (not too long ago, actually), Patrick and I created a DSL for modeling domain object by extending XSD (an existing DSL). We could have created a much more terse and person-friendly DSL (as opposed to XML which is person-hostile) with tools like this. I can see this greatly facilitating Domain Driven Design.
Doug's talk is at Mix (and will be online later) on Friday and you can find it on the Mix Site. Remember it's not really about URLs, or REST, or MURL, it's about the creation of DSLs and the tools that support it.
It's early, but now I've got more context. I'm not on board yet, but it's slowing sinking in for me.
Other MGrammar Examples
- Simple MGrammar
- DSLs for Devs
- Creating a WatiN DSL using MGrammar
- Fowler’s DSL example with MGrammar (Draft!)
- C# code generation using MGrammar
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
@Dave markle: I was thinking the exact same things. I thing mumps should no longer be called "M". From now on, it shall be named... "F"!
I however found the MGrammar / DSL tools to be very interesting and I can see that this will be a very useful tool, especially for tool/framework companies/open source projects.
Thanks for linking to my WatiN DSL post :) , I did a follow up where I rewrote it with using MGraph -> XAML -> Model deserialization, and changed the syntax to be more natural.
Example:
--- Can filter by author ---
goto address "http://demo.codesaga.com/".
click the link with the text "MvcContrib".
select "torkel" from the list with the id #author-fitler.
page should contain the text "Filtering view by author torkel".
http://www.codinginstinct.com/2008/11/browser-automation-dsl-using-mgrammar.html
http://www.outoftheslipstream.com/node/125
and
http://blog.crossoverhealth.com/2009/01/12/the-problem-with-vista-its-the-platform-stupid/
nice post! I was actually thinking of doing a bdd-style rest-specs dsl for easily specifying acceptance tests for rest-services. Could build it upon that, though.
Over time MGrammar is planned to be part of M. "Oslo" is a codename for M, "Quadrant" and the Repository and whatever to come in the whole initiative.
I think this Repository thing confuses lots of people. Sometimes I feel the only reason for the Repository is to drive "Quadrant". Thats most likely the tool that could bring money. But "Quadrant" is still not publicly available and hence there is little use for the Repository these days. The debate about files vs. repositories is an old story for model storage.
What I love about M (besides its syntax), is, that it is released under OSP and will have a free implementation for .NET.
Whats great about MGrammar is not only the parsing stuff (there are other tools for that), but also the nice integration with language services in Visual Studio and intellipad.
cheers,
Lars
Are you giving away a part of Doug's twitter password in one of your screenshots!?
Just curious...
"Lars from Oslo"
Other talks and posts I've seen on Oslo etc. are so vague and generalised that they left me none the wiser as to what they actually do or what they're really for. The examples and other details you provided are 1000x more revealing than the other "explanations" I've seen so far.
Thank you for bypassing the blurb and getting down to the actual specifics of what these technologies actually are!
-Dan
It is unfortunate that Microsoft's "M" name clashes with MUMPS; however, hopefully it will turn out to be a codename.
I'm still confused as to where to use Oslo in a DDD project, and there's the one thing I really find problematic. In order to consume Oslo's outputs in C# we've to use plain text (I'm referring to the Parse method). I think this can cause a major drawback in the quality of projects. Think about it, for quite a while we're working real hard to get DSL to be recognised by the compiler and the IDE to get sanity checks as type affinity and productivity tools as auto-complete. LINQ is a great example to such an effort bringing the SQL DSL closer to the compiler and the IDE.
In this example, we've to input the DSL using a structured string unknown to the compiler and the tools. In essence, we're losing all the support mechanism provided by the IDE. For example, if our project would render the DSL on runtime and then try to parse it for further processing, any errors produced to the rendered DSL string would only be found at runtime when the Parse method would fail. This is not a great for enterprise project that usually require compile-time checks.
Don't get me wrong, I do see the value of Oslo for the design phase with the business representatives and the domain experts, but I lack to see how the outputs can flow in a DDD project all the way to the C# implementation.
@Fernanado: That example is showing "M" in C# "interop". Oslo is _exactly_ what you want for a DDD project, as the domain can be expressed in one language and type system (inclusive of behavior, constraints, etc.) with out the current set of transformations and validation "copying" that you need to do between the web, service and database.
I understand the power of Oslo in regards to its Model-Driven Architecture capabilities. It's a tool enabling architects to have a discussion with domain experts (business representatives) and capture the findings in a model. However, to further benefit from that model, you've to be able to merge it with other layers of your applications presumably implemented in C#.
So I can see what's the benefit of having an Oslo model easy for humans to read, describing e.g. a XAML that is then interpreted by the WPF compiler, but I fail to see what's the benefit of Oslo in producing that XAML. Why not use any other transformation tool producing XAML from arbitrary-structured text? What's, I think, missing in this example is how the model flows all the way to the C# code so it can be reused easily and the IDE can leverage it.
Saying that, I since read this article C# code generation using MGrammar that explain one way to achieve this.
Oslo is not just a tool for architects to capture models from business people. Oslo is a way of writing model-driven applications.
http://www.hanselman.com/blog/content/binary/WindowsLiveWriter/GettingmyheadaroundOsloMandMGrammer_C5C9/3_thumb.png shows some of this.
I was writing a web service with a database backend using "M". No C# in it at all. Using "M" you can define the domain model and the runtimes are driven from that, rather than code being generated or a developer writing a ton of C#.
Once my MIX talk is posted, this may be a little clearer.
Comments are closed.
http://en.wikipedia.org/wiki/MUMPS