DEV Community

Cover image for Write DSLs and Code Faster

Write DSLs and Code Faster

Barry O Sullivan on January 23, 2018

(Originally published on my blog.) What is a DSL DSL stands for Domain Specific language, this means that it is a language that is de...
Read full post
Collapse
 
rafalpienkowski profile image
Rafal Pienkowski •

First of all very nice article.

I've implemented a DSL language during my studies. It was generating forms by an application written in Python+Django. DSL (as its name shows) is domain specific and it was easy to use by non-technical people. It was the main part of the project. I still remember how many work cost to define DSL and write a parser to it which has made the right job. BTW the parser was a big pain in the neck.

With my small experience with custom DSL, for the case, you had described, I personally would like to use a builder with fluent methods. In my opinion, it's simpler to set up a builder than define a DSL. An entry threshold is smaller than in DSL scenario. Additionally, this would be fully supported by any IDE. For instance, available methods will be prompted.

An example of usage could look like (I've used C# syntax):

var userScheduleAppointment  = new UserScheduleAppointmentBuilder()
   .WithUserId(userId)
   .WithAppointmentDateTime(apointmentDateTime)
   .WithLocation(location)
   .Build();
Enter fullscreen mode Exit fullscreen mode

It's even possible to remove the last Build() when we declare explicitly expected result type. This is one of the advantages strongly typed languages like C# :)

What do you think about this approach?

Collapse
 
barryosull profile image
Barry O Sullivan •

Glad you enjoyed the article, and thank you for the feedback.

I've done both ways, written a DSL parser/interpreter and written a fluent interface. You're right about parsers, they can be a huge pain in the neck, especially if you're writing one yourself from scratch.

I like you're suggestion above, a fluent/builder makes a lot of sense. It's not that complex a language so implementing it as a class structure is fairly simple. As you mentioned, IDE auto completion is another big win. Martin Fowler calls these internal DSLs, and it's usually the first step in creating a DSL (and maybe the last step, if it works it works).

In the next article, I'm going to show how a parser for the above can be implemented using a PEG (pegjs.org/ to be precise), ie. an external DSL. However, that's just to showcase the concept. In reality I would implement this language as you suggested.

I think that external DSLs would gain more traction if we could get better IDE support, make it easier to design the language and plug a parser into the IDE itself. Until then they're always going to be clunkier and harder to write.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski • • Edited

Thanks for your answer.

I'll follow your DSL thread and I'll read your article about parser. I was very interested in this subject a few years ago but it was a very hard to find an interlocutor to talk with him/her about DSLs.

Once again great article and I'm glad that you've brought up DSL subject.

Collapse
 
prestongarno profile image
Preston • • Edited

Kotlin has full support for type-safe DSLs from native code, they're easy to write combining applicatives with infix notation:

schemaProvider { kdelegateContext ->
  newBuilder<T>().withArgs<A>() takingArguments ::Always resultingIn { (args, builder) ->
     EnumAdapterImpl(clazz, args, builder.default).toDelegate(kdelegateContext)
  }
}.withAlternate { it allowing Nothing::class }
Collapse
 
barryosull profile image
Barry O Sullivan •

I'll need to look into Kotlin, it looks quite concise, though it's not a syntax style I'm used to.

Collapse
 
remojansen profile image
Remo H. Jansen •

If you are considering writing your own DSL from scratch, Xtext is a good option.

With Xtext you define your language using a powerful grammar language. As a result you get a full infrastructure, including parser, linker, typechecker, compiler as well as editing support for Eclipse, any editor that supports the Language Server Protocol and your favorite web browser.

More info at eclipse.org/Xtext/

However, I do prefer the fluent approach in most cases.

Collapse
 
barryosull profile image
Barry O Sullivan •

Wow, that is very cool. The editing support looks amazing. I will definitely look into that.

Collapse
 
bohdanstupak1 profile image
Bohdan Stupak •

I'll just leave it here for the sake of your amusement