Domain Specific Language
From APIDesign
(→Accessing Database) |
|||
Line 1: | Line 1: | ||
[[wikipedia::Domain Specific Language|Domain Specific Language]]s will be topic of [[User:RichUnger]] and [[User:JaroslavTulach]] JavaOne 2010 shootout. | [[wikipedia::Domain Specific Language|Domain Specific Language]]s will be topic of [[User:RichUnger]] and [[User:JaroslavTulach]] JavaOne 2010 shootout. | ||
- | = | + | = Overview = |
- | ==== Accessing Database | + | ===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= Vendor Experience (That's You) = | ||
+ | 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) { ... } | ||
+ | |||
+ | ====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? | 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... |
Revision as of 17:03, 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= Vendor Experience (That's You) =
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) { ... }
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...