Rants Tagged with “DSL”
1 (Total Pages: 1/Total Results: 4)
Just a couple of days ago I did the Atlanta stop of the MSDN Developer Conference where David Scruggs and I did a "Lap Around Oslo" talk that seemed to go very well. If you are lucky to have this conference coming to your town, its well worth the $99 investment. Great topics and great speakers (especially if you missed the content at the PDC).
In preparation for the talk, I spent a lot of time looking at the demo script that we were supplied. It was well thought-out and tried to touch on many aspects of the Oslo platform. After the talk we got a number of good questions a about Oslo, Model Driven Development and Domain Specific Languages. That was great. The only frustration is that some of the students got stuck on the concepts in MSchema. They seemed to be more interested (or more importantly could see the value) in using MSchema to define their schemas and data. My fear here is that there were getting caught up in the details instead of seeing the big picture (which to me is Models and DSLs).
This isn't the first technology talk that to confused and obfuscated. LINQ is my favorite example. In most of the early LINQ demos I saw, LINQ to SQL was used as an example of the power of language integration of a query language. The problem is that people left the talk thinking (and many still think) that LINQ is an ORM over SQL Server. This causes two problems, either attendees that miss the message leave thinking that the technology doesn't apply to them (i.e. I already have an ORM) or that they focus on the part of the technology that they understood well (LINQ to SQL has a big following even if Lambda's and LINQ in non-db hasn't gotten as much traction as it might).
Applying this learned lesson to Oslo, I sincerely hope that attendees heard the message of model driven systems and domain specific languages. These two technologies are not a new invention (after all, "Little Languages" was coined in 1994), but Oslo does make it very approachable. Writing a DSL grammar with MGrammar is simpler than my earlier attempts with other technologies. These represent an opportunity to shift the way we develop software. I hope that message is being heard loud and clear.
What's your take?
Now that Oslo is in a public form, I've taken time (as you probably noticed in earlier blog posts) to look at Oslo. While the Model Driven Development part of the stack is important and potentially game changing, I wanted to stop and look at the Domain Specific Language part of the Oslo stack.
I am not the only one though. The potential for building Domain Specific Languages has caused jeers and leers from different parts of the web including Martin Fowler, Frans Bouma, and Roger Asling. Aside from the whether "M" becomes a valid way to build Domain Specific Language, I am more interested in the idea behind Domain Specific Languages themselves.
Honestly I am not sure whether I am early or late to the party. My interest was peaked at a party where I was a fly on the wall with the likes of Don Box, Chris Sells, Ted Neward, Neil Ford (et al.) all discussing what it meant to be a DSL and why it was important. I've be stewing and thinking about it quietly since then to try and understand really what is means to me and the problem spaces I care about. This is what I came up with.
Business software is written to solve business problems. The people feeling the pain of the business problem are often the people running the business. The people that run a business are rarely the technical folks. Before software is written we need to understand the problem so that we can figure out how to solve the problem. That means that technical folks have to talk to the non-technical folks to understand the problem. Traditionally that is how requirements are gathered. So what happens next? Typically the requirements are written down and communicated back to the non-technical folks to see if the requirements are still correct as simply transcribing them can introduce errors in the requirements. Finally the requirements are shared with developers to implement the requirements.
This doesn't work well as well as it should.
This problem is that the two groups involved often do not speak the same language. Language is a big deal here. Every business has its own vocabulary and unless the technical people have been in the business for a long time, they don't understand that vocabulary. Even developers have their own vocabulary and we know that most people don't understand what we are saying (especially our spouses), so why should it surprise us that we often do not understand the vocabulary of the business we are working with/for?
This is exacerbated by the problem that contractors are being used to a great extent these days. It used to be that developers in an enterprise would learn their domain. Part of the process of working in a company would be learning the language of the company and how they did business. To my surprise many companies are investing in contractors to teach them their domain and then cutting them loose. This means we need to have a way get domain knowledge "out of the head" of the stakeholders and into a form that can live for longer than one product cycle.
In the recent Oslo .NET Rocks Podcast, Don Box and Doug Purdy talked about the problem of coders and encoding. If you haven't listened to the podcast yet, i'll paraphrase. We learn from the non-technical folks how to run their business, then we write it down. We take the written down version and ask a 'coder' to encode the rules in code. The essential problem here is that we can't have the non-technical folks read the 'encoded' version to figure out if it matches their intent. It also assumes that the developer understands the language of the business well enough to make sense of the written down version.
The other problem is that as the business changes, the whole cycle has to repeat. Once the documented business process is encoded, changing it requires re-encoding of the change. This is problematic.
How do Domain Specific Languages fit into problem space? I think that if we can talk with the non-technical folks and create a textual DSL (or perhaps a visual DSL) that is clear enough for the non-technical folks to read it (not necessarily write it), then we can use that to document the business problems. That would allow for the developer to use that data at runtime instead of encoding it. That means that the non-technical folks can *validate* the actual business rules (not the documentation that is being encoded) so that our systems are less prone to communication confusion. In addition, this means that as the business changes, the changes to the business rules are interpreted by the system instead of being re-encoded.
This doesn't take the developer completely out of the picture as developers still need to use the runtime information to make the system work as well as develop and maintain the DSL. Rarely will a DSL be complete. As business requirements change, the DSL will often have to change to accommodate new business rules. But that leaves the developer from having to have intimate knowledge of the business (though tertiary knowledge is still required).
At the end of the day this allows fewer points of failure between the business intent and the runtime environment. At least that is my hope.
Of course, this is not new. We build and use Domain Specific Languages all the time on projects. Every time we build a new configuration file section, XML Schema, or use one of the plethora of common DSLs (e.g. XSLT, XAML, CSV) we are using DSLs. The difference that I hope this brings in is the ability to have DSLs that are consumable by non-technical stakeholders in the business.
What do you think?
I've spent a number of hours since I downloaded the Oslo SDK to look around. In this post I want to tell you what I've found out.
Oslo is a funny beast because its multi-layered. With only a couple of hours on its hard to even know if my assumptions are all correct. I am sure we'll see in comments if I am far off or not.
As I read stories about Oslo before I was able to look at actual bits, I felt confused. I heard two stories: "Oslo is about Modeling and Model Driven Development"; and "Oslo is about building Domain Specific Languages". So which is it? Both.
I used to be "The ADO Guy" so lets start with the modeling:
Modeling Features
Oslo's Modeling Platform is a layered technology that is made up of several pieces:
- Quadrant: A Visual Designer for flowchart-like models.
- The "M" Language: A Textual DSL that supports creating your own system models or extending the built-in models.
- "Oslo Repository": A Database for storing models to be used at design-time and runtime.
In the SDK that I have played with, Quadrant isn't included (it is in the Oslo Virtual PC that is on the PDC attendee hard disk) so I haven't had any opportunity to look at that. What I did spent time with what the "M" language and a simple editor for it that is included called "Intellipad". The "M" language allows you to define quite a lot about an application, but the only part I played with so far is the modeling of data. Using Intellipad I attempted to model some Video Games data that i've been playing with in demos and the Silverlight 2 workshop. Intellipad simply lets me define the types including the data extents:
What is particularly interesting here is how the "M" language can be used to generate SQL scripts to create the storage. In Intellipad we can show a panel that shows the generated SQL:
(Click for a larger view of the SQL)
This is enough to keep my interest. I like where this is going but until I can really see what Quadrant does its hard to see how this fits into the bigger picture. So now lets look at the Domain Specific Language underpinnings:
Domain Specific Language Features
Of even more interest to me is the infrastructure that they used to build the modeling features. The "M" language is actually a Domain Specific Language called "MSchema" built with the Oslo Domain Specific Language ecosystem. MSchema defines a "little language" that is used to define models. But how is MSchema defined? It uses a lower level Domain Specific Language called MGrammar. MGrammar defines a "little language" for defining Domain Specific Languages. Beneath both of these is another language called MGraph that I haven't totally grok'ed yet.
I haven't had time to try and build one but in the SDK is a cool small example called "Song". This small Domain Specific Language defines a "little language" that supports songs as a list of notes and rests, for example:
Music
- - - D
C C# F G
E E - D
A E - E
G F - E
D C D E
A E D D
D E A C
More importantly, we can use the MGrammar to define what this language is composed of:
In most other instances I've been pushed to think of Domain Specific Languages being build either in a language (usually something like Ruby with lots of Macro'ing) or in data structures (like JSON or XML) since both of these ideas allow for avoiding building my own parser. The Oslo stack changes this idea for me an really allows me to define small languages without the need for these scenarios.
You may be asking how Domain Specific Languages impact you as a developer though? I recently gave a talk at the Atlanta .NET Users Group to try and cement some of these ideas. My overarching idea is that by writing "little languages" that use the same semantics as the domain, we can 'code' the intent of users in a domain (e.g. a business) and then the domain's stakeholders can validate the 'code' since its written in the language of the domain. But that's a story for another post. Understand that I see Domain Specific Languages as a powerful idea for everyday programmers, not just academic scenarios.
This is just a tiny taste, but so far I am incredibly intrigued by the possibilities of Oslo. In the coming months you can expect to hear quite a bit from me about this topic. But I am no expert. I started down this Domain Specific Language path by trying to read and study information on the topic. By far the best thing I ran across was this great video by Martin Fowler that everyone should watch...its well worth your time:
Since Martin Fowler is important in this space, I was thrilled to see he was shown a preview and had time to give his first impressions as well:
What do you think?
Head over to the Chris Sells' blog to get all the details on the new public CTP of Oslo. This toolset has the possibility to change the nature of development in a major way. If you are interested in the modeling or DSL space, its definitely worth your time to dig into the tools.
