12

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).

Result:

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.

closed as primarily opinion-based by Steven Burnap, GrandmasterB, user40980, user22815, amon Dec 10 '14 at 20:06

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 8
    You might want to dial down the rant aspect. – user7043 Dec 7 '14 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 '14 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 '14 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'. – GrandmasterB Dec 7 '14 at 22:37
  • 3
    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". – Jörg W Mittag Dec 8 '14 at 3:01
19

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 '14 at 21:49
6

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.

Update:

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 '14 at 16:21
  • 3
    @amon That sounds like the start of a good answer :-) – svick Dec 7 '14 at 17:09
  • 1
    The barrier to learn SQL might be lowered because of the readability, prolog might fend off people due to the syntax, I completely agree on that. But indeed, without knowing SQL understanding subqueries and a few joins is not so trivial. But the lower barrier when starting out with simple queries is surely a reason people would use SQL instead of Prolog to start out. :) – Dylan Meeus Dec 7 '14 at 17:51
  • 4
    @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 '14 at 8:04
  • 1
    @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 '14 at 9:44
4

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 '14 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 '14 at 21:40
  • 1
    Theoretically yes, but practically SQL is storing on disk, and that is often essential – Basile Starynkevitch Dec 8 '14 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 '14 at 8:20
  • 1
    Exactly, SQL is for databases, and Prolog is a programming language. That is my point. – Basile Starynkevitch Dec 8 '14 at 8:37
1

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.