Our competences at your disposal on our blog
We love our job and we are glad to share it with you! Keep yourself fully informed about news and technologies we use to develop and which you may need! Follow our blog.
×

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.
mattia.minotti's picture

In computing, the vast majority of programming languages ​​is general-purpose, this is because they are designed to allow you to write software for any kind of application domain. Alternatively, in some contexts, there are so-called domain-specific languages ​​who sacrifice their generality in exchange for greater expressiveness.
The languages ​​of this second category, among which we find particularly famous as HTML or SQL, have the great advantage of allowing the programmer to design its solutions with abstractions that are closer to the domain of the problem to solve.

Domain Specific Languages

Although the domain-specific languages ​​have always existed in the computing landscape, they have always been confined to specific domains and macroscopic dimensions.
Until some time ago it was not desirable to invest time in creating a language if it wasn’t forecast a stable or enduring use by a consistent pool of programmers, otherwise the game was not worth the candle.
Recently, however, new trends of software engineering, supported by emerging technologies in this field, have allowed us to reduce the impact that the creation of a new language can have on the economy of a project.
This has made the creation of domain-specific languages ​​a very powerful tool if used wisely.

From a conceptual point of view, creating a language for a specific application domain, coincides with the determination of a model that is an abstraction of the entities that constitute that domain.
We try to do an extremely simplified example: let's consider an application domain as that of an animal farm, its minimal model may be composed of:

  • The factor, manager of the farm.
  • One or more animals, in detail: pigs, sheeps and chickens.
  • One or more fences in which live different animals.

The description in words above is nothing more than an informal representation of a model. An alternative could be the following:

Model :
    farmhouse=Farmhouse;

Farmhouse:
    ‘farmer’ ‘:’ Farmer
    ‘fences’ ‘[‘ (fences += Fence)* ‘]’
Farmer:
    STRING

Fence:
    ‘fence’ ‘{‘ (animals += Animal)* ‘}’

Animal:
    Pig | Sheep | Hen;

Pig: ‘pig’

Sheep: ‘sheep’

Hen: ‘hen’

The code above is the definition of a language that refers to the same model previously expressed (to be precise, it is a formal definition of a grammar written for Xtext Eclipse technology).
An example of an instance of this language, and then an instance of this model, is the following:

farmer: ‘Mr Smith’
fences: [
    fence { pig pig pig }
    fence { sheep sheep sheep sheep hen hen hen }
    fence { hen hen hen hen hen }
]

In it we define the Mr. Smith's farm, with three enclosures: the first with 3 pigs, the second with 4 sheeps and 3 hens, the third with 5 hens.
The connection between language and the model is crucial because it allows us to understand that the definition of a domain-specific language for a given application domain is equivalent to find its model, which is one of the analysis process’s goals (or perhaps the main objective) of software engineering.
What a domain-specific language also offers is the possibility to define other instances of the problem in an agile and "strict" method.

Code Generation

Here at TwinLogix we have always appreciated the philosophy of Domain-Specific Languages​​, but we also tried to go a step further and figure out how to reconcile it with a more pragmatic approach, geared to the needs and timing of the company.
To this end, we experimented the use of some technologies for defining languages ​​and code generation initially developed as an Eclipse Project and then distributed within the Eclipse Modeling Framework: Xtext and Xtend.
These two frameworks provide all the functionality for creating its own language and the definition of generation rules to transform sentences of grammar in their programs in any general purpose language like Java, Objective C, C + +, etc..
In this way, the clearance between the definition of the problem in the domain-specific language and the target language implementation is substantially automatic and taking in charge by the code generator which, however, must be developed just once.
Eclipse also allows you to generate the necessary plugins for the integration of features developed with Xtext and Xpand directly in its IDE, making it simple to use and fast.
Once the integration is completed, you can create in your own projects one or more files with instances of the Xtext file model and automatically Eclipse generates the appropriate sources in the target language.

The approach to code generation, according to our experience, provides a number of valuable benefits:

  • Reduction of the development time of software components applicants, with a generalized structure.
  • Lower probability of error on the portions of code generated: once built the system, the errors on the parts generated automatically become null.
  • Uniformity of the code: the portion of the generated code, of course, always complies with the generator and then with a predefined standard.
  • Changes and bugfixes in the code, if applied to the generator, are automatically propagated to the next generation.
  • Ability to write components common to parts of the system in different languages​​, calling them once and reducing the development time. For example, the definition of an entity in Java, iOS, C++ can be done by writing it only once in the domain-specific language and generating the various versions.
  • Minor frustration for recurring developments (never forget that developers are still people!).

Finally, I would add a couple of sample data that may be useful to give an idea of the scope of the concepts described above.
Our normal implementation of a REST service of medium complexity, and developed in Java using the Spring Framework MVC 3.2, has about 4100 lines of code.
Currently, making the most of the code generation, we got to automatically generate most of 3850 lines of code, setting a pattern of about 240 lines, and still having to write specific parts, by hand, about 250 lines of code.
We've switched from implement 4100 lines of code to write just 500 lines, about a 88% less!

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.