04/14/09 :: [MOP] Understanding Oslo [permalink]

First and foremost, I am not the only one to have concerns about Oslo's "pragmatism". As I said, this was kind of a disaster in WCF, I am quite surprised that pretty much the same people get to try the same thing.

I certainly support Lars' idea to bring together in the same room people like the oaW team, the EMF team and the Oslo team (it would be quite something to meet at the M3 bar in Oslo). Software engineering would make a huge leap forward if that would be to happen.

You gotta love Dave Chappell's humor too:

"Initially, Oslo referred to a lot of different things," said David Chappell, principal of Chappell & Associates in San Francisco. "Now, Oslo refers to modeling technologies. and the repository. So just in terms of clarity, that's progress."

Indeed, progress it is...

Oslo seems quite ambitious despite this demotion. Burley Kawasaki explains:

Oslo will provide a consistent application model across both on-premise and Cloud environments...Oslo as a general purpose modeling platform can target any number of environments... one of the big breakthroughs that we see is that Oslo was built from the ground up assuming there was going to be this composite world

Doug, with such an ambitious target why are you wasting your (and our) time on CRUDish-REST services? When can we see this in action? which programming model are you going to use? So far it is not very clear that you even understand what "composite" means. As a reminder, Microsoft tried to kill all "choreography" standards (I was present in both when that happened), declined to participate in some aspect of SCA and has no understanding whatsoever about the BPM field. So I really can't wait to see what you guys are going to come up with (hint a bunch of webparts don't qualify as a composite application). Again, looking outside the box would really help you.

One of key pieces that seems to be missing in Oslo to "target any number of environment" is a transformation capability. This is related to the discussion Runtime vs Code Generation. I am not a big fan of "code generation" but Artifact Generation is kind of a must in such framework.

Shawn Widermuth has written a good introduction on MSchema. 

MSchema is a language for defining your data store and relationships between data that Oslo uses to define how to handle storage.

I don't care about that, as a matter of fact, Thomas Huijer writes an hilarious post where he claims:

I recently was in a session on Oslo, when someone at the very end asked: “But this MSchema thing isn’t really different than T-SQL, is it?”. Well, that person completely missed the point of M and Oslo.

If it is agreed that MSchema is more constrained than T-SQL in what it can do, Thomas don't seem to realize that MSchema is just a "cleaner" way to write some T-SQL. T-SQL is metadata, just like C# is metadata...ah and just like MSchema. This is where model transformations come handy.

Creating database schemas and storing data is not such a great problem to tackle. Murl is another one of these problems that are not really going to drive your Oslo's requirements very far. I mean come on Doug, do you need a DSL to create CRUDish HTTP requests?

Lots of people seem to agree:

I just found out about Oslo the other day and it seems like it has incredible potential. However, the more I use it, the more wasted potential becomes apparent. The Oslo FAQ attempts to stress that the Oslo repository is not yet another database, but it doesn't seem to provide much to back that statement up. That's because right now, there isn't anything to back that up. [don't forget to read the remainder of the post].

So, if MSchema is pointless, how about MGrammar?

MGrammar is what you use to define textual-DSLs. I did not get a chance to create MGrammar's metamodel, i.e., in first approximation, Oslo's M3 layer (if I understand your architecture correctly). James Clark provides a good analysis of the tool which is not much more than a clone of xtext.

There's a bigger issue lurking here.  I think Microsoft see Mg as more than just a nifty library.  It's part of their vision for a next generation application development platform, where developers become more productive by using custom DSLs rather than XML [as a common syntax]. I have mixed feelings about this.... How do you make your platform encourage developers to use a DSL where it makes sense, and discourage them when it doesn't? Up to now, part of the answer was that libraries made it a bit easier to use XML (or some other standard format) rather than some completely custom syntax; so unless there was a substantial benefit from a custom syntax, developers wouldn't bother...It doesn't help users if they have to learn a new syntax for every application...I definitely don't want every application to be using its own completely custom syntax.

I think that James nailed it on the head. Doug, what's the point of using a DSL when you can create a library with a well defined API in a particular programming language? Oslo lives at a much higher level, the one that Burley is talking about or what I call Metamodel Oriented Programming.

Ray Ozzie, Chief Software Architect at Microsoft, ended his PDC keynote ... by cautioning that the new technology is "nascent." Hopefully Microsoft won't have to use forceps like in the good CSD days.

Doug, Charles, I would certainly spend quite some time to correct the perception that quite a few of us have (hopefully this is just a disconnect between us and you guys) or if it is more serious, I would look at correcting the course by spending some time away from Redmond.