Domain Specific Language

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 40: Line 40:
* Create a SOAP endpoint with no extra configuration or code
* Create a SOAP endpoint with no extra configuration or code
webservice String getSomething(integer someParam) { ... }
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====
====When domain lends itself to an idiom that can be clearly expressed in the syntax====

Revision as of 17:09, 22 May 2010

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

Contents

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
  • 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)

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

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

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?

Clarity of syntax

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

 public class Foo with sharing { ... }

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)

TBD...

Retrieved from "http://wiki.apidesign.org/wiki/Domain_Specific_Language"
Personal tools
buy