The document discusses domain-specific languages (DSLs) and their advantages, such as improved quality, productivity, and maintainability, while also addressing drawbacks like the learning curve and maintenance issues. It contrasts external and internal DSLs, emphasizing Ruby's unique features that facilitate DSL construction. Additionally, it presents real-world examples of DSLs, highlighting their evolution and future potential in software design.

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

3. problem?
Problem
Solution
reduce the gap
Customer
Programmer

4. 01000001

6. evolution
expressive
?
Object Oriented
Procedural
Assembly
100101010
Emergence of
language
C
C++ Java
Problem
GAP
Solution

7. • 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
the power of language

8. evolution
expressive
DSL
Object Oriented
Procedural
Assembly
100101010
Emergence of
language
C
C++ Java
Problem
GAP
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
module_eval
class_eval
instance_eval
alias_method

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
hour
day
month
year
reboot
weekend
weekday
sunday
monday
a.m
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. THE PROCESS
Writing DSLs in Ruby

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

66. Application Programming Interface
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
Customer.find :all, :condition => [ :age >= 25 ]
Example 1
Example 2

67. Application Programming Interface
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
Customer.find :all, :condition => [ :age >= 25 ]
• Libraries give a sense of domain-specificity because
of vocabulary
• Nouns / verbs / adverbs / adjectives
Example 1
Example 2

68. Application Programming Interface
try {
Socket client = new Socket(“www.google.com”,80);
} catch(IOException e) {
System.out.println(e);
}
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
Example 1
Example 2

69. DSL
Abstractions
Interfaces
Patterns
“But, I believe a DSL is a healthy bi-product
of a good object-oriented design.”
Blaine Buxton (Smalltalk developer)

70. Capture vocabulary and processes
of the domain
Discover desired syntax
Define DSL interface (API)
Define classes and abstractions
Implement validations
Internal DSLs – A coarse process

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
monday
hourly
day
month
year
reboot
weekend
weekday
sunday
a.m.
p.m.
runner
at
every
annually

74. Discover syntax
Discuss
with
DSL user
Experiment
around
keywords
Design a
syntax
Define
constructs
Define
ownership
of keywords
Write
extended
methods
(e.g.
2.days)

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. Using Ruby
features to realize
DSL constructs
Purpose
(what)
Getter/setter
Pattern matching
Alternative interfaces
Context
Code generation
Execution
Arbitrary interfaces/
attributes
Ruby feature
(how)
Function calls w/o
parentheses
Regular expressions
‘alias_method’
Closure/block
Strings
‘load’, ‘require’, ‘eval’
‘method_missing’

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’
Class JobList
def every(frequency, option={})
…
yield #handles block
end
def runner(task, options={})
…
end
end
2.days()
{ :at => ‘4.30.am ‘ }

80. A TALE OF TWO DSLS
Real examples

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
a1 = AntennaClient.new (“http://antenna1”)
a1.reboot
a1.monitor 2.mhz
Simultaneously,
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
Complex !!!
Single antenna
http://openwferu.rubyforge.org - Using OpenWFEru Workflow engine

86. ‘Teleset’ as DSL : Version 2.0
with antenna :a1, :a2 do
reboot
monitor 2.mhz
end
Much
simpler !
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
Suggested prototype

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. A STEP FURTHER
Advanced topics

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

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

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

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

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

100. Evolution of a DSL
Entities
(numbers
+ strings)
Entities (+
relationships)
Conditions and
loops
Reusability
Specialization
(inheritance)

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
is
Library Design
Library Design
is
Language Design
Bjarne Stroustrup[1]

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