(Domain Specific Language, not Direct Server Link) [email_address] DSL explained
DSL premises
and only then for computers Code is written for people
Objects ---> Vocabulary Grammar ---> Language Domain Driven  Design DSL
DSL is advanced stuff
DSL example (by Martin Fowler)
 
 
 
 
 
 
 
 
DSL is a computer  language with: human language nature limited expressiveness domain focus
DSL types internal external language workbench
Internal DSL example
 
 
External DSL example
 
Language workbench example
 
More examples
regular expressions CSS SQL all XML Unix config files Ruby on Rails mocking frameworks wiki syntax / markdown LINQ
Using internal DSL (aka Fluent Interface)
Easy to do... no parsers, etc. Full IDE support Good Bad Limited by host language
 
 
 
 
 
Method chaining Object scoping Expression Builder
Using external DSL
Unlimited expressiveness You choose execution environment Good Bad Requires “more” work No IDE support
DSL script parse AST Semantic model optional
You can parse DSL manually  (regexp, Tokenizer) using some tool (ANTLR, yacc, ...)
 
Using  Language Workbenches
Meta Programming System Microsoft Oslo Intentional Domain Workbench Eclipse Modeling Project
 
concepts (language) edit you
AST (DSL script) concepts (language) edit describe you
AST (DSL script) concepts (language) edit edit describe “ user” you
AST (DSL script) concepts (language) edit describe “ user” you no text, just AST ! edit
useful stuff (like java code) AST (DSL script) concepts (language) edit describe transformed “ user” you edit
 
Module Project
Module Project Solution Language Generator DevKit kind of
Model Module Project Solution Language Generator DevKit kind of
Node Model Module Project Solution Language Generator DevKit kind of includes Concept defined by
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Internal DSLs rule! :)

DSL explained _

Editor's Notes

  • #2 Hi For those who haven't heard about it, SOLID is acronym composed from principles names. (There are 5 of them.) SOLID doesn't have any particular meaning. It's just a good way to remember list of principles. These principles are about low-level design and partly interpretation of OOP basics.
  • #4 Before doing anything it's good to know “why” you're going to do it. In other words operating without context you're becoming coding monkey or a screwdriver.
  • #40 I began programming at school because it was fun (before anyone actually taught me). Turbo Pascal, asm for DOS (for cool things). Then Delphi, C++. Of course we were told at school that OOP not only “Организация Освобождения Палестины”(Palestine Liberation Organization, in Russian sounds like OOP) but also encapsulation, polymorphism, inheritance © Nice words which I've known for quite a long time. What I did at the time was kind of “goal-oriented programming” . You don't really care how the work is done (almost), it's works today – fine! I knew some techniques like using inheritance but never bothered to understand why they exist. After (four?) years I got tired of “fighting the mess” and vision of programming as “low-level activity” so I programmed only for some “code for labs”. Some time later for some reason I though it would be nice to make sense of objects anyway. That way I came across patterns, UML, java, junit, refactoring and OOP (this time for real) . Nice java IDEs were also very attractive, but not more than the following “promises”.