I enjoyed Jeremy's post about Oslo.
In the comments, there were lots of follow-up questions about the realness and substance of Oslo, and the target customers of the language. Here's some reflections from one Oslo guy...
What we shipped in our first CTP is very much an early alpha of our bits. And, it represents the lowest level of the platform without many of the services, libraries, and bells-whistles that you'd want as a developer. It's as if we shipped the .Net runtime and C# but without any libraries or tools. So, that may be some cause of confusion.
Why did we do this? We wanted to get out the core of the platform as soon as possible so we could start having real discussions with customers and partners. We also want the developer community to embrace modeling as a key principle in the future for how we build applications.
Ultimately, our goal is to enable declarative, model-driven programming. If I look around, I see people doing this today in the form of XML schemas and dialects, various textual reps, and frameworks that encode a domain. We went down that path as well, using visual designers and XML. But at some point the pain was too much :) We evolved our approach into Oslo by trying a more holistic solution. We wanted an easy-to-use language to write down declarations. We wanted a place to store those declarations, and then query, and even compose that data (i.e., join) into "instructions" that runtimes could execute to produce interesting behavior. And then, the idea of making it very easy to create a textual DSL over the model/declarations seemed like a natural step forward to enable app development in an elegant way. It just all fit together for us - and we wanted to share as soon as we could.
Let me also comment about our target customers. We are all developers on our team, and we care deeply about developer tools and productivity. We do not really talk much about making business users programmers. I have to say that personally, I think having a DSL may make it easier to have interesting conversations with business users about the solutions that we build for them. But I don't think that makes them programmers. It just makes it easy to write things down and share/design it with them.
...end of reflecting for now.
Posts
7 months ago
20 comments:
My view is that the problem isn't what you've delivered, it's that there was too much hype and the message hasn't been clear.
On the hype I think it is worth saying that we've had announcements of game changing breakthroughs before, including with WSDL and WCF, but enumerable times in the past. Some of these have delivered some value, many have not, so I think its fair to say that we'd be smart staying a little pessimistic.
The second reason is that the way its been discussed has left many of us pretty cold. To many of us models are active things, we're thinking behavioral domain models and possibly using DDD and OO. Even if we're not using DDD we do want to build in behavior. Microsoft has a poor
However the message has all been data, data, data. Its been about XML, XML schemas, Excel, passive models consumed by workflow/services/rules. That means very little if your target audience are people developing real systems today using object-oriented languages and techniques.
I'm not even clear how you fit behavior into your model, how do I have a Customer/Account with real behavior in it? Should I really need to download Oslo and try it out to find out?
"I have to say that personally, I think having a DSL may make it easier to have interesting conversations with business users about the solutions that we build for them"
Me too, but there is almost no discussion on this side of Oslo.
Colin,
On hype - I love that folks are cautious. I would be too. In fact, I hope that you continue to push and ask hard questions so we can get it right. Our goal is to make it better for all developers.
On behavior - I think I need more education here. What do you mean by behavior? Isn't a workflow behavior? Or are you looking for the more traditional "model -> generate OO code" kind of thing?
Our focus at PDC was on developers for developers. We want to spend our "hype" dollars carefully ;)
"What do you mean by behavior? Isn't a workflow behavior?"
Workflow and services are definitely one approach, both are fine and certainly have their place.
However the domain model itself (Customer/Order/Account/FeeSetting) should also contain behavior.
"Or are you looking for the more traditional "model -> generate OO code" kind of thing?"
Well in DDD the code is a key expression of the model, you don't create a whole lot of UML and then generate code. That approach has tried and failed several times. Instead you focus on your code (C#/Java) being a clear expression of the problem domain.
So if my domain experts talks about a client medical history then I'd quite possibly have a ClientMedicalHistory class in the model. If she talks about some behavior being closely related to a clients medical history then its quite possible that the ClientMedicalHistory will take on some/all of that behavior.
At the very least we're talking validation but in complex domains we might have all sorts of behavior in the model itself.
I'm sure you guys have thought of this style but if not I'd certainly start looking at it now because I think one of the big failings in previous MS initiatives (including EF v1) was not correctly supporting this style of development.
Thanks for the clarification.
I (and we) understand the modeling approach you take, that is, use a general programming language to capture the domain. Great. Love it. We're not trying to prevent that.
We're trying to add a new way of doing modeling that augments what people do today, that is, lots of declarative/data-driven stuff in XML. In a data-driven world, you model behavior as data and use a runtime like WF to execute it.
Why would you do that? Well, there's lots of benefits from turning behavior from imperative code to declarative content. It's data so you can more easily query and transform. You can also more easily persist it, and send/receive it. You can build multiple interpretations of it (my favorite reason), e.g., if you want your own patterns and practices about how to execute a workflow, then you can massage to data to get that. That's much harder to do in C# - I've tried :)
But again, by no means are we saying that you shouldn't use C# or Ruby or whatever general language you use to model your domains. We just offer a higher level of abstraction and a data-oriented approach to modeling.
Just to be clear, I didn't think you guys were trying to discourage us using general purpose languages and I only gave that as an example of what we do now. If Oslo offers a better path then I'd take it (or use it wherever it suited.
"We're trying to add a new way of doing modeling that augments what people do today, that is, lots of declarative/data-driven stuff in XML"
Get you, was hoping Oslo might enhance the approach I'm using now for example by allowing me to build DSLs on top of the existing behavior rich models I am creating.
"In a data-driven world, you model behavior as data and use a runtime
like WF to execute it."
Coming back to the behavior issue though, lets say I buy into the advantages of my entire model being represented as declarative content. Will you be providing any way to actually include behavior in that model, so that any DSLs I create can look as if I do have a behaviour rich model?
I can't see why not.
"Why would you do that? Well, there's lots of benefits from turning behavior from imperative code to declarative content."
I'm looking forward to being surprised but I'm not imaginative enough to think why the benefits you describe would be useful in domain modelling, not saying they don't have value elsewhere though.
There is good news to help you with DSLs and your current approach.
You can choose to use our MGrammar language to write a DSL. MGrammar produces structured data. You can then write a small program to process that data and turn it into your OM or anything else you want to. This gives you the flexibility to separate the language from the implementation, support multiple implementations in time, and to present a textual DSL to customers. There's a couple of posts on how to do this, and a sample in the SDK.
Ok ta, yeah that makes sense as its the sort of process you might use if you were creating a declarative internal DSL using a dynamic language. I'll definitely give it a shot.
thanks for sharing perfect site ı am coming everday here
sesliserbest
sevgiadresi
seslidünya
i love here ı am comın everday because perfect web sıte
sesli chat
sesli yes
eniyisesli
konya chat
isvicresesli
hollanda chat sitesi
sesli siteler
seslicet
esesli
sss
sss
sss
ssss
thnks
wery thnks
very nice
Thank you for your share!It is wonderful!!
sesli yes sohbet sesliyes sitelerine buradan giriş yapın saygılar thanks for sharingpornsesli good yalandünyam
thank you admin
Just came across your blog through a site and found it interesting and informative, will definitely keep visiting for more.
massasje i oslo
Hi the information on this blog is just amazing it keeps me coming back time and time again ,personally i met my wife using this site so i couldnt like it any more i have done my best to promote this blog as i know that others need to read this thing ,Thanks for all your effort spent in making this fabulous resource ! ok,nice one Jake
Post a Comment