From APIDesign

Revision as of 07:43, 28 May 2010

Domain Specific Languages will be topic of User:RichUnger and User:JaroslavTulach JavaOne 2010 shootout.

Overview

What is a DSL?

A programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. --wikipedia

DSL examples

• LOGO (a language for children?), like Karel?
• SQL, HQL
• regex
• ZIL (Zork Implementation Language)
• Graphics rendering (POVray, Postscript)
• Building, dependency management (Makefiles)
• Document formatting (TeX, CSS)
• BNF Grammars (YACC, Antlr)
• XML variants (Ant, VoiceXML, XSLT, SVG, Docbook) Note: XML variants count as DSLs, and are a valid option if

• You want to code the parser very quickly
• Human readability and performance are not major concerns
• Or the format is close to HTML, like in case of Docbook.

Does this mean that XML a meta DSL language then? A language to help creation of DSLs without writing a parser? What other languages like this we can find and where is the boundary? For example sometimes, when using a library written in some highlevel language like Scala, Haskel, Clean, then I feel like using some other, completely different language. To give a BNF grammar example, compare for example Haskell Parser Combinators]. Of course you are bound by the underlaying language (but the same applies to XML), but the program code itself is quite close to BNF and gets processed automatically without writing anything special. Conclusion? Good language (Haskel) and good library (the parser generators for example), gives you same comfort more easily.

When is it good to use a DSL?

When you're targeting domain experts, not java programmers

• ZIL: lets authors program whole games
• TeX: used in academia across many disciplines
• Excel formulas: non-programmers do amazing things with excel

Note: This is a sliding scale. The more you limit your domain, the wider an audience you can target. Apex is almost a full language, but we have many users who would be far too intimidated to write their app in Java.

When you can do validation or eliminate boilerplate based on domain assumptions

For example, in Apex...

• No DB connections, pools, etc
• Static type checking for domain objects

 Account[] myaccounts = [select firstname, lastname from Contact]; // compile error

• Bring in complex set of data visibility rules specified by the admin in the UI

 public class Foo with sharing { ... }

• Create a SOAP endpoint with no extra configuration or code

 webservice String getSomething(integer someParam) { ... }

Note: Yes, you can use an annotation to create something similar to the webservice keyword. However, as a keyword it is more expressive. It is a type of visibility, just like public and private. Public means visible to other code on that server. Webservice means visible to other code on other servers. To say:

 @webservice public foo();

...would be using annotations to present a syntax that is as wrong as:

 @public private foo();

When domain lends itself to an idiom that can be clearly expressed in the syntax

• BNF syntax

 expression: unaryExpression | binaryExpression | constant;
 binaryExpression : expression binaryOp expression;
 binaryOp : '+' | '-' | '*' | '/';

• LOGO

 FORWARD 100 ; draws a square with sides 100 units long
 LEFT 90
 FORWARD 100
 LEFT 90
 FORWARD 100
 LEFT 90
 FORWARD 100
 LEFT 90

Developer Experience

Clarity of syntax

With DSLs you can bake pertinent concepts right into the language:

 public class Foo with sharing { ... }

TBD: Rich, can you explain what with sharing means?

Accessing Database

Is it easier in DSL to access database structure, than in Java? I would expect so, I would expect that DSL can make it easy easy as Ruby on Rails or Grails - e.g. you just access object representing the database and all columns are accessible as fields. As soon as you change the database schema, new field will immediately be visible. This could be hard to simulate when writing Java libraries, or not?

Learning Curve

If you're targeting java programmers, a large set of assumptions that go with an API are well understood.

Even so, if the technology you're presenting represents a foreign paradigm to your audience, it's often easier to convey that paradigm as a DSL.

Also, if the paradigm doesn't lend itself to object orientation (e.g. relational data). SQL isn't going away anytime soon, despite very concerted efforts over the past 10 years.

Vendor Perspective (That's You)

Providing Tooling

With APIs you get the standard tooling for free, which is great, IF:

• You are targeting java programmers
• You cannot afford the modest investment necessary to support a DSL in a major IDE
  • NetBeans, Eclipse, IntelliJ all have pretty straightforward ways to support at least minimal code completion and syntax coloring of DSLs
  • Language workbenches and RCP platforms are lowering barrier to entry for language tooling

Time to Market

• Java API, XML-based DSL: about the same
• DSL with custom syntax: a bit longer

Evolution (Versioning, Deprecation)

There are strict rules for evolution of Java API. The Chapter 6 touches on this topic slightly, moving methods up and down the class hierarchy, adding methods, etc. When doing library design, you need to adjust to the Java (or other framework) rules. When writing a DSL you are basically creating your own rules, aren't you Rich?

It took me few years to understand the Java rules, how long it takes to specify own? There are tools which help you discover backward incompatibilities in Java like Sigtest. This all needs to be written from a scratch for DSL (btw. we would need something like that for Ant - as Ant XML build scripts supports overrides, inheritance, etc. - nothing like that is available, nobody will likely bother to write anything like that and rather we will rely on visual inspection and early testers to report bugs).

TBD...