Why DSL

As software projects are getting more complex and more expensive there is a widely felt need to improve the software development process.

Test 

Where strategies like offshoring and UML/Model Driven Architecture have had only limited success, DSL's are expected to take the software development process to a higher level.

The central idea about domain specific languages is that within a well defined domain, there are a lot of best practices of how to achieve a desired functionality. With generic programming languages like C#, Java and php a developer is not directed towards these proven best practices and has to reinvent the wheel. By offering this developer a specific language to the domain he has to work in, this developer can only choose from a subset of proven solutions and does not have to take care of all the implementation details.

Domain Specific Languages have been around for a long time. Well known ones include SQL and HTML. They target the domains of ‘Database Querying' and ‘Layouting' respectively.

So far, developing these kinds of languages was only cost-effective for very large user groups and intensive usage.

Because of improved technologies, the cost of developing a DSL has dropped. Because of this, DSL's have been receiving an increased interest in the recent years. Developing a DSL becomes a viable option for many more software companies. 

As with any technology there are benefits to be gained and challenges to overcome. Knowledge of both and good management can make the difference between a project failure or success.

At Plicity, we have been developing Domain Specific Languages for years and we can help you reap the benefits of DSL's while keeping these challenges to a minimum, by offering the following:

  • deep understanding of creating domain specific languages
  • unique toolset to create these languages.

  

Benefits of using DSL's

  • Cost reduction. Several of the software development processes like coding and testing can be automated significantly. The result are considerable cost reductions.
  • Output improvement. the developers work on a highel level, where programming has 1-on-1 relation to real world processes and data. the information created by the developers can be discussed directly with their client. this in itself results in a product that better suits the requirements.
  • Quality. The code written is is closely related to business process. The code is compact and surveyable, so team members with relevant business knowledge can read and understand the code. This will result in high qualitity code.
  • Productivity. The expertise of the star programmers will be incorporated in the DSL. All team members woring with the DSL are actually using that expertise very efficient. This results in higher productivity
  • Reliability.  Dsl results in short programs. Bugs increase exponentional with the lines of code, so short programs have much less bugs. This results in reliable programs.
  • Maintainability. The costs of maintaining software are strongly related to the lines of code that have to be maintained. It is not uncommon for DSL's to reduce the lines of code by a factor 10. 
  • Portability. If environment / platform changes, only a new translation (output module) has to be written. DSL's avoid using platform related functionality, they are geared towards domains, not to platforms.
  • Reusability. Just like with a library, the code that is similar only has to be written once and it is reused multiple times. The DSL is a library in itself.
  • Time to market. The implementation of the requirements is reduced to formally describe these requirements. The description is the program, so no time will be lost writing out all instructions. The time off development is reduced considerably.

  

Challenges of using DSL's

  • Acceptance. The technology of DSL's is new to large groups of professionals. If this leads to initial reluctance, Plicity can help overcoming this by informing this group and showcasing success stories.
  • Vendor lock in. Using 3rd party DSL's are tying you to a specific supplier, just like the usage of 3rd party libraries will do. In cases where this situation is not preferable, you can choose to implement your own DSL.