Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am not sure how you could meaningfully compare Prolog and SQL. Both are declarative languages, but that's where the similarities end. SQL is for interacting with databases, whereas Prolog is, more or less, a language that you can write regular programs in.

Perhaps the Prolog terminology of "queries" and "database" gave you the impression it has something to do with databases that store data. It doesn't. The query is over logical terms, and the database is a collection of Prolog facts.



Both languages are relational, which is fairly unique among programming languages. For example you can define a graph in Prolog like this:

  edge(1, 2).
  edge(2, 3).
  edge(3, 4).
These edges are naturally undirected. Similarly, in SQL you can have a table "Edges":

  +——-+——-+
  | 1 | 2 |
  | 2 | 3 |
  | 3 | 4 |
  +——-+——-+
which also imposes no strict direction. In non-relational languages you have to define maps for both directions.

However, in Prolog you can easily define something like reachability using recursion:

  reachable(V, V).
  reachable(V, W) :-
    edge(V, U),
    reachable(U, W).
In SQL you would have to join the "Edges" table with itself an unknown number of times. I suspect this is possible somehow but definitely less natural.


The reachable predicate on your 'naturally undirected edges' treat them as directed;-) I would rather say that your edges are naturally directed, and then you can add a clause to make them undirected.


I get what you're trying to say, that in Prolog you are able to lookup structures by their shape, and not by some pre-defined path, as in other languages, so you can do both `edge(1, A)` and `edge(A, 1)`.

But the graph in your example is still directed, simply by the virtue of predicate arguments being ordered.

So your example misses two rules to be correct.

  reachable(V, W) :- edge(V, W).
  reachable(V, W) :- edge(W, V).
  reachable(V, W) :-
    reachable(V, U),
    reachable(U, W).
Alternatively you could introduce

  edge(V, W) :- edge(W, V).


> In SQL you would have to join the "Edges" table with itself an unknown number of times.

In fact fore recent SQL standards have added extensions for these kinds of recursive joins. (And some databases like Oracle, DB2 have had recurse or tclose operators for a long time.)

I don't think they're particularly elegant -- they're awkward like most things in SQL because SQL's syntax sucks -- but the ability is in fact there these days.


How are the two any different? Can you come up with any differences in expressive power between the first-order logic/Horn clauses that underpin Prolog and the relational algebra that underpins SQL?

I wonder whether you're accurately portraying the structural foundations of either Prolog or SQL.


Relational algebra is not Turing complete. SQL gets Turing completeness by means of various additions/alterations (sometimes pretty weird ones about that). So the foundations are pretty different, and I think this is obvious if you tried to start writing typical programs in SQL/Prolog.

Now, some people argue you might want a less expressive logic programming language, especially datalog, so this isn’t a knock-down argument, but it’s a pretty big difference.


> Relational algebra is not Turing complete.

yes it is

> SQL gets Turing completeness by means of various additions/alterations.

Sigh. No. SQL was a subset of relational until recursive CTEs were included to round it off properly.


> yes it is

Can you double check and/or give references? Because I specifically doubted my memory here, and everything I found online before posting matches what I thought—-standard relational algebra is not Turing-complete (hence relational queries are guaranteed to terminate).


I need to do some more checking, but you are right. The original relational algebra was a subset of first-order predicate logic. Adding recursion I believe just gave it parity with 1st order PL, so fulsome apologies and thanks for pointing out my error.


Fair Q, I may be confusing relational and predicate calculus. Will check and get back. Apologies in advance if I'm wrong.


You want to learn or to debate :)


I get where you're coming from but your point seems flippant. My answer is "debate" -- and looking at the rest of my subthread, some commenters have raised some great concrete areas around Prolog's unique strengths, which I've found helpful!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: