Thinking in Eve Part 1

Modelling domains declaratively with Eve

Eve is a new programming environment from the team that created LightTable. The language Eve uses has a semantics that has been designed to support rich, literate programming from the start. It is declarative, orderless, and introspectable. It is also astonishingly simple: everything in Eve is based on pattern matching rules applied to key-value records. Whether you are working with data, creating a browser interface, or sending emails, this simple representation makes it very easy to code in a declarative way.

Declarative programming is powerful because it reduces the mental distance between the problem and solution domains. Instead of saying how you want something done and thinking in the language of the machine, you can say what you want to have happen in the language of the problem. Eve’s combination of a declarative syntax with rich literate programming allows us to go further and also describe why we are solving the problem.

This combination also gives us another tantalising possibility: more direct translation between requirements and code. While fully automated software engineering is a while off, this can make it much easier to add features to a code base. If you need to change a requirement, the code you need to change is already there and is obviously related to the requirement’s text.

In this article, I describe a few patterns for implementing domain or business rule requirements by analysing their textual form.

Note: In this article, I am being quite verbose in my Eve code. This is deliberate to make it easier to see the detailed mapping from the requirement to the implementation. In real code, a lot of these would likely be collapsed for readability.

RuleSpeak

In the following, I am using the RuleSpeak controlled natural language formulation of business rules. This provides a simple set of sentence forms that can express most domain requirements.

Being systematic with our language like this allows us, as humans, to be quicker at parsing the rules. It also allows us to check our translations. We should be able to easily see which bits of the code correspond to which bits of the rule.

Validity rules

It is common to want to constrain what records are valid. An example of this sort of business rule is: ‘A team plan must have at least two team members’. If a team plan has fewer than two members, the plan does not conform to the rule and error processing should happen. These rules are indicated in RuleSpeak with the keywords ‘must have’ or ‘must be’.

These kinds of rules are trivial to translate to Eve. Essentially, everything forms part of the search section of a single block. The part before the ‘must’ selects the record of interest (the subject of the rule), and the part after specifies the validation. For example:

It is important to invert the ‘sense’ of the requirement: if the requirement states that one number must be larger than the other, then the Eve block must check whether the number is smaller.

Another rule in the domain could be ‘Team members must be over the age of 18’. The translation of this is similarly straightforward:

Conditional rules

A conditional rule is one that is suffixed by a section with the keyword ‘if’. For example, ‘A team plan must have at least one administrator if the team plan has more than five members’.

With conditionals, the sense is not reversed. In the above, we deliberately filter our search to only those entities with more than 5 members.

Calculation rules

There are two sorts of calculation rules: those that are introduced with the keyword ‘must be computed as’ define one property in terms of others, while those introduced with ‘must be considered as’ describe calculated classifications. These are best translated as bind actions so that they constantly stay up-to-date.

An example of the former is ‘The bulk discount of a team plan must be computed as the number of team members * 0.01’.

A classification rule might be stated like ‘A team member must be considered as inactive if the last login date was over 30 days ago’. This can be implemented by tagging the subject being described.

Conclusions

Eve provides a wonderful new way of thinking about and writing software that has the potential of mapping much more cleanly to requirements. This will allow for quicker and easier development, and more maintainable code.

If you want to learn more about Eve, you can start playing with the quickstart sandbox online now or read the language manual. The environment is still in its early days, but it shows great potential. I am excited to see what new approaches to software it will inspire.