Overview
A domain is a set of characteristics which completely define a problem. Think about everything a person has to know in order to perform their job. That knowledge is part of the domain in which they work. It is quite common for people to have at least some knowledge of many different domains and for portions of those domains to interact to provide a solution for any given problem.
Years ago I predicted (wrongly I might add ;-}) that by now the need for general purpose software developers would be nearly extinct. I believed that the knowledge necessary to perform in any field would out-weight the knowledge necessary to develop a computer system within that field. In other words I felt that it would be easier for a brain surgeon to learn to write software than it would be for a software engineer to learn brain surgery. Whoops. Missed that one.
As it turns out computers have remained black boxes to most people outside of the tech industry (and unfortunately to many people inside the tech industry as well ;-}) What most techies tend to have trouble understanding is people aren't interested in what computers can do, they are interested in what computers can do for them. Most people want to be able to tell the computer what they want in the same way they would tell a colleague. They want the computer to be able to "understand" the domain they are working in.
As techies we inherently understand this as is evidenced by the number of DSLs we have created for ourselves to ease our own lives. SQL is a good example of a DSL. SQL doesn't provide any mechanisms to create data structures or access a network. SQL provides the capability to manipulate and retrieve data. This is all it does and it does it well.
The following list provides examples of some well known DSLs:
-
SQL - Structured Query Language
-
YACC - Yet Another Compiler Compiler
-
UML - Unbelievably Messed-up Language
-
XAML - Extensible Application Markup Language
The Goal
- until neither the Plain nor the Star-Bellies knew
- Whether this one was that one or that one was this one.
- Or which one was what one or what one was who. - The Sneeches by Dr. Suess
Over the past few decades we have been trying to put a finger on what will bring the business guys together with the tech guys. Since the days of the first computers it was clear to techies that these machines could offer huge benefits to business, if only they could understand what it was the businesses really needed. Business users were also awed at the incredible potential these machines had to offer if only they could communicate what was they really needed.
What's needed is a better division of labor. Techies need to be able to create concrete rules and concepts which encapsulate the domain and then to present those objects to business users in a way that the business users can arrange them to solve problems. It is not the responsibility of software developers to learn how to perform brain surgery. The job of the software developer should be to provide brain surgeons with the tools necessary for the surgeons to perform brain surgery better.
Currently the blame for this miscommunication rests firmly on the shoulders of the techies. Most industries already embrace some sort of DSL analog equivalent. Physicians refer to parts and procedures using specific terms and syntax to help them quickly communicate without ambiguity. The language they use has evolved to become both well-known and robust and should be adopted by techies and not redefined.
If Diagnosis is Spinal Disk Herniation and Treatment is NSAID verify DUR
Let the techies develop the DSLs. Allow users to use them in ways that are much more dynamic than they would be able to convey to the developers.
Why Now?
We've been looking for the golden goose for a long time, and many things have brought us closer. OO was a huge step along the path. SOA was another. Large scale collaboration yet another. Recently there have been a number of other changes to they landscape which are helping to prime the DSL pump.
Recently Microsoft released .NET 3.0. What this provides is much more than just an upgraded object library. .NET 3.0 contains 3 very important pieces: Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) and Windows CardSpace. Together these three frameworks provide authentication, interaction and scripting capabilities that will help shine a spotlight on the importance and benefits of DSLs without specifically calling them out.
Another very important feature is also provided by Microsoft in the form of the .NET CLR itself. The CLR was designed to be easily extended as is evidenced by the creation of IronPython. The flexibility to introduce new languages and constructs into an already robust VM is huge. This provides a mechanism for easily and safety installing new domains into existing environments. Big win!
What's Missing?
There are still a number of short-comings with what we have today.
One of the most obvious is the absence of a role model. A reasonably complex DSL needs to be developed and put to use for users to realize the potential and for developers to use as a template. This is more difficult than it sounds since I don't believe it can stem from academia. IMHO, this must come from the real world and solve real world problems before being pulled back into a research environment. That means it will take real time, money and resources to create which is a difficult argument to make in most companies.
Despite what I said about the framework advancements integration is still a problem. While integrating C# and SQL may be a huge advancement (not that I think LINQ itself is any good mind you ;-}) it is a far cry from providing interfaces between DSLs developed by different groups. It is imperative that DSLs and general purpose languages are capable of easy and efficient interaction. It is the only way to capitalize on the vast amount of disparate knowledge available world wide.
The final missing piece is any real effort by the techie community to move toward the new paradigm. Business continues to push technical development into a model it understands, one developed by the likes of Henry Ford. MoBetterFaster is the word of the day. Instead of trying to work out a better solution to the problems we're facing, we are compelled to find quicker and cheaper ways of producing results using the current solution, faulty or not. The upside of this is that the man who does evolve will be king, and is probably already setting up shop in a garage in the valley ;-}
Summary
Being a product of the PowerPointized culture, let me do this in a way that's easy to understand:
- DSL = Good
- Getting Closer
- Not There Yet!
Got it? Good.
TTFN