DSLs: what, why, how?
What is a DSL?
DSL computer programming language
limited expressiveness
particular domain
used by humans to instruct a computer
bare minimum of features
entire system can’t be built in a DSL
sense of fluency
domain focus makes a limited language worthwhile
executable by a computer
language nature
Internal vs. external DSLs
internal DSL
external DSL
a particular way to use a GPL
embedded into GPL
script in internal DSL valid code in its host GPL
only uses a subset of GPL’s features
has a feel of custom language rather than its host language
Ruby on Rails often seen as a collection of DSLs
a separate language has custom syntax
script in external DSL parsed using text parsing techniques
Unix little languages
Graph g =
graph("example1")
.directed()
.with(
node("a")
.link(
node("b")
)
);
Command-query APIs
methods on an object
command
query
commands queries
returns a value
does not change the state of the system
may change state of the system
should not return a value
doesn’t have side effects
can be called multiple times in any order without changing the results
does have side effects
should make sense in stand-alone contextnames of methods
obj.getName()
obj.removeAt(1)
obj.toString()
obj.setName(’a’)
Command-query APIs Vaadin Framework
domain rich Internet applications
import com.vaadin.server.VaadinRequest;
import com.vaadin.ui.Label;
import com.vaadin.ui.UI;
@Title("My UI")
public class HelloWorld extends UI {
@Override
protected void init(VaadinRequest request) {
// Create the content root layout for the UI
VerticalLayout content = new VerticalLayout();
setContent(content);
// Display the greeting
content.addComponent(new Label("Hello World!"));
// Have a clickable button
content.addComponent(new Button("Push Me!",
click -> Notification.show("Pushed!")));
}
} semantic model
http://vaadin.com
Vaadin-based language
HelloWorld {
Component content = VerticalLayout {
Component myLabel = Label {
String Label caption = “Hello world!”;
}
Component myButton = Button {
String Button caption = “Push Me!”;
Function changeCaption = () {
caption = “Pushed!”;
} listens to click;
}
}
}
HelloWorld {
VerticalLayout {
Label “Hello world!”;
Button “Push Me!” {
when click: caption = “Pushed”;
}
}
}
TouchScript (H. Westergård, 2013)
layout vertically:
label “Hello world!”
button “Push Me!” as myButton
events for myButton:
click { caption = “Pushed”; }
“Hello world!”
[“Push Me!”]
when click on [“Push Me!”] -> [“Pushed”]
numerous options on how to define a DSL
[ ] – represent a button
no names for components
“transformation operator”
similar to REBOL syntaxview layout [text "Hello world!" button "Quit" [quit]]
Why use a DSL?
tool with limited focusDSL
very specific tool for very particular conditions
typical project uses a dozen of DSLs
improving development productivity
communication with domain experts
change in execution context
alternative computation model
shift logic from compile time to runtime
The Why: development productivity
communicate intent of a part of a system
easier to understand DSLDSL vs. command-query API
aestheticsnot only code is easier to read
easier to find mistakes
easier to modify the system
limited expressiveness harder to express wrong things
DSL to wrap awkward third-party library
The Why: domain experts
domain experts
read code
write code
understand what the system thinks it’s doing
spot mistakes
talk more effectively to programmers
focus on reading code not writing
DSL shouldn’t necessarily be implemented useful to describe the system
communication issues
involving domain experts is difficult but has a high payoff
The Why: alternative computation model
mainstream programming imperative what to do and in what sequence
conditionals loopscontrol flow
declarative what should happen rather than how it should happen
state machine
decision table
Problems with DSLs (1)
language “hell”
cost of building
languages are hard to learn
far easier to learnDSL simpler than GPL
people aren’t used to building DSLs
cost of a DSL model
help think about the model reduce cost of building itDSL
too many DSLs bad DSLs
good DSL wrap a bad library
make it easier to deal with
waste of resources to maintain
cost over the cost of
Problems with DSLs (2)
ghetto language
limited
abstraction
the whole system built in a language it’s a GPL!
DSL GPLmight evolve into a
DSL should be focused on a narrow problem
ideally no features that fall outside that
DSL provides abstraction to think about subject area
behavior of the domain expressed easier
than using lower-level constructs
the world is fit into abstraction instead of the other way around
DSL something evolving unfinished

DSLs: what, why, how

  • 1.
  • 2.
    What is aDSL? DSL computer programming language limited expressiveness particular domain used by humans to instruct a computer bare minimum of features entire system can’t be built in a DSL sense of fluency domain focus makes a limited language worthwhile executable by a computer language nature
  • 3.
    Internal vs. externalDSLs internal DSL external DSL a particular way to use a GPL embedded into GPL script in internal DSL valid code in its host GPL only uses a subset of GPL’s features has a feel of custom language rather than its host language Ruby on Rails often seen as a collection of DSLs a separate language has custom syntax script in external DSL parsed using text parsing techniques Unix little languages Graph g = graph("example1") .directed() .with( node("a") .link( node("b") ) );
  • 4.
    Command-query APIs methods onan object command query commands queries returns a value does not change the state of the system may change state of the system should not return a value doesn’t have side effects can be called multiple times in any order without changing the results does have side effects should make sense in stand-alone contextnames of methods obj.getName() obj.removeAt(1) obj.toString() obj.setName(’a’)
  • 5.
    Command-query APIs VaadinFramework domain rich Internet applications import com.vaadin.server.VaadinRequest; import com.vaadin.ui.Label; import com.vaadin.ui.UI; @Title("My UI") public class HelloWorld extends UI { @Override protected void init(VaadinRequest request) { // Create the content root layout for the UI VerticalLayout content = new VerticalLayout(); setContent(content); // Display the greeting content.addComponent(new Label("Hello World!")); // Have a clickable button content.addComponent(new Button("Push Me!", click -> Notification.show("Pushed!"))); } } semantic model http://vaadin.com
  • 6.
    Vaadin-based language HelloWorld { Componentcontent = VerticalLayout { Component myLabel = Label { String Label caption = “Hello world!”; } Component myButton = Button { String Button caption = “Push Me!”; Function changeCaption = () { caption = “Pushed!”; } listens to click; } } } HelloWorld { VerticalLayout { Label “Hello world!”; Button “Push Me!” { when click: caption = “Pushed”; } } } TouchScript (H. Westergård, 2013) layout vertically: label “Hello world!” button “Push Me!” as myButton events for myButton: click { caption = “Pushed”; } “Hello world!” [“Push Me!”] when click on [“Push Me!”] -> [“Pushed”] numerous options on how to define a DSL [ ] – represent a button no names for components “transformation operator” similar to REBOL syntaxview layout [text "Hello world!" button "Quit" [quit]]
  • 7.
    Why use aDSL? tool with limited focusDSL very specific tool for very particular conditions typical project uses a dozen of DSLs improving development productivity communication with domain experts change in execution context alternative computation model shift logic from compile time to runtime
  • 8.
    The Why: developmentproductivity communicate intent of a part of a system easier to understand DSLDSL vs. command-query API aestheticsnot only code is easier to read easier to find mistakes easier to modify the system limited expressiveness harder to express wrong things DSL to wrap awkward third-party library
  • 9.
    The Why: domainexperts domain experts read code write code understand what the system thinks it’s doing spot mistakes talk more effectively to programmers focus on reading code not writing DSL shouldn’t necessarily be implemented useful to describe the system communication issues involving domain experts is difficult but has a high payoff
  • 10.
    The Why: alternativecomputation model mainstream programming imperative what to do and in what sequence conditionals loopscontrol flow declarative what should happen rather than how it should happen state machine decision table
  • 11.
    Problems with DSLs(1) language “hell” cost of building languages are hard to learn far easier to learnDSL simpler than GPL people aren’t used to building DSLs cost of a DSL model help think about the model reduce cost of building itDSL too many DSLs bad DSLs good DSL wrap a bad library make it easier to deal with waste of resources to maintain cost over the cost of
  • 12.
    Problems with DSLs(2) ghetto language limited abstraction the whole system built in a language it’s a GPL! DSL GPLmight evolve into a DSL should be focused on a narrow problem ideally no features that fall outside that DSL provides abstraction to think about subject area behavior of the domain expressed easier than using lower-level constructs the world is fit into abstraction instead of the other way around DSL something evolving unfinished