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.

2. goals
• DSL Fundamentals
• Some Ruby Basics
• DSL construction with Ruby
• Advanced Topics - A step further
• Summary
• Q&A

3. problem?
Problem
Customer
reduce the gap
Programmer
Solution

4. 01000001

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

9. example
Monit – automatic management and monitoring - http://mmonit.com/

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/

14. Domain Specific Languages
vs.
General Purpose
Languages

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

18. no silver bullet!

19. no silver bullet!
• Learning curve

20. no silver bullet!
• Learning curve
• Good language design is hard

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

25. Types of DSL

26. external DSL
Need to build a parser to process the custom
syntax
sql, make files, xml config files, regular
expressions

27. advantages
• Free to use any syntax

28. advantages
• Free to use any syntax
• Run time evaluation

29. disadvantages
• Starts simple, can get ugly and complex

30. disadvantages
• Starts simple, can get ugly and complex
• Building parsers is difficult

31. disadvantages
• Starts simple, can get ugly and complex
• Building parsers is difficult
• Lack of tooling support

32. internal DSL
Extends the host language

33. advantages
• Don't have to write and debug a new
language

34. advantages
• Don't have to write and debug a new
language
• Full power of base language is available

35. advantages
• Don't have to write and debug a new
language
• Full power of base language is available
• Tooling support available

36. disadvantages
• constrained by the host language.

37. Ruby based DSLs are
internal

38. DSLs - not special to Ruby

39. Ruby is special

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

44. DSL goodness

45. OPTIONAL PUNCTUATION
concise code

47. vs.

48. SYMBOLS
less noisy than strings

49. or

50. BLOCKS
delayed evaluation of code

52. OPEN CLASSES
build your language

54. some code here

58. METAPROGRAMMING
expand your mind

59. define_method
eval alias_method
module_eval
class_eval
instance_eval

60. ‘whenever’
a DSL for cron jobs
30 4 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 * * reboot
http://github.com/javan/whenever

61. language constructs
year
hour month sunday
day reboot monday
weekend a.m
weekday p.m

62. expressive
30 4 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 * * reboot
http://github.com/javan/whenever

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

64. Writing DSLs in Ruby
THE PROCESS

65. Application Programming Interface
Example 1
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}

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

77. Writing ‘Whenever’
every 2.days, :at => '4:30 am‘ do
runner “/usr/bin/reboot”
end

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

80. Real examples
A TALE OF TWO DSLS

81. EXAMPLE 1: DSL FOR GMRT

82. Giant Metrewave Radio Telescope
System
30
Antennae
http://gmrt.ncra.tifr.res.in

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

87. EXAMPLE 2: DSL FOR
VISUALIZATION

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

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

94. Advanced topics
A STEP FURTHER

95. Evolution of a DSL
• Generalization versus specialization
• “expressiveness x scope = constant” [3]
expressiveness
External Internal DSL
DSL DSLs
scope scope
ASM GPL
GPL
expressiveness

96. Three aspects
Domain
Domain-specific
aspect Language
Language Specification
aspect aspect

97. Three aspects
Domain Specification Language
• CRUD of • Conditionality (if/ • Natural
• Domain entities switch) • Syntactic noise
• Relationships • Automation • Semantic noise
• Processes (loops)
• Constraints • Reusability
(function/classes)
• Data structures
• Error handling

98. Three aspects
Domain Specification Language
• CRUD of • Conditionality (if/ • Natural
• Domain entities switch) • Syntactic noise
• Relationships • Automation • Semantic noise
• Processes (loops)
• Constraints • Reusability
(function/classes)
• Data structures
• Error handling

99. Three aspects
Domain Specification Language
• CRUD of • Conditionality (if/ • Natural
• Domain entities switch) • Syntactic noise
• Relationships • Automation • Semantic noise
• Processes (loops)
• Constraints • Reusability
(function/classes)
• Data structures
• Error handling

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]

107. Contacts
iamharshal@yahoo.com
rohan.kini@gmail.com