Simplicity, ease of use, clean syntax and clear semantics are the characteristics of a good DSL that enable the users to focus on the problem. It is non-trivial to define, develop and maintain a DSL, especially using traditional compiler techniques. The Ruby programming language solves this issue to a certain extent.
Topics Covered
* Fundamentals of DSLs.
* Introduction of Ruby features for writing DSLs.
* Writing a DSL - The speakers' experience, with examples.
* Challenges and Issues.
Speaker Profiles:
Harshal Hayatnagarkar is a researcher at Tata Research Development and Design Centre, Pune (a division of TCS) with many years of experience in writing large-scale trading systems, DSLs and high performance machine learning systems. Currently he is writing a DSL for information visualization using Ruby.
Rohan Kini: is a Senior Developer at ThoughtWorks. He has been working with Ruby since 2005 on one of the earliest Ruby projects in India. He specializes in development of large-scale, web-based applications and scripting languages.
6. evolution
Problem
?
Object Oriented C++ Java
expressive
GAP
Procedural C
Assembly Emergence of
language
100101010
Solution
7. the power of language
• Arm Ball
• Around the wicket
• Cow Corner
• Duck
• Fly Slip
• Googly
http://en.wikipedia.org/wiki/List_of_cricket_terms - an long list of cricket terms
8. evolution
Problem
DSL
Object Oriented C++ Java
expressive
GAP
Procedural C
Assembly Emergence of
language
100101010
Solution
10. definition
a computer programming language of limited
expressiveness focused on a particular
domain
- Martin Fowler
Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
11. definition
a computer programming language of
limited expressiveness focused on a
particular domain
- Martin Fowler
Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
12. definition
a computer programming language of
limited expressiveness focused on a
particular domain
- Martin Fowler
Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
13. definition
a computer programming language of
limited expressiveness focused on a
particular domain
- Martin Fowler
Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
15. what DSLs bring to the table
• Quality
• Productivity
• Reliability
• Maintainability
• Reusability
16. what DSLs bring to the table
• Quality
• Productivity
• Reliability
• Maintainability
• Reusability
• Social impact
17. what DSLs bring to the table
• Quality
• Productivity
• Reliability
• Maintainability
• Reusability
• Social impact
• Validation at the domain level
21. no silver bullet!
• Learning curve
• Good language design is hard
• Cost of building
22. no silver bullet!
• Learning curve
• Good language design is hard
• Cost of building
• Limited applicability
23. no silver bullet!
• Learning curve
• Good language design is hard
• Cost of building
• Limited applicability
• Maintenance
24. no silver bullet!
• Learning curve
• Good language design is hard
• Cost of building
• Limited applicability
• Maintenance
• Could be overused or abused
40. why is ruby special
• minimally intrusive Syntax to allow for more
concise code
41. why is ruby special
• minimally intrusive Syntax to allow for more
concise code
• Ruby culture - values expressiveness in
code
42. why is ruby special
• minimally intrusive Syntax to allow for more
concise code
• Ruby culture - values expressiveness in
code
• Dynamic and Reflective
43. * Working code writing using RSpec, a testing frame work
63. The fascinating thing is that, in my
experience, most well-written Ruby
programs are already a DSL, just by nature
of Ruby’s syntax.”
- Jamis Buck, 37signals
66. Application Programming Interface
Example 1
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
Example 2
Customer.find :all, :condition => [ :age >= 25 ]
67. Application Programming Interface
Example 1
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
Example 2
Customer.find :all, :condition => [ :age >= 25 ]
• Libraries give a sense of domain-specificity because
of vocabulary
• Nouns / verbs / adverbs / adjectives
68. Application Programming Interface
Example 1
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
Example 2
Customer.find :all, :condition => [ :age >= 25 ]
• Libraries give a sense of domain-specificity because
of vocabulary
• Nouns / verbs / adverbs / adjectives
• They are all internal DSLs
69. Patterns
Interfaces
Abstractions
DSL
“But, I believe a DSL is a healthy bi-product
of a good object-oriented design.”
Blaine Buxton (Smalltalk developer)
70. Internal DSLs – A coarse process
Capture vocabulary and processes
of the domain
Discover desired syntax
Define DSL interface (API)
Define classes and abstractions
Implement validations
71. Capture vocabulary
• Task scheduling is the domain of ‘cron’
• Tasks
• Timing
• Frequency
72. Capture vocabulary
• Task scheduling is the domain of ‘cron’
• Tasks (e.g. ‘reboot’, ‘send mail’, ‘alert’, etc)
• Timing (e.g. ‘5 pm’, ‘4.30 am’, etc)
• Frequency (e.g. ‘yearly’, ‘weekend’, etc)
73. Capture vocabulary
• Task scheduling is the domain of ‘cron’
• Tasks (e.g. ‘reboot’, ‘send mail’, ‘alert’, etc)
• Timing (e.g. ‘5 pm’, ‘4.30.am’, etc)
• Frequency (e.g. ‘yearly’, ‘weekend’, etc)
• Discover keywords
• Special words (‘yearly’, ‘reboot’, etc)
• Domain values (‘5 pm’, etc)
• A good design would decide ownership of these keywords
annually year at
hourly
month sunday
runner monday
day reboot
every a.m.
weekend
weekday p.m.
74. Discover syntax
Experiment
around
keywords
Write
extended
Design a
methods syntax
(e.g.
2.days) Discuss
with
DSL user
Define
Define
ownership
constructs
of keywords
75. Design considerations
• “Follow good design principles”
– Entities as classes
• As nouns
– Operations as methods
• Typically as verbs
• Adaptive interfaces (wrappers) to instantiate aggregations
• Accept hash as argument to simulate ‘call by name’
76. Purpose Ruby feature
(what) (how)
Function calls w/o
Getter/setter
parentheses
Pattern matching Regular expressions Using Ruby
features to realize
Alternative interfaces ‘alias_method’ DSL constructs
Context Closure/block
Code generation Strings
Execution ‘load’, ‘require’, ‘eval’
Arbitrary interfaces/
‘method_missing’
attributes
78. Writing ‘Whenever’
every 2.days, :at => '4:30 am‘ do
runner “/usr/bin/reboot”
end
every(2.days(),{:at => '4:30 am’}) do
runner(“/usr/bin/reboot”)
end
79. Writing ‘Whenever’
2.days()
Class JobList
def every(frequency, option={})
…
yield #handles block
end { :at => ‘4.30.am ‘ }
def runner(task, options={})
…
end
end
83. GMRT Prototype
• Objective
– Re-engineering ‘ABC’ and ‘Teleset’
– Collaboration among TCS, NCRA and CoEP
• Challenges
– Scientists need a simple, extensible interface to
• Monitor and control antennae
• Schedule experiments
• Approach
– ABC as collection of Rails web services
– Teleset re-designed as a Ruby DSL
84. ‘Teleset’ as DSL: Version 1.0
a1 = AntennaClient.new (“http://antenna1”)
a1.reboot
a1.monitor 2.mhz
Single antenna
85. ‘Teleset’ as DSL : Version 1.1
Single antenna a1 = AntennaClient.new (“http://antenna1”)
a1.reboot
a1.monitor 2.mhz
Simultaneously,
Complex !!!
for antennae
a1 and a2
engine.register_participant :antenna do | antenna |
reboot
monitor 2.mhz
end
concurrent_iterator on_value => [:a1,:a2], to_variable => ‘antenna’ do
participant :antenna => ’${antenna}’
end #Using openwferu engine
http://openwferu.rubyforge.org - Using OpenWFEru Workflow engine
86. ‘Teleset’ as DSL : Version 2.0
Suggested prototype
with antenna :a1, :a2 do
reboot
monitor 2.mhz Much
simpler !
end
engine.register_participant :antenna do | antenna |
reboot
monitor 2.mhz
end
concurrent_iterator on_value => [:a1,:a2], to_variable => ‘antenna’ do
participant :antenna => ’${antenna}’
end
88. DSL for visualization
• Objective
– A specification-driven dashboard
• Visualization metaphors (charts, data grids, etc)
• Organization using layouts (window, tab, portal, etc)
• Navigation (page flows)
• Challenge
– Consistent API
– Integration with other components and environment
• Ruby was chosen
89.
90.
91. application ‘ThoughtWorks MCS Demo’ do
add grid ‘Actors list’ do
data_source table do
table_name ‘actor’
end # data_source
end # grid
end # application
92. application ‘Thoughtworks MCS Demo’ do
add grid ‘Actors list’ do
data_source table do
table_name ‘actor’
end # data_source
add view ‘Show movies’ do | actor |
add grid “Movies for actor #{actor}” do
data_source query do
text “SELECT …
WHERE actor_id=#{actor.actor_id}”
end # data_source
end # grid
end # view
end # grid
end # application
100. Evolution of a DSL
Specialization
(inheritance)
Reusability
Conditions and
loops
Entities (+
relationships)
Entities
(numbers
+ strings)
101. Crossroads and crosswords
• “No domain is an island”
• Interoperability in DSLs
• DSLs need to talk one-another
• Achilles’ Heel for external DSLs
• Parallel development of different DSLs needs early
standardization
• Chicken-egg problem
102. Future of DSLs
• UML and DSL
• DSL as front-end to UML (or alternative)[5]
Book “MDA Distilled” (page 16)
103. Future of DSLs
• UML and DSL
• DSL as front-end to UML (or alternative)[5]
• High assurance systems
• Minimal code, relevant code
104. Future of DSLs
• UML and DSL
• DSL as front-end to UML (or alternative)[5]
• High assurance systems
• Minimal code, relevant code
• Multi-core revolution
• Multi-threading
• Message passing
The Free Lunch Is Over – Herb Sutter’s article on Multi-core Revolution
105. References and resources
1. Interview of Bjarne Stroustrup
2. Presentation by Martin Fowler (at InfoQ.com)
3. Domain-Specific Languages in Perspective
4. A Picture is Worth a 1000 Words?
5. Book “MDA Distilled” (page 16)
6. The Free Lunch Is Over
106. Language Design Library Design
is is
Library Design Language Design
Bjarne Stroustrup [1]