DSLs, or Domain Specific Languages, have been known in software engineering for many years. Despite this fact, they aren't widely used today. In this article we take a look at what DSLs are and why they aren't widely accepted by mainstream developers. Then we describe how JetBrains MPS solves the main problems which stop DSLs from being widely used. http://www.dzone.com/links/r/solving_the_problem_of_dsls_adoption_in_mainstrea.html

"You can give a DSL to a domain expert, and she can write code in it thanks to her knowledge of the domain itself." Which is why there are so many "domain experts" using Regular Expressions, SQL and Prolog?!?

"You can give a DSL to a domain expert, and she can write code in it thanks to her knowledge of the domain itself."

Which is why there are so many "domain experts" using Regular Expressions, SQL and Prolog?!?

Although I appreciate that DSLs can improve development times, I am far more concerned by vendor lock-ins and company internal DSLs - a nightmare for consulting companies and external contractors. I posted my thoughts on DZone, I do not want to double post. In short, I concur with you.

These are just examples of widely used DSLs and there are very few such domains. If we created DSLs for more narrow domains, we would get substantial productivity benefits.

These are just examples of widely used DSLs and there are very few such domains. If we created DSLs for more narrow domains, we would get substantial productivity benefits.

Which domains would that be? Every domain I can think of where a domain specific language exists, it is not really widely used by "domain experts" except if they happen to be engineers. Examples: Visualization: PV-WAVE Symbolic Math: Mathematica, Maple Document Transformation: XSLT Machine/Measurement/Process Management: Labview Graphical Interfaces for Business Processes: SAP .....

If I get the picture, Konstantin's idea is to have many micro-DSLs on top of a standard language (e.g. Java) to depict very small domains and "ease" development. Besides the confusion that bringing so many small-scale DSLs will introduce in the source code, my question is still how this will impact (timescale/budget) projects where teams foreign to these DSLs are being introduced. How steep will the learning curve be? How functionally complete/well working/well documented will they be? I am not saying that is a bad idea, I just have many more concerns than enthusiasm about it.

When people talk about Java libraries, they usually don't have such question. Everyone know that libraries can be learned quite easily but this of course requires an effort. If we wrap libraries with language, not so much things will change. Actually, because language is more concise and best practices can be encapsulated with language constructs, it should be easier to read. We had experiment with it. We had interns programs when we hire students and give them experimental or internal tasks. Once we gave a student languages for web development, and asked him to write a simple CRUD application for internal use. He was able to accomplish this in a very short amount of time, in about a week. If we gave him, JEE technologies instead, it would take at least a month.

The idea of wrapping library constructs and/or idioms with tailor-made syntax of course remains an attractive idea. Just take a look at how many small language changes were proposed recently. Although it's maybe not really a DSL, consider something like the following: instead of transaction.start(); // do stuff transaction.commit(); it would be nice to write something like: transaction { // do stuff } Of course, with EJB3 you wouldn't even have to write the transaction{} thing, but bare with me, this is just an example of how language constructs can wrap library functionality. Basically, using custom tags on a JSP might be a little like this, although I assume this DSL thing goes a lot further than this.

. He was able to accomplish this in a very short amount of time, in about a week. If we gave him, JEE technologies instead, it would take at least a month.

I do believe what you say, but a statement like this does have to be weighted against several other factors: how easy is the code to change 4 weeks from now? 8 weeks from now? how easy can it be extended? how does the code scale performance wise? was the student asked to build a specific thing? what if we want to defer a little from the defaults, does the tech allow us to do that? I've seen in the past several claims like this being made. An infamous one was that with PHP you didn't need any education or even talent for that matter to be able to build an 'industrial strength' (whatever that means) web application. This was supposedly because PHP was so simple, you barely needed the ability to think. Of course we now know the complete and utterly unmaintainable mess all those 'people without knowledge' produced using PHP. It's the type of stuff you read about on thedailywtf. Another example is that platforms that basically generate an application for you allow you to work 10x faster. Ruby on Rails may be an interesting example here. In case of RoR this actually works out pretty nicely, but the downside is that as soon as you want to deviate from the 'golden path', the framework starts working against you instead of before you, and your initial speed gains all but vanish. Java EE may be a little slow to setup, but along side mature technologies such as C#/.NET (yes, I know it's not a popular thing to say here, but that platform is actually pretty mature and flexible), it gives you a lot of power at a very reasonable complexity tradeoff. So, it might be true that your DSL allowed this particular student to produce results faster, I still have to take the statement with a grain of salt given the many times I've heard people talk about Java EE killers that offer 100 times productivity enhancements. As said, it almost always comes at a cost. Ain't such thing as a free luch...

Another example is that platforms that basically generate an application for you allow you to work 10x faster. Ruby on Rails may be an interesting example here. In case of RoR this actually works out pretty nicely, but the downside is that as soon as you want to deviate from the 'golden path', the framework starts working against you instead of before you, and your initial speed gains all but vanish.

Java EE may be a little slow to setup, but along side mature technologies such as C#/.NET (yes, I know it's not a popular thing to say here, but that platform is actually pretty mature and flexible), it gives you a lot of power at a very reasonable complexity tradeoff.

I agree with you and I think the heart of this is that smart development teams that have been around the block are looking for tools and approaches that provide a roughly flat curve of productivity over time. A downward curve would be great but flat is acceptable. Naive development shops look for tools that focus on the time it takes to get something up and running. Many of these tools have a sharp upward curve which is unsustainable. Personally I think DSLs could really be useful although I don't believe that non-developers can use them safely without oversight. What I really don't like about MPS is the lack of text-based source. I've been burned multiple times by such tools in the past. The argument is that you can't do this in an unambiguous way because nested unambiguous DSLs may not be unambiguous. First, I don't see much value in nesting DSLs. It actually seems like a really bad idea to me. Secondly, since MPS is persisted internally using XML, it's obviously serializable to text (just not a very appealing form.) I have a hard time buying into an argument that's internally inconsistent. I used to have a boss who would tell our clients that things could not be done when really, he just didn't want to do them. In any event, the level of vendor lock-in with this tool seems pretty risky.

Nice point, nicely made. +1

We created a DSL for cross-field validation rules for a Customs application. It's based on XPath plus some simple syntax for adding rule identification, field binding, and error messages. A rule expressed in 2-3 lines of English is implemented in 2-3 lines of XPath. Compare that to 60 lines of Java implementation. Plus the same rules are used for offline and GUI validation, which would be very hard with Java. This has been vital for our project: when you have 150 rules to implement and they change weekly, believe me you don't want to deal with that many Java files. The argument that a single language makes maintenance easier is not valid, if that language forces you to spend 20-30x more time/effort. The argument "we haven't actually seen domain experts using DSLs" is not valid either: if it increases the productivity of developers (and allows non-developers and juniors to be productive), it's a good thing.