DSL Construction rith Ruby

5,150
-1

Published on

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.

Published in: Technology
3 Comments
19 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,150
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
188
Comments
3
Likes
19
Embeds 0
No embeds

No notes for slide

DSL Construction rith Ruby

  1. 1. goals •  DSL Fundamentals •  Some Ruby Basics •  DSL construction with Ruby •  Advanced Topics - A step further •  Summary •  Q&A
  2. 2. problem? Problem Customer reduce the gap Programmer Solution
  3. 3. 01000001
  4. 4. evolution Problem ? Object Oriented C++ Java expressive GAP Procedural C Assembly Emergence of language 100101010 Solution
  5. 5. 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
  6. 6. evolution Problem DSL Object Oriented C++ Java expressive GAP Procedural C Assembly Emergence of language 100101010 Solution
  7. 7. example Monit – automatic management and monitoring - http://mmonit.com/
  8. 8. definition a computer programming language of limited expressiveness focused on a particular domain - Martin Fowler Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
  9. 9. definition a computer programming language of limited expressiveness focused on a particular domain - Martin Fowler Martin Fowlers book on DSLs - http://martinfowler.com/dslwip/
  10. 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. 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. 12. Domain Specific Languages vs. General Purpose Languages
  13. 13. what DSLs bring to the table •  Quality •  Productivity •  Reliability •  Maintainability •  Reusability
  14. 14. what DSLs bring to the table •  Quality •  Productivity •  Reliability •  Maintainability •  Reusability •  Social impact
  15. 15. what DSLs bring to the table •  Quality •  Productivity •  Reliability •  Maintainability •  Reusability •  Social impact •  Validation at the domain level
  16. 16. no silver bullet!
  17. 17. no silver bullet! •  Learning curve
  18. 18. no silver bullet! •  Learning curve •  Good language design is hard
  19. 19. no silver bullet! •  Learning curve •  Good language design is hard •  Cost of building
  20. 20. no silver bullet! •  Learning curve •  Good language design is hard •  Cost of building •  Limited applicability
  21. 21. no silver bullet! •  Learning curve •  Good language design is hard •  Cost of building •  Limited applicability •  Maintenance
  22. 22. no silver bullet! •  Learning curve •  Good language design is hard •  Cost of building •  Limited applicability •  Maintenance •  Could be overused or abused
  23. 23. Types of DSL
  24. 24. external DSL Need to build a parser to process the custom syntax sql, make files, xml config files, regular expressions
  25. 25. advantages •  Free to use any syntax
  26. 26. advantages •  Free to use any syntax •  Run time evaluation
  27. 27. disadvantages •  Starts simple, can get ugly and complex
  28. 28. disadvantages •  Starts simple, can get ugly and complex •  Building parsers is difficult
  29. 29. disadvantages •  Starts simple, can get ugly and complex •  Building parsers is difficult •  Lack of tooling support
  30. 30. internal DSL Extends the host language
  31. 31. advantages •  Don't have to write and debug a new language
  32. 32. advantages •  Don't have to write and debug a new language •  Full power of base language is available
  33. 33. advantages •  Don't have to write and debug a new language •  Full power of base language is available •  Tooling support available
  34. 34. disadvantages •  constrained by the host language.
  35. 35. Ruby based DSLs are internal
  36. 36. DSLs - not special to Ruby
  37. 37. Ruby is special
  38. 38. why is ruby special •  minimally intrusive Syntax to allow for more concise code
  39. 39. why is ruby special •  minimally intrusive Syntax to allow for more concise code •  Ruby culture - values expressiveness in code
  40. 40. why is ruby special •  minimally intrusive Syntax to allow for more concise code •  Ruby culture - values expressiveness in code •  Dynamic and Reflective
  41. 41. * Working code writing using RSpec, a testing frame work
  42. 42. DSL goodness
  43. 43. OPTIONAL PUNCTUATION concise code
  44. 44. vs.
  45. 45. SYMBOLS less noisy than strings
  46. 46. or
  47. 47. BLOCKS delayed evaluation of code
  48. 48. OPEN CLASSES build your language
  49. 49. some code here
  50. 50. METAPROGRAMMING expand your mind
  51. 51. define_method eval alias_method module_eval class_eval instance_eval
  52. 52. ‘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
  53. 53. language constructs year hour month sunday day reboot monday weekend a.m weekday p.m
  54. 54. 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
  55. 55. 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
  56. 56. Writing DSLs in Ruby THE PROCESS
  57. 57. Application Programming Interface Example 1 try { Socket client = new Socket(“www.google.com”,80); } catch(IOException e) { System.out.println(e); }
  58. 58. 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 ]
  59. 59. 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
  60. 60. 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
  61. 61. Patterns Interfaces Abstractions DSL “But, I believe a DSL is a healthy bi-product of a good object-oriented design.” Blaine Buxton (Smalltalk developer)
  62. 62. 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
  63. 63. Capture vocabulary •  Task scheduling is the domain of ‘cron’ •  Tasks •  Timing •  Frequency
  64. 64. 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)
  65. 65. 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.
  66. 66. 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
  67. 67. 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’
  68. 68. 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
  69. 69. Writing ‘Whenever’ every 2.days, :at => '4:30 am‘ do runner “/usr/bin/reboot” end
  70. 70. 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
  71. 71. Writing ‘Whenever’ 2.days() Class JobList def every(frequency, option={}) … yield #handles block end { :at => ‘4.30.am ‘ } def runner(task, options={}) … end end
  72. 72. Real examples A TALE OF TWO DSLS
  73. 73. EXAMPLE 1: DSL FOR GMRT
  74. 74. Giant Metrewave Radio Telescope System 30 Antennae http://gmrt.ncra.tifr.res.in
  75. 75. 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
  76. 76. ‘Teleset’ as DSL: Version 1.0 a1 = AntennaClient.new (“http://antenna1”) a1.reboot a1.monitor 2.mhz Single antenna
  77. 77. ‘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
  78. 78. ‘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
  79. 79. EXAMPLE 2: DSL FOR VISUALIZATION
  80. 80. 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
  81. 81. application ‘ThoughtWorks MCS Demo’ do add grid ‘Actors list’ do data_source table do table_name ‘actor’ end # data_source end # grid end # application
  82. 82. 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
  83. 83. Advanced topics A STEP FURTHER
  84. 84. Evolution of a DSL •  Generalization versus specialization •  “expressiveness x scope = constant” [3] expressiveness External Internal DSL DSL DSLs scope scope ASM GPL GPL expressiveness
  85. 85. Three aspects Domain Domain-specific aspect Language Language Specification aspect aspect
  86. 86. 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
  87. 87. 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
  88. 88. 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
  89. 89. Evolution of a DSL Specialization (inheritance) Reusability Conditions and loops Entities (+ relationships) Entities (numbers + strings)
  90. 90. 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
  91. 91. Future of DSLs •  UML and DSL •  DSL as front-end to UML (or alternative)[5] Book “MDA Distilled” (page 16)
  92. 92. Future of DSLs •  UML and DSL •  DSL as front-end to UML (or alternative)[5] •  High assurance systems •  Minimal code, relevant code
  93. 93. 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
  94. 94. 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
  95. 95. Language Design Library Design is is Library Design Language Design Bjarne Stroustrup [1]
  96. 96. Contacts iamharshal@yahoo.com rohan.kini@gmail.com

×