#begin
The next topic in the book is about domain languages. We’ve talked about this is previous blogs as well since I personally think domain languages are very important. I try to create an ubiquitous language whenever I can. Ever since I read Eric Evans’ book about Domain Driven Design, this has been integrated in the way I work. I’ll often ask stakeholders of projects to define the words or terminology they use so we can come to a consensus about the domain. So I might even ask if the stakeholder could define what a User is.
But since this book, The Pragmatic Programmer was written way before the DDD book this is not exactly what they mean. It comes close I guess but what the point authors want to drive home here is more oriented towards Domain specific languages (DSL). A DSL is a language fully oriented around the problem space it wants to solve. A very good example of a DSL is; SQL. SQL is not a programming language, but it is a DSL to express queries.
The authors say that languages can limit the way we express and talk about things. This accounts for both natural languages, like Dutch, English or Spanish, but also for formal languages like programming languages. When you try and solve a problem in C# or in Clojure the end result will be far different. Furthermore, certain problems fit better with one programming language than the other. So they say that you might be able to create a mini-language to create with your stakeholders or domain experts.
This seems like a really great idea to me, but one that I’ve never actually tried or implemented. And implemented can mean a couple of things here. You could implement a real, compiled or interpreted language but it could also be just a simple written language on a piece of paper, just for the sake of empowering communication.
They also specifically mention that these domain languages can be specifically made to configure and control applications. This sounds like such a cool idea to me. Also considering Prof. Ousterhout’s comments about creating config files for systems, thus laying the burden of complexity at the seat of the user. If you could combine the two, you might we might be able to reduce the complexity of configuration just by using a DSL. And to add to this, domain language can also be used in error logging and handling. So instead of throwing cryptic .Net errors, throw errors that match the domain; like AvatarNotFoundException if your 3D character avatar cannot be found. I think Uncle Bob as well as Prof. Ousterhout have talked about this too. Always throw descriptive error messages.
The next couple of subsections involve some examples about how to actually implement such domain language. I wont go to far into detail here since they involve some syntax and explaining it wont make much sense. But you can get your copy of the book and check it for yourself. Or you can search around in your favorite search engine on how to create a DSL.
I will however talk about something very important they mention here, and that is the different types of domain languages. They say it comes down to two types, either your DSL is a data language or an imperative language. The difference in these languages are the following. With data languages you often specify, well, data. This data is then interpreted by some code and and most often turned into, you guessed it configuration or control. An obvious example I can give in a Unity3D context are ALL JSON and YAML files you create. So all your prefabs, scenes, project settings, preferences, animators etc. would fall in this category. However, JSON and YAML are widely accepted and really standard forms of a data language. But you could on the other hand design your own and use that. Nothing is stopping you to do so.
But on the other end we have imperative languages. These types of languages differ from data languages since they not only can contain data but also expressions. These expressions can be executed and control things. Examples of imperative languages are the language you probably write in every day, C#, but also C, C++ or Java. In fact, all languages that derive from C are inherently imperative. Yes, I know the lineage goes back further to like Simula or Algol but I’m gonna leave these out since people probably don’t know about them.
Andrew and David also mention the fact that meta-programming languages exist. These are again a bit different from DSL since they serve a very specific purpose. Meta-programming languages are often designed to use data of another language to operate on. I find it quite difficult to explain this but I can give you an example of a meta-programming language I used in the past.
So I’ve used a meta-programming language called Rascal. Rascal is a meta-programming language with the capability to do code analysis. So with rascal you can read in the source code of a project, and extract what-ever metric you want to know. So I used it for analyzing the average cyclomatic complexity of a project, average lines of code per class, average length of lines in the code, number of classes that make up a component and more. I even used it to analyze the source code and pick out the duplicated code snippets. It was a lot of fun and it really though me a lot. This was all part of a course in University called software life-cycle. It took some time to get used to the language features and syntax, but in the end it turned out to be pretty cool. You could also generate some great visualizations with it like you see in the code-city visualizations.
The last interesting thing the authors mention in this section is the fact that, with more code, comes more maintenance. Yes, this is certainly true. So although DSL’s can give you great extensibility and ease of development, they do incur some form of maintenance. And as with any other type of maintenance, you really need to stay on top of this. One way of keeping maintenance of your DSL in check, is to create a simple language; which seems kind of obvious but still. If the domain language is simple, maintenance will be too.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments