Hacker News Reader

Comment by rhelz | Hacker News Reader

Nicely done. Prolog is killer for database programming/querying and parsing/formatting. Since these are not exactly "niche" tasks, its kinda sad that prolog isn't more popular.

View on HN

One reason it is not more popular is that it was, but then its Datalog subset, and supersets of Datalog that are different than Prolog, took a lot of that use from it. (Often with the Prolog syntax removed since it is frequently embedded in other languages, so it becomes a semantic rather than syntactic subset of Prolog.)

There does at least seem to be a recent uptick in popularity and interest in Datalog, which expresses a more constrained form of similar concepts specialized on data management tasks. Not as general purpose as Prolog, but more suitable for a database environment.

(Also here's a gratuitous plug for my employer's product in a similar vein: https://docs.relational.ai/rel/intro/overview)

Wouldn’t Datalog be a better alternative?

On one hand, Prolog is more powerful than Datalog. But on the other hand, Prolog is more powerful than Datalog.

With great power comes great irresponsibility.

Query: morepowerfullthan(Prolog, Datalog).

yes; yes; yes; yes; yes; yes; yes; yes; ...

Just as C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

In this case, it's even worse. Prolog is computationally complete. With everything that comes with rice's theorem. Every non-trivial property of a program being generally undecidable.

Datalog, on the other hand, isn't. It's terminating, like SQL. And many program properties are indeed decidable.

Datalog is great for database programming, and since it is a restricted subset of prolog, a datalog comes in every box of prolog :-)

Aren't there significant differences in implementation between a Datalog system and Prolog running similar rules, though? Bottom-up vs top-down eval, is what I read...

Classically, yes, but most prolog implementations these days support a tabled search strategy as Datalog typically does.

Sort of.

Because of it's restrictions it traditionally uses different search/resolution strategies than Prolog. And in the other direction the SLD resolution strategy Prolog traditionally uses can fail on syntactically valid Datalog (clause ordering issues).

That said, the big Prolog implementations all support multiple resolution strategies although I suspect there are a lot of various optimizations Datalog squeezes out of it's restrictions that let it handle things that might not be reasonable in a given Prolog.

Good point; in the olden days of prolog only the SLD search strategy came out of the box, and you had to roll your own if you wanted others. However, happily a lot of the tabled programming research from the XSB prolog group (and others) has osmosed out into the mainstream prolog implementations by now.

> great for database programming

Can you elaborate on what you mean by this? Like, custom database implementations? I wrote a little bit of Prolog in college and thought it was neat but I haven't looked at it since. I've seen Datalog mentioned recently in relation to biscuits, a technology I think is incredibly cool but that I don't fully grok.

Yes. Datalog is not Turing-complete; thus is much easier to reason about, and good query optimizers can be much more aggressive. Once you introduce cuts (as in prolog), you have to throw a lot of that out the window. But Datalog is a subset of prolog.

Reply on news.ycombinator.com