CSC/ECE 517 Fall 2013/ch1 1w30 nn: Difference between revisions
Line 62: | Line 62: | ||
A general process for writing a DSL in Ruby is as follows : | A general process for writing a DSL in Ruby is as follows : | ||
[[ | [[File:DSl.jpg]] | ||
== Examples == | == Examples == |
Revision as of 22:19, 23 September 2013
A domain specific language (DSL) is a computer programming language of limited expressiveness focused on a particular domain. A domain-specific language is created specifically to solve problems in a particular domain and is not intended to be able to solve problems outside it (although that may be technically possible).
Why use DSL ?
DSLs are useful tools – they use the grammar and syntax that closely resembles the lexicon used by the target domain so we can easily express logic specific to the particular problem.They have very specific business domain based implementations. It is designed to be very intuitive and fluent for a domain expert to use.A domain-specific language is similar to programming library and is somewhere between a tiny programming language and a scripting language.
DSLs are popular for two major reasons: improving productivity for developers and improving communication with domain experts.A well-built DSL can make it easier for the developers to understand a complicated workflow thereby increasing their productivity. The communication with the domain experts becomes easier as it provides a bridge between the development of an executable software and a description that the domain experts can understand to know how their requirements have been implemented in the system. This helps to address one of the major concerns in software development- the communication between the developers and the customers.
Lets take for example, a mathematician working on a particular algorithms does not think in loops, iterations and variables but instead he thinks in the form of base cases, recursions and base comparisons. Using a programming or a general purpose language with iterators and loops require him to mentally map the corresponding parameters from his domain to the language he wants to write his code in. Using A DSL for algorithm design can help nullify this translation and provide a much more effective and reusable code library.
Types of DSL
There are two types of DSLs namely Internal and External.
Internal DSL
An internal or embedded DSL is designed and implemented using a host language. A script in an internal DSL is valid code in its general-purpose language, but only uses a subset of the language's features in a particular style to handle one small aspect of the overall system.The programmer need not worry about grammar, parsers, and tools to do the heavy lifting. However, an internal DSL is constrained by the host language, and your DSL is influenced by its host's flexibility, limitations, and idiosyncrasies. The challenge with an internal DSL is to tactfully design the language so that the syntax is within the confines of what the host language allows, yet is as expressive, concise, and fluent as you desire.Ruby has also developed a strong DSL culture: Many Ruby libraries come in the style of DSLs. In particular, Ruby's most famous framework, Rails, is often seen as a collection of DSLs.
Advantages and Disadvantages of Internal DSLs
An internal DSL rides on the syntax of a host language, so the programmer need not spend any time or effort worrying about compiling or parsing. Also as the programmer is largely constrained by the host language, a lot of time is saved designing the syntax of the DSL.or an effective implementation of a DSL a flexible language with great metaprogramming capabilities would be useful.It is better to choose a programming languages which has few restrictions and idiosyncrasies.External DSLs give you better control than internal DSLs when validating DSL syntax. Because you take the effort to define the grammar for your external DSL, that effort also serves to validate the syntax. This is harder to do with an internal DSL because the code is often processed dynamically. You will have to do extensive error checking and do the validation yourself.
External DSL
An external free-standing DSL is a language separate from the main language of the application it works with. Usually, an external DSL has a custom syntax and programmer defined rules for grammar-definitions and parsing the syntax.It is upto the DSL programmer to decide on the language and the tools to implement the DSL. However, using another language's syntax like XML is also common. A script in an external DSL will usually be parsed by a code in the host application using text parsing techniques. Examples of external DSLs that you probably have come across include regular expressions, SQL and XML configuration files for systems like Struts and Hibernate.
Advantages and Disadvantages of External DSLs
An external DSL gives the programmer the liberty to design the syntax of his/her language in exactly the way desired. They can select the language's symbols, operators, constructs, and structure as they fit their domain. On the downside, the programmer has to define the grammar for their language and create a compiler to parse and process the syntax and map it to the semantics they expect. An external DSL gives a programmer a lot of flexibility, but you have to take the time to do the hard work of compiling it.
Building a DSL in Ruby
DSls are quite popular in Ruby because of the nature of the Ruby language itself:
- Especially the ability to use minimal syntax in order to make the code concise.
- Ruby itself is a very expressive language and has readable syntax which facilitates writing of DSLs where one has to come up with their own syntax.
- Most ruby programs are already a DSL because of Ruby's syntax.
Below is the actual Ruby code:
it "must not allow a person to login without the proper credentials " do person.logs_in_with("invalid credentials"); person.must_not(be(person.logged_in?())); end
The above code can also be written as a DSL :
it "must not allow a person to login without the proper credentials " do person.logs_in_with :invalid credentials person.should_not_be_logged_in end
From the above example we can clearly see that the DSL code is more readable and clearly explains what the code means. Notice how we used symbols(:invalid credentials) instead of strings to make it more readable.
How to build a DSL in ruby
A general process for writing a DSL in Ruby is as follows :
Examples
Here are some examples that will explain the various benefits of DSLs in Ruby:
Internal DSL in Ruby
- A programmer can create his/her own classes and define them:
class Integer def minutes ..... end end 60.minutes 20.mnutes.later delete 20.minutes.later
- A DSL can be used to write more expressive code
every 3.day, :at => '2.00 pm' do delete end
The above code easily reflects its purpose and thus highlights the benefits of using a DSL
Some popular Ruby DSLs
Some popular examples of Ruby DSLs are as follows:
- Rake : [ http://rake.rubyforge.org/]
- Sinatra :[ http://www.sinatrarb.com/]
- Twibot : [ https://github.com/cjohansen/twibot/tree/master]
Advantages and Disadvantages
Some of the advantages:
- Domain-specific languages allow solutions to be expressed in the idiom and lexicon of the domain.It is possible for the domain experts to themselves define , modify and develop the domain-specific language code.
- It is possible to do validations in DSL’s at the domain level.
- The code in most cases is self-documented
- Domain-specific languages improve quality, productivity, reliability, maintainability, portability and reusability.
Some of the disadvantages:
- There are a lot of overhead costs involved w.r.t developing DSL’s.
- The programmer needs to learn a new language , design, implement, setting and maintaining a scope and maintain a DSL as well as the tools required to develop it.
- Also limited number of experts in a DSL increases the labor costs.
- DSL’s also cause some level of processor efficiency hit as compared to hand-coded software.
- Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
- Integration of the DSL with other components of the IT system may be difficult.
- Proliferation of similar non-standard domain-specific languages.Non-technical domain experts can find it hard to write or modify DSL programs by themselves.