Microsoft doing Language Oriented Programming with Oslo? Are they serious about it, or just taunting me?

Ok, I was totally ready to dismiss Oslo out of hand as yet another “Visual Programming” silver bullet wannabe from Microsoft that helps teams quickly create unmaintainable code, but I saw this little line in Doug Purdy’s post on Oslo:

A language that helps people create and use textual domain-specific
languages and data models

Now I’m paying attention.  Attending PDC certainly isn’t within my budget, so you folks that are going, please blog it out.  I’d really love to hear if Oslo has some capabilities similar to JetBrains MPS product, but for .Net.

I’m about to do a total reboot of my StoryTeller project, but this time I’m ready to ditch the FitnesseDotNet engine* altogether and replace it with something from scratch.  I love the concept of Fit, but the implementation just flat out sucks in complex usage.  What I do love about Fit at its best is the ability to create External DSL’s for testing specifications of your system (largely using the DoFixture).  I want to use External DSL’s for testing because they are much more readable and intention revealing than writing the test out in normal code, even with tools like MSpec or RSpec.  The problem is that building an External DSL is relatively expensive compared to an internal DSL or just using a “push button” API for testing (I have heard other people say that it’s easy, but I’m dubious).  With Fit testing the problem is both in authoring the testing DSL because the DoFixture and the engine itself is limited in its expressiveness, and also because writing and editing the tests in Fitnesse Wiki format or HTML is time consuming and error prone.  What I’d like to do with StoryTeller is create a poor man’s language workbench specifically for the creation and editing of external DSL’s.  Specifically, I want a sort of intellisense or guided editing for the testing languages I would be creating with StoryTeller.  I’ll be interested to see if the Oslo tooling could help in that regard.

In the meantime, I’m going to continue on my StoryTeller reboot, and try to get some help from an F# guru for some language parsing help.

Thoughts anybody?

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Google
    If you do not wish to receive similar messages please inform us on it by mail[dog]

  • Hubert

    Excuse me. I stand in awe of my body. Help me! It has to find sites on the: Archive purchase cheap synthroid online.. I found only this – turbo tax. Most western european countries are not fluoridated and have experienced the prescribed drug of the year was synthroid, which is a hormone replacement drug. No prescriptions! Huge discounts! Huge discounts! Synthroid! Cheap generic synthroid. 😮 Thanks in advance. Hubert from Malaysia.

  • Don Box

    Jeremy, I think you’ll have a lot of fun with the bits in October.

    There’s definitely an overlap between what we do and what MPS does, but there are also enough differences that will make both interesting.

  • Mike Stockdale

    I’m interested in more details about what you “love” about the Fit concept and what “sucks” about the implementation. Is there more beyond the external test DSL (good) and the pain of wiki/HTML editting (bad)? I ask because I’m trying to get some ideas for a “reboot” of Fit.

  • Colin Jack

    “I want to use External DSL’s for testing because they are much more readable and intention revealing than writing the test out in normal code, even with tools like MSpec or RSpec. ”

    Definitely interesting stuff and look forward to seeing what you come up with. Thats about all I can say as other than a bit of fluent interface fun my only investigation in this field has been buying Ayende’s book.

  • Jeremy D. Miller

    From Twitter conversation on the side:

    jeremydmiller jeremydmiller @ayende and testers/customers use the grammar definitions like lego blocks to create the acceptance tests 10 minutes ago from web in reply to ayende

    jeremydmiller jeremydmiller @ayende I still like the basic Fit workflow. Get the testers and devs together, agree on the testing grammars, devs implement grammars,… 10 minutes ago from web in reply to ayende

    jeremydmiller jeremydmiller @ayende I mispoke. I want it to *read* like natural language, but I’m perfectly happy to have the language restricted to precanned grammars 11 minutes ago from web in reply to ayende

  • Jeremy D. Miller


    Thanks for the comment and I’ll certainly give OMeta# a look.

    And btw, Simonyi is *still* working on Intentional Software.

  • Jeremy D. Miller


    Give me a couple days and I’ll publish a sample test with the visualization I’m pawning from Ward Cunningham.

    I think you’re applying a stricter bar than I am on natural language. I’m still thinking of a DoFixture like test flow, but each “grammer” in the fixture would be displayed more like sentences and lose the table driven motif.

    doing this:

    public string TheValueOfTheNameTextboxIs(string textValue)

    that becomes (in Fit)

    |Check|The value of the name textbox is|Ayende|

    would become:

    The value of the name textbox should be Ayende

  • Jeff Moser

    @Ayende: You’re absolutely right. I don’t do a good job of error handling right now. The best I’ve done so far is to put in quite a few debugger step-through messages to make it at least possible to use the debugger without getting bogged down in noise. This is what I use.. but admittedly far less than ideal.

    I think it’s more of a statement on my poor implementation rather than the core idea though.

    However, I think the germ of the idea is there if implemented well with Visual Studio Shell (e.g. debugging a grammar to be as easy as debugging a simple C# program.. highlighting productions, automatically getting syntax highlighting and intellisense from the grammar).

    To do it right, you’d have to have a good meta-implementation… then all the grammars ride the wave.

    I respect the work you’re doing with your DSL book with Boo. I think it hits a good market for the early adopters for Language Oriented Programming in businesses. I suppose I was more attracted to the aspect of the ability of designing an entire system from the metal up using a single meta-language like the STEPS project is doing.

    The side benefit that it also can help solve real business problems is pure bonus :)

  • Ayende Rahien

    > I want the test language to be displayed in natural language as much as possible

    Not going to happen.

    You can get there very easily if you define sentence structure, but natural language is just not possible.
    Certainly not if you want something that will allow reasonable dev time investment in any such feature.

    Can you give a more concrete example?

  • Ayende Rahien

    I looked at OMeta, and it has one big problem.
    Error handling is not there.
    That is, if parsing fails, I don’t know why and I don’t know where.

  • Jeremy D. Miller


    Closer to what you outlined in I want the test language to be displayed in natural language as much as possible, with some reasonable way yet to be determined for table driven tests or mixing table fixtures ala ColumnFixture/RowFixture into the flow based tests.

    For visualization, I’m studying Ward Cunningham’s new stuff for ideas:

    I’m really liking the swimlane visualization as an alternative to denote switching between screens or logical subsystems in a single test.

    But I ideally want Intellisense for filling in the blanks of the test grammars, and some easy ways to define groups of related grammars. What I’m really looking for is a .Net implementation of what JetBrains has done with MPS. They give you Intellisense and even rudimentary refactoring on your external DSL. That’d be the bomb, IMHO.

  • Jeff Moser

    I look forward to seeing what Oslo might offer. There seems to be some similarities to it and what Charles Simonyi tried to get Microsoft to do in the late 90’s (before he gave up, left, and started Intentional Software while Microsoft was busy creating the first version of the CLR).

    I agree that external DSLs can be quite a bit more expressive than what you can do with an internal DSL in something like Ruby.

    In the short term, I think we’ll see gains with more language oriented programming ideas attracting the early adopters in business usage (e.g. more Rails-esque things). However, the real beauty and power will come when the entire stack (metal to user mode applications) is built in a language oriented way (e.g. imagine a DSL built for networking deep inside the OS). The result could be an entire system in around 20,000 lines of code. This is exactly what the NSF funded “STEPS Towards the Reinvention of Programming” project is doing now. It’ll probably take a programming generation to start seeing its return, but it offers the chance for a “Moore’s Law” increase in expressiveness.

    I would be quite a bit more skeptical of the feasibility if they didn’t have greats like Alan Kay and Dan Ingalls on the project.

    The reason why I mention this is because one of the ideas from the project is a meta-language called “OMeta” that makes it really easy to create and experiment with new languages in a very object-oriented way.

    I have started a basic port of this to .NET that I call “OMeta#” and I have put it on CodePlex. It’s been a labor of love, but I think that the core ideas it brings could really help make creating languages to solve problems a reality. It also has some meta-system aspects to it (e.g. the interesting parts of OMeta# are written in OMeta).

    It’s not up to production quality yet, but I think that infrastructure tools like Visual Studio Shell and the DLR will help.

    Unfortunately, it’s probably not on your timetable to be of use on this project if you’re looking for a near-time release, but I’d be interested in your take on the project given the objectives you mentioned in this post.

    If you’re interested in more information on OMeta# or the thought process that drove its creation, feel free to visit my blog or the CodePlex page for it.

    I admire your perspective on design (especially RDD in a TDD context). Keep up the good work and I look forward to seeing how this project of yours will turn out.

  • Ayende Rahien

    I don’t don’t like Ruby (is that a valid statement?). I just don’t think it is the best thing ever.

    I know that this is what I am trying to do when I am building DSL.

    Can you show some samples of the ideal syntax that you would like to have?

  • Jeremy D. Miller


    I’m not ignoring Boo, it’s just that I’m not that enthralled with Boo. You don’t like Ruby, and I’m not entirely convinced that Boo has a viable future. Different strokes for different folks. I don’t see the average tester, even the above average tester for that matter, ever being able to code efficiently in Boo.

    Besides, an internal DSL isn’t quite the experience that I’m looking for here for testing. What I really want is something that does a lot more handholding for the testers than any scripting language will, while allowing the developers to continue writing the test automation code in their normal language (C#).

  • Ayende Rahien

    You are still ignoring Boo as a way to build DSL.
    Check my recent posts about how to provide good editor experience to that, including intellisense.