I was just listening to the Ted Neward talk on .NET Rocks during Oredevfrom a while back. It’s a very interesting discussion and I would definitely recommend listening to it. Ted, Carl and Richard discuss a variety of things such as Oslo, functional programming and DSLs. There were a few things I wanted to comment on since I spend a lot of time thinking about DSLs; perhaps I can add to the discussion.
Here’s a little paraphrase that Ted boldly proclaims towards the beginning of the conversation:
The next 5 to 10 years will be about programming languages… the renaissance of the programming language.
I couldn’t agree more.
There are a lot of things said and I agree with almost everything. There was one question outstanding that I would like to try to respond to. I don’t remember who said it exactly but the generalized question was “what is the business need DSLs are trying to solve?”.
Here is my response as succinctly as I can put it:
Constraint increases scalability.
This maxim has a multitude of implications, because in order to increase scalability we are talking about code that is easier to maintain, understand and author. We are also talking about code that is consistent and accurate while still increasing productivity. There are many factors that go into scalability and I think, in general, DSLs are the solution to the broader problems. Because when you think about it the most powerful aspect of a DSL is the fact that it is a constrained universe.
So to put it in more practical terms, I think as projects become more and more complex we will need DSLs in order for it to even be possible. This idea was somewhat given to me by a talk at the Lang.NET symposium I heard by Roman Ivantsov related to the failure rate for extremely large projects.
I would also add that while it may be necessary to have DSLs for larger projects it may be merely helpful for smaller ones. But in a competitive market any little advantage you can gain in productivity is usually a critical factor in the success of your projects overall. After all, most general purpose languages we use today could be thought of as a DSL over machine code itself, it’s simply the domain of programming in this case. Another way to think about is to say that a while loop is just a construct to help us safely use the jump instruction. But nobody today would argue that using a popular general purpose language is worse than manually writing assembly code. The sorts of productivity boosts given to you by a modern programming language is undeniable and used by nearly everyone.
But back to the idea of constraint as a good thing. We normally think of flexibility in a programming language as a good thing but I would like to go ahead and claim that the opposite might likely by true. Perhaps flexibility in languages in the past was necessary because of the general nature of their purposes as well as the rapidity with which they can change (slow). There are entire classes of solutions that require lots of flexibility in order to be solved by a general purpose language.
However think of the value that design patterns bring to a general purpose language. As you’re implementing your application you start noticing patterns, places where you tend to need to do the same thing over and over, you may abstract that into a design pattern. Unfortunately due to the general nature of the languages we tend to use, it is very easy to stray from the patterns we have created and do something that breaks that pattern due to ignorance, or haste or whatever. This usually results in an increase in complexity and maintenance. And there is nothing more permanent than a temporary fix.
For example, just because you’ve gone through great pains to create a Data Access Layer and Business Logic Layer, it doesn’t mean that somebody won’t spin up a SqlConnection in the middle of your view and screw everything up. There are ways to mitigate this, code reviews, static analysis, education, etc. but these are all simply other forms of constraint. What if the very language you were using to create your application didn’t even have the capability to stray from the accepted design patterns. What if your view was written in a declarative DSL specifically for authoring views where accessing data was completely agnostic to the implementation, and interpreted at design time or runtime to always go through the accepted channels? This is how a DSL can increase scalability.
Design patterns are DSLs.
Any where you can abstract your application into a design pattern you should be able to create a DSL to express that design pattern. Additionally, those DSLs should be re-usable and implementable in any application. An interesting example of this is the Axum programming language, specifically designed to solve the problem of concurrency by creating a language constrained to enable concurrent code safely. Under the hood the code created is something you could have done manually in any general purpose language but the more we can be constrained and declarative about such things the less error prone the underlying code will be. Additionally it helps us to easily understand and implement highly complex code, which increases productivity. Even the smartest developers have a hard time getting concurrency right, we really need constraint in this domain because its incredibly easy to do something unsafe.
There are a few things we need in the programming community in order to make any of this feasible, which we are currently lacking. I have been working on MetaSharp specifically to solve some of these issues, but it has a long way to go. Here is a brief list off the top of my head of problems needing to be solved by a DSL tool:
- An open, transparent, extensible, language agnostic compiler.
- A common, extensible AST.
- An excellent, runtime based grammar parser.
- Common transformations.
- IDE support, for debugging transformations as well as author time feedback and visualization.
I could go on and on… but look forward to our future of programming languages. In the near future we may finally be equipping ourselves with the right tool for the job at hand.