It seems that writing Declarative SQL is very popular in Imperative Programming. However, it also seems that writing Declarative Prolog could save a lot of complexity but this is not very common.

Is there a historical precedent for this apparent preference of SQL over Prolog?

If the reason is lack of native support by Imperative languages, then is it possible to answer why the language creators didn't find it useful to natively support Prolog in the first place?

To provide some specific examples:

Example 1
Evaluating a loan application might be just a few lines of code in Prolog, like the SELECT/JOIN query that is just a few lines of code in SQL, but it seems the advantage is not as obvious as SQL.

Example 2
Here is another example problem and the solution in Prolog. The following constraint logic program represents a simplified dataset of john's history as a teacher:

teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.

The following goal clause queries the dataset to find out when john both taught logic and was a professor:

:- teaches(john, logic, T), rank(john, professor, T).


2010 ≤ T, T ≤ 2012.

In the above example it will be easy with SQL to get the same result. But suppose that you have this data in an Array. Then it is not as easy to get the same results using SQL. And in the case of data stored in an array, I believe that the Prolog code will be easier to write and maintain.

  • 8
    You might want to dial down the rant aspect.
    – user7043
    Dec 7, 2014 at 15:09
  • 4
    Most of the text sounds like a rant against people who don't use Prolog. There is a question worth asking contained in it, but the other stuff (the rant) attracts downvotes and turns off people who could contribute an answer. In other words, I suggest you try phrasing your question in a more charitable way.
    – user7043
    Dec 7, 2014 at 15:17
  • 6
    "For example evaluating a loan application might be just a few lines of code in Prolog" I don't buy this, for the same reason as any application worth it's salt will use tons of custom-made or generated SQL queries.
    – Euphoric
    Dec 7, 2014 at 15:57
  • 7
    Maybe I'm missing something, but I think the answer here is 'people use SQL because that's what the databases support'. Dec 7, 2014 at 22:37
  • 4
    They do use Prolog … well … actually … they do use Rules Engines, which are "an ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog". Dec 8, 2014 at 3:01

4 Answers 4


I believe this is primarily historical thing.

SQL was primarily used in businesses for making business applications. Some companies build their livelyhood on selling SQL solutions and they used their money to advertise and push SQL into minds of many. This was especially empowered by how important data is for business people. This is why SQL won over it's many competitors and is so widely known and used even today.

Prolog on the other way was mostly known in academic sphere, usually in area of artificial intelligence. Academic people rarely push their tools and ideas on others in a way business does. It usually requires some company to advertise a technology that was born in academia for it to spread among common developers. Also, while data is extremely important, the "business rules" are not so. While they might seem important, they are much less important than data. Business rules can usually be fixed easily. Trying to fix "broken" data is usually much harder problem. So businesses focused much more on getting their data solutions than their business rules solutions.

  • 2
    "It usually requires some company to advertise a technology that was born in academia for it to spread among common developers.": True. A lot of good ideas are developed in academia and later made popular by companies who have the marketing power to do so. +1
    – Giorgio
    Dec 7, 2014 at 21:49

The reason is actually pretty simple. It has nothing to do with how useful the language is for a given task and everything to do with how maintainable the code is.

Reading an SQL statement, many developers will be able to determine what most basic queries do without knowing the language. They might have a harder time in the case of complex examples but adapting existing code or working from samples is relatively easy. The barrier to comprehension is quite low for the vast majority of queries.

You read a few lines of prolog and many developers will go slightly cross-eyed and leave the task for someone else, and possibly go for a lie down. The predicate syntax of prolog simply does not lend itself to easy reading.


Based on the code sample, languages that implement collections should do well. I implemented a solution in C#/Linq and it wasn't significantly larger than the prolog sample (once you accounted for the static typing and definitions required). There was an extra step involved in some interim work to merge the lists to make a single timeline to be searched but it was not a significant amount of work.

  • 14
    It's true that SQL went for COBOL-grade ultra-verbose and “natural” syntax that makes it “easy” to read. But I severely doubt that someone who does not know SQL would be able to properly understand a medium-complicated statement with a few joins or count(*) or anything like that. If we understand basics of SQL it's because we occasionally have to use that language and therefore had to learn these basics. Relational data storage is a much more common need than solving logic systems, so no comparably strong necessity to learn Prolog presents itself.
    – amon
    Dec 7, 2014 at 16:21
  • 3
    @amon That sounds like the start of a good answer :-)
    – svick
    Dec 7, 2014 at 17:09
  • 5
    @JamesSnell Sorry but -1. What you are claiming doesn't match any RegEx. ^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$.
    – 53777A
    Dec 8, 2014 at 8:04
  • 2
    @JamesSnell RegEx are cryptic, hard to write, debug, maintain and modify or extend, yet they are extremely popular. If you were right then RegEx should have been never get their current popularity between developers and language creators.
    – 53777A
    Dec 8, 2014 at 9:44
  • 2
    @JamesSnell I definitely respect your opinion and I do believe that the learning-curve and maintainability issues has contributed to the fact, however I'm not totally following you as I think it's only a small part of a bigger issue.
    – 53777A
    Dec 8, 2014 at 10:53

There is another reason. Practically speaking, SQL is useful for data persisted on disk. So databases are used to store data for a "long" time (several months). Every SQL database (e.g. PostgreSQL, MySQL, Oracle, ....) is managing data on disks (or SSDs, i.e. hardware which could keep data if properly powered down). However, most Prolog implementations I am aware of are working in memory, and cannot be used to keep data reliably (data persistent after a power outage, at least a programmed one). And SQL implementations can deal with terabytes of data....

Of course, a DBMS does not write immediately to the disk (but later). But the Prolog interpreters I heard of never write (implicitly) their fact & rule bases to persist them to disk.

(Some language implementations do have persistence ability, e.g. SBCL with save-lisp-and-die... but I know no Prolog doing that).

Pragmatically speaking, SQL is for databases -on disks-, but Prolog is a programming language (for source code in textual files).

  • 1
    I don't think so, since no SQL database works strictly with disk I/O, as that would be very inefficient (there's some data in-memory at all times), and there's no technical impediment to serializing prologue constraints to disk that I can think of at the moment.
    – idoby
    Dec 7, 2014 at 21:32
  • 3
    Theoretically speaking, SQL is a query language and doesn't care about how data is stored, as long as the data is described by a relational model. SQL is just an interface, not a paradigm. There are SQL-using databases that operate purely or partially in non-persistent memory. It would even be possible for an SQL-using database to store data in form of Prolog facts! [citation needed] After all, facts merely describe relations. Conversely, it would probably be possible for a Prolog engine to store facts in a database-like fashion on disk rather than loading everything to memory.
    – amon
    Dec 7, 2014 at 21:40
  • 1
    Theoretically yes, but practically SQL is storing on disk, and that is often essential Dec 8, 2014 at 5:42
  • 1
    @BasileStarynkevitch Rules & Facts are written on the source code which persists on disk. Why would you store them on the database instead? What do you mean by Prolog cannot keep the data? It is not supposed to do that. That's why databases do exist. Could you please elaborate more.
    – 53777A
    Dec 8, 2014 at 8:20
  • 1
    Exactly, SQL is for databases, and Prolog is a programming language. That is my point. Dec 8, 2014 at 8:37

One aspect not mentioned so far is the push for "open" systems in the 1980s and 1990s. In many places, software vendors would have to provide industry standard access to the data in their databases. At the time, SQL was an established standard which was well know and understood; Prolog was pretty esoteric and academic. Once you started getting interfaces like ODBC to easily connect systems, no-one was interested in looking at other technologies.

I worked at a place in the late 80s which had a quite successful ISAM database that was forced by market pressures/procurement regulations to add a SQL interface to.

Not the answer you're looking for? Browse other questions tagged or ask your own question.