Imperative vs. Declarative Query Languages: What’s the Difference?

The evolution of programming languages has grown in parallel with the evolution of computing itself, with new languages being created with each new advance and paradigm shift.

After all, if language shapes how we view reality, then changes in computing (i.e., thinking) will necessitate a corresponding shift in language. Databases are no exception.

The two main paradigms of database query languages are imperative and declarative. Understanding the difference between these two approaches is essential if you’re going to be successful in database development.



In this Graph Databases for Beginners blog series, I’ll take you through the basics of graph technology assuming you have little (or no) background in the space. In past weeks, we’ve tackled why graph technology is the future, why connected data matters, the basics (and pitfalls) of data modeling and why a database query language matters in the first place.

In this blog post, we will discuss the trade-offs and differences between imperative and declarative query languages. Selecting which type of query language to use depends upon your specific situation.

Imperative Query Languages: Definition & Example

If the query languages were human archetypes, imperative languages would be the micromanaging boss who gives instructions down to the final detail.

In the most basic sense, imperative query languages are used to describe how you want something done specifically. This is accomplished with explicit control in a detailed, step-by step manner; the sequence and wording of each line of code plays a critical role.

Some well-known general imperative programming languages include Python, C and Java.

In the world of graph database technology, there aren’t any purely imperative query languages. However, both Gremlin and the Java API (for Neo4j) include imperative features. These two options provide you with more detailed power over the execution of their task. If written correctly, there are no surprises – you will get exactly what you want done.

However, imperative database query languages can also be limiting and not very user-friendly, requiring an extensive knowledge of the language and deep technical understanding of physical implementation details prior to usage. Writing one part incorrectly creates faulty outcomes.

As a result, imperative languages are more prone to human error. Additionally, users must double-check the environment before and after the query and be prepared to deal with any potential erroneous scenarios.

To better illustrate the differences, imagine you have two children: Isabel and Duncan. Isabel represents an imperative query language and Duncan the declarative query language.

To get the two children to make their beds, you take differing approaches. For Duncan, it is easy. Simply instruct Duncan to make his bed and he will do it however he sees fit. Yet, he might make it differently than you had in mind, especially if you’re a picky parent.

Isabel requires an entirely different process. You must first inform her that she needs both sheets and blankets to make her bed, and that those materials are found on top of her bed. Then she requires step-by-step instructions, such as “spread the sheet over the mattress” and “tuck in the edges.”

The final result will be closely similar to Duncan’s (or perhaps, exactly the same). At the end of the process, both children have their beds made.

Declarative Query Languages: Definition and Examples

All too often, declarative query languages are often defined as being any database query language that is not imperative. However, to define it in such a manner is too broad.

Declarative query languages let users express what data to retrieve, letting the engine underneath take care of seamlessly retrieving it. They function in a more general manner and involve giving broad instructions about what task is to be completed, rather than the specifics on how to complete it. They deal with the results rather than the process, focusing less on the finer details of each task.

Some well-known general declarative programming languages include Ruby, R and Haskell. SQL (Structured Query Language) is a declarative query language and is the industry standard for relational databases.

In the graph technology ecosystem, several query languages are considered declarative: Cypher, SPARQL and Gremlin (which also includes some imperative features, as mentioned above).

Using a declarative database query language may also result in better code than what can be created manually, and it is usually easier to understand the purpose of the code written in a declarative language. Declarative query languages are also easier to use as they simply focus on what must be retrieved and do so quickly.

However, declarative languages have their own trade-offs. Users have little to no control over how inputs are dealt with; if there is a bug in the language, the user will have to rely on the providers of the language to fix the problem. Likewise, if the user wants to use a function that the query language doesn’t support, they are often at a loss.

In the previous example of the children, Duncan was able to complete his task in a method faster and easier for his parent than Isabel. However, imagine now that you want to them to wash the dishes.

It is the same process for Isabel: You’d need to walk through each step with her so she can learn how the process works.

For Duncan, however, we have hit a snag. Duncan has never learned how to wash the dishes. You will stay in that impasse with Duncan unless his programming engineers decide to teach him how to wash the dishes. (Duncan isn’t like most children.)

Conclusion

This post is not meant to pit the two types of database query languages against each other; it is meant to highlight the basic pros and cons to consider before deciding which query language to use for your project or application.

You should select the best query language paradigm for your specific use case. Neither paradigm is better than the other; they each have different strengths for software development.

If your project requires finer accuracy and control, imperative query languages do the job well. If the speed and productivity of the development process matter more, declarative languages offer the flexibility of getting results without as much effort. Ultimately, the choice depends on you.





Catch up with the rest of the Graph Databases for Beginners series:

• Why Graph Technology Is the Future
• Why Connected Data Matters
• The Basics of Data Modeling
• Data Modeling Pitfalls to Avoid
• Why a Database Query Language Matters (More Than You Think)
• Graph Theory & Predictive Modeling
• Graph Search Algorithm Basics
• Why We Need NoSQL Databases
• ACID vs. BASE Explained
• A Tour of Aggregate Stores
• Other Graph Data Technologies
• Native vs. Non-Native Graph Technology