Maestro: A Managed Domain Specific Language For Concurrent Programming

Posted By: Charles | Dec 22nd, 2008 @ 11:46 AM | 94,145 Views | 12 Comments
Josh Phillips(PM), Niklas Gustafsson(Architect), and Artur Laksberg(Developer) of the Parallel Computing Platform Team spend some time with me to discuss a managed (.NET-based) DSL (Domain Specific Language) for concurrent programming, Maestro. Maestro incorporates well-entrenched language patterns (imperative, OO, C style syntax, etc) and language constructs (channels, agents, domains) in a compelling way to make concurrent composition more accessible and familiar to the legions of sequential code composers.

Here we dig into the architecture and design of the Maestro language and compiler as well as discuss the philosophy behind this incubation project (at this point in time there are no plans to release Maestro as a product - it's a research project, an incubation...). Why create another language to help solve the Concurrency Problem? What's the advantage over implementing a library (this is .NET after all -> CLR + BCL = most of the power of the platform)? There's obviously good reasons for implementig Maestro as a language, but you'll need to watch and listen to find out.

Enjoy.

Note: After this interview was conducted and posted to Channel 9, the Maestro team has renamed their technology to Axum. So, they are now the Axum team and the managed DSL for concurrent programming they're incubating is called Axum. Smiley
Rating:
4
0
#Dec 30th, 2008 @ 4:25 PM
Charles
Charles
Welcome Change
CCR is not as popular as it could be due to how it requires a shift in "concpetual programming". There are many teams inside of Microsoft that have implemented some concurrent system using CCR (generally in incubation stage or experimentation). Anybody who does anything with Microsoft Robotics is using the CCR (albeit implicitly). I think I understand your general question: "Why isn't the CCR more poplular than it appears to be?"

I will make sure to ask the creator of the CCR this question at our next interview. I know that George will probably disagree with the notion of a lack of CCR adoption, but he'll have more concrete evidence than I can come up with off the top of my head.

Thanks for the discussion!

C 
#Jan 6th @ 12:45 PM
staceyw
staceyw
Before C# there was darkness...
Very cool.  I remember a thread me and evildictator had on this very idea that was similar.  Grab patterns from Erlang and CCR and wrap it in a language/combiler pair that will enforce correct-by-construction design.  I also like that the patterns itself is a simpler version of STM.  Essencially the R/W agents are a localized mini-STM without needing to implement a full STM.  And that you can even replace it with STM under the covers as an implementation detail and the syntax does not change much and the model remains the same.   And think you still have the flex of using PTL libraries "inside" your agent.   It smells like this is the right approach and abstraction going forward IMHO.  Nice work, hope to use some ctp bits in future.

Also thinking...  Suppose the windows UI thread loop was *replaced with a single Agent.  Now we don't have to worry about IsInvokeRequired() or BeginInvoke() or even hanging the UI thread inside callback method.  We have a clear seperation and threads don't matter in terms of UI correctness.  This would also mean we can forget about what thread we got a callback on (i.e. timer event) as it will not matter.  The UI agent can then be free to have any type of parellelize it can correctly handle inside itself and all is hidden from programmer.  It would mean we would have to think about explicitly blocking/pausing other UI actions if you don't want people clicking same button twice before last action completes for example.  A light begins to appear...
#Jan 7th @ 1:39 PM
NiklasGustafson
NiklasGustafson
I think it's a good idea to explore how an agent-isolated model can be used to simplify expressing "ownership" of the UI. It certainly seems worth exploring in some depth.

Another interesting angle is to look at how Maestro contracts can be used to express correct ordering of UI events, to control enabling/disabling of UI elements and force some formalism on UI interactions. Don't know whether that's actually going to prove useful, but it seems interesting to explore.
Microsoft Communities