About

License

The source code implementing delightql is licensed Apache 2.0.

The content of this website and the book are © 2026 Daniel Eklund. All Rights Reserved.

Regarding intellectual property, I have always had willful ignorance. I am learning now. My choice of Apache 2.0 was based on the fact that other languages use it.

There are two things I have not yet figured out for myself and for delightql:

• what will be the contribution mechanism ("to CLA or not to CLA", "to allow PRs from the 'wide world' or not" )
• trademark

That I don't have the answer to this at this point only means that I don't have the answer to this at this point.

History

The idea for delightql started in 2017. The book was written starting in 2020 through to 2025.

Various proof of concepts were written between 2017 and 2020¹ before all effort was placed only into writing the book. The author believed that with a good enough reference, the language would insist on existence.

In mid 2025, coding began on the specifications listed in the book.

The language was originally named datalogite for its obvious datalog inspiration. Its name changed to logiteql and then dliteql but soon clashed with the opensource project dlite. Rather than give up on this train of thought, the author switched to the homophone: delightql.

The Datalog Education System predates delightql significantly² and makes the same connection that underpins all of delightql: SQL and logic programming are the same. Other SQL transpilers have made similar connections. ³ Many of the ideas around tree-groups found their inspiration from the COGROUP operator in pig latin and from other 'big data' relational technologies that were permissive to zeroth-normal form data.

There are other influences in the syntax, the most obvious one being the pipe operator |> via Elixir and before that ML and F#. Syntax aside, pipelining as job control in UNIX is the obvious influence.

Motivation

Let me switch to first person.

I love SQL. Or more accurately, I love the relational model and respect SQL. Time and time again, I have found engineering solutions would become better by using more of SQL's features and not fewer -- or worse, trying to hide it.

That said, familiarity with SQL gave me enough hubris to envision some things being better.

For a 50-year old 4GL, SQL has had a remarkable run and will continue to do so, but I was curious as to whether there was room for a different syntax that could accomplish a few things:

• remove some of the un-ergonomic and boilerplate frustrations
• promote reusability and composability
• trick people into learning about Prolog

At no point did I think of the language as being anything other than a SQL transpiler. I wanted to build atop the years of engineering and familiarity that SQL affords. I had no ambitions about a new paradigm. I just wanted the power of SQL without having to reach out to vim macros, moustache templating, or other such hacks.

For the first four or so years, delightql was a weird outlet for my creativity -- a way to learn more about the subjects were of interest to me, but not yet a goal.

As the years went by, I would find myself implementing and reimplementing, with bursts and false starts, and then having to change my attention to my paying job and forgetting everything I wrote. As a result, I started writing out the book with the promise to myself: "When you finally can take a year off from work, you can implement this."

Usage of AI

AI was used to help implement the language, but not to design the language. As mentioned above, the language was my pipe dream for well over five years and was described by a 300 page book.

I implemented the first thousand lines of Rust code and most of the tree-sitter parsing code, before wholeheartedly embracing agentic coding.

That this section exists is indication that I might feel a bit defensive about it and am still working through some feelings.