An Interview with Debasish Ghosh, author of DSLs in Action
Join the DZone community and get the full member experience.Join For Free
if you are dabbling with domain specific languages, especially on the jvm, then read on. i recently had the opportunity to pose a few questions to debasish ghosh. debasish ghosh is the chief technology evangelist at anshinsoft , where he specializes in leading delivery of enterprise-scale solutions for clients ranging from small to fortune 500 companies. his research interests are functional programming, domain-specific languages, and nosql databases. is a senior member of the acm and author of the book dsls in action , to be published this year by manning . you can read his really insightful programming blog at http://debasishg.blogspot.com .
manning also has kindly made a free chapter available from the book too. thanks manning!
get 40% off the dsls in action ebook, pbook, or meap. use the special dzone coupon code dzone40 .
domain specific languages is a quite a
trending topic in recent months (maybe years). what was your main
objective for writing the book?
debasish ghosh: the multitude of languages that we see today on the jvm has created a niche ecosystem for expressive programming. by expressive programming, i mean architecting the solution domain of your problem in such a way that even business users can understand and verify many of the domain logic that programmers write. this paradigm of development can have a huge impact on the way we write and deliver software today. i have been working on this model of development for some time now. i wanted to share this thought and some of my experience in building real world dsl based solutions with all developers out there.
aslam: in your book, you work with several general purpose languages for creating dsls. what should we look for in a language that makes that language a good candidate for creating internal dsls?
debasish: internal dsl is almost not differentiable from expressive apis. in my book i have emphasized on this idea that a well designed api that models the ubiquitous language of the domain is an internal dsl. you can have internal dsls designed in any language – the amount of expressivity will vary with the features that it offers. languages that offer functional programming idioms are more natural for designing expressive internal dsls because functions compose more naturally than objects. additionally some languages like scala offer higher order abstractions like parser combinators as a library that make a great tool for developing external dsls. dsls in action discusses all these in much gory details along with real world examples from a particular domain.
aslam: so we build a dsl, and write lots of small pieces of code with the dsl. then we discover that we need to enhance the dsl. can you share any tips, techniques or thoughts on how to deal with changes in dsl so we don't break (a lot) of the old dsl code base.
debasish: dsl is like any piece of software. it will evolve over time and you need to architect your system so that it can adapt to changes in the dsl. just like you model associations between objects non-intrusively that continue to work even when you change one of them, you do the same with dsls. whenever you compose multiple dsls or compose a piece of dsl with your core application, ensure that you follow the principles that lead to well designed abstractions. the general principles are the same –
• never expose implementations between composed dsls
• allow the composition to be based on published protocols and interfaces,
• use combinators and higher order abstractions instead of lower level structures like recursion etc.
aslam: how important is syntax sugaring in a dsl and how more complexity (if at all) is introduced as a result of building in sugaring?
debasish: my philosophy is not to go overboard with syntax sugaring. it complicates implementation unnecessarily, makes error handling difficult and may also confuse users. introduce only sufficient syntax to your users which make the domain vocabulary explicit. one common meme that goes around with dsls and syntax sugaring is that with enough syntax sugars, non-programming business users can do programming. i don't subscribe to this school of thought. a dsl is designed so that it's sufficiently expressive to the business users. the primary purpose is to make the business rules explicit, so that a business user can read and them, thereby improving the communication between the development team and the user base. this has been an underlying thought throughout the book.
aslam: tooling - should dsl creators be building tooling to help others that will be programming with their dsl? does it make a difference if it is an internal or external dsl?
debasish: eclispe xtext is an excellent tooling platform for developing external dsls. i have a detailed example in the book on how you can control the complete lifecycle of your dsl using xtext. but tooling is an area in dsl development that's going to evolve a lot in the years to come. for internal dsls, we are going to see languages that offer higher order abstractions that help you express your intent more succinctly. for external dsls, we have already started looking at various workbench tools that promises to take development of external dsls at the very next level.
aslam: what are some of the holes that developers can fall into when building their very first dsl?
debasish: i always suggest an iterative approach to dsl design. it's no different from api design. as with any api design, work collaboratively with your users to iron out the syntax of your dsl. i have also seen instances where developers have fallen into the trap of trying to provide too much sugar to the syntax of a dsl. this can only result in brittle implementations and non intuitive error reporting.
a dsl has two parts – a thin veneer of linguistic abstraction (the surface syntax) for the users of the dsl, which sits on top of a semantic model of your domain. the semantic model is for the dsl implementers and needs to be treated with enough care to ensure that it is well designed as well. the syntax cannot stand on its own – make the semantic model of the dsl expressive as well so that all business rule implementations are equally well published to developers.
aslam: in your opinion, are we seeing dsl and polyglot approach to development becoming mainstream? if not, what will it take for it to become mainstream?
debasish: every new paradigm starts as a nascent movement. even today we see lots of projects using groovy as a dsl with mainstream java applications. i have used scala based dsls to pimp my java classes to give the users domain friendly apis. all of us use bdd frameworks like specs for scala, rspec and cucumber for ruby, easyb for groovy. and most of these testing frameworks can be deployed irrespective of the jvm language that you use for developing the core application. so, it's not the question of becoming mainstream – we are already using lots of dsls in our everyday programming. remember the big bang infamous xml for defining spring beans? today we are using the nice syntax of groovy for the bean builder definitions in grails. clojure is a language that itself is a dsl. you don’t have to do anything extra to make a dsl out of clojure. just write idiomatic clojure and you have a dsl.
debasish, thank you for taking the time to share your thoughts with
with us, and thanks for the huge effort in putting down all your
knowledge and experience into your book.
Opinions expressed by DZone contributors are their own.