14

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
53777A
  • 1,706
  • 13
  • 18
  • 8
    You might want to dial down the rant aspect. –  Dec 07 '14 at 15:09
  • @delnan Sorry didn't totally understand your point. – 53777A Dec 07 '14 at 15:11
  • 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. –  Dec 07 '14 at 15:17
  • 1
    @delnan Thanks for the heads-up. That's to my broken English, otherwise I didn't have such an intention. I will try to re-phrase it. – 53777A Dec 07 '14 at 15:19
  • 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 07 '14 at 15:57
  • 1
    @Euphoric +1 - this question might benefit from some code samples to illustrate the points you'd like to make. – James Snell Dec 07 '14 at 16:08
  • 1
    @JamesSnell I've updated the question with an example. – 53777A Dec 07 '14 at 17:42
  • 1
    @Euphoric I have just add a real-world problem and its solution. I should have added that in the first place. Please have a look. – 53777A Dec 07 '14 at 17:43
  • Are you asking about languages or relational vs deductive databases? To me, it seems as if you were asking about why we use relational databased instead of deductive ones (eg. ones based on Prolog). – Euphoric Dec 07 '14 at 17:43
  • @Euphoric I'm talking about languages. The example might be misleading you, however that's the most clear example I can think of. The point here is if you didn't have this data in a database, so therefore no access to `SQL`, how would you get the same result in an _Imperative_ solution? I think in any language other than `SQL` it should take quite some effort to get the same result. – 53777A Dec 07 '14 at 17:50
  • @53777A Any modern language with decent collections can trivially solve that specific problem, although you do have to spell out the (simple) solution yourself. Let `teaches` and `rank` be mappings from subjects/titles to ranges of years. Then, in Python: `logic_as_professor = set(teaches["logic"]).intersection(rank["professor"]); print("John taught logic as professor from %d to %d" % (min(logic_as_professor), max(logic_as_professor)))`. That's pretty inefficient because it loops through all years in question, but it can be easily rewritten to efficiently operate on intervals instead. – amon Dec 07 '14 at 19:24
  • @amon Well, that specific example is just a simple example and I don't wanted to make it more complicated. My point is why Prolog and all of its features don't look very useful to most programmers, but unfortunately it seems that first I have to prove that Prolog has anything to offer, and then talk about why it is not as popular as SQL for example. – 53777A Dec 07 '14 at 19:59
  • 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 07 '14 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"](http://wikipedia.org/wiki/Greenspun's_tenth_rule). – Jörg W Mittag Dec 08 '14 at 03:01
  • 1
    @GrandmasterB I think that's the most correct answer so far. Can you post it as an answer also? – 53777A Dec 08 '14 at 08:07
  • 2
    Datalog is actually used in some very creative ways: http://www.cs.cmu.edu/~aldrich/courses/654/tools/bierhoff-bddbddb-05.pdf – SK-logic Dec 08 '14 at 11:45

4 Answers4

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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • 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 07 '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.

James Snell
  • 3,168
  • 14
  • 17
  • 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 `join`s 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 07 '14 at 16:21
  • 3
    @amon That sounds like the start of a good answer :-) – svick Dec 07 '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 07 '14 at 17:51
  • @DylanMeeus - Yep. And remember, the fact that people don't ACTUALLY understand a given SQL query doesn't mean they don't THINK they understand it, and proceed accordingly. Then the thing gets done (broken, but done). – Michael Kohne Dec 07 '14 at 22:40
  • 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 08 '14 at 08:04
  • What's regex got to do with anything? – James Snell Dec 08 '14 at 09:14
  • 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 08 '14 at 09:44
  • 1
    To be honest that just smacks of sour grapes. – James Snell Dec 08 '14 at 10:16
  • 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 08 '14 at 10:53
  • 1
    @53777A, I think that similar to what amon and DylanMeeus said about SQL, basic regexes are very approachable to beginners. You are probably thinking about regex use for parsing and validation, but often much more simple regex expressions are used in businesses to perform searches and matches in actual text. These can be quite "easy" to read and modify. The RegEx syntax is almost unique in the fact that it can be learned by parts on a "need-to-know" basis and thus has an extremely low barrier to entry. – yoniLavi Dec 10 '14 at 18:27
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).

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

dave
  • 2,466
  • 15
  • 21