Comment by hjek | Hacker News Reader

Comment by hjek | Hacker News Reader

See also Racket Datalog: https://docs.racket-lang.org/datalog/index.html

I dig logic programming, but I wish Racklog had better (or any?) constructs for storage. Racket Datalog can serialize a theory[0], but that still means you'll have to write it in its entirety to the disk after any accumulation of facts.

In my opinion the SQL language is inferior to Prolog, but in most SQL systems incremental update isn't a problem.

Here's a comparison of SQLite with xml-files-in-a-zip-file[1] (and the zip-based file format has similar problems as serializing a Datalog theory):

> It is difficult to update individual entries in a ZIP archive. It is especially difficult to update individual entries in a ZIP archive in a way that does not destroy the entire document if the computer loses power and/or crashes in the middle of the update. It is not impossible to do this, but it is sufficiently difficult that nobody actually does it. Instead, whenever the user selects "File/Save", the entire ZIP archive is rewritten. Hence, "File/Save" takes longer than it ought, especially on older hardware. Newer machines are faster, but it is still bothersome that changing a single character in a 50 megabyte presentation causes one to burn through 50 megabytes of the finite write life on the SSD.

[0]: https://docs.racket-lang.org/datalog/interop.html#%28def._%2...

[1]: https://sqlite.org/affcase1.html

There's a new Datalog [1] implementation written in the language of linear algebra (similar in nature to the ideas behind GraphBLAS [2] "graph algorithms in the language of linear algebra"). Evidently the linear-algebra approach works well for Datalog too -- the paper below shows it's the fastest Datalog implementation to date, several orders faster than the best Prolog engines.

NB: GraphBLAS runs in the recently-released RedisGraph. The Datalog linear-algebra approach is so close to simi-ring primitives in GraphBLAS. A Datalog implementation on GraphBLAS could be slick as hell. The GraphBLAS code is implemented by Tim Davis, and the code is pristine.

[1] A Linear Algebraic Approach to Datalog Evaluation (2017) [pdf] https://arxiv.org/abs/1608.00139

[2] GraphBLAS http://faculty.cse.tamu.edu/davis/GraphBLAS.html Discussion: https://hn.algolia.com/?query=GraphBLAS&sort=byPopularity&pr...

Hmm I'm fine with prolog, I love it, but I'm not sure how it can be used in practice. There are really efficient SQL implementationa like postgres that we already spent millions of dollars and man-decades developing. My guts would tell me whatever prolog implementation I'll use, they will not be as reliable as one of these battle tested technologies. Maybe there is an opportunity here, if there is a demand for prolog. Having seen companies where SQL was used very extensively for analytics, data storage etc I can't see how prolog wouldn't help. Of course there are cultural problems too, people know SQL, but only a tiny minority know prolog.

> Hmm I'm fine with prolog, I love it, but I'm not sure how it can be used in practice.

Well, that rings similar to what is said about Lisp sometimes, and I think it can easily be refuted by pointing to instances where it is being used in practice[0].

There are some problems that are fairly easy to solve in Prolog, but would be very difficult to express in SQL[1]. And recursive relations, which are at the core of Prolog, only made their way into SQLite 4 years ago[2].

My comment was specifically about those Prolog/Datalog implementations in Racket. Other Prolog implementations might be dealing sensibly with incremental updates (but I don't know).

> Having seen companies where SQL was used very extensively for analytics, data storage etc I can't see how prolog wouldn't help.

You can't see how Prolog wouldn't help, as in Prolog can only be an improvement over SQL?

[0]: https://www.youtube.com/watch?v=G_eYTctGZw8

[1]: https://xmonader.github.io/prolog/2018/12/21/solving-murder-...

[2]: https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que...

I think you misread my comment. I am pro-prolog but I'm skeptical of some of the details such as ACID complaint, being battle-tested, getting predictable performance etc.

> Well, that rings similar to what is said about Lisp sometimes, and I think it can easily be refuted by pointing to instances where it is being used in practice[0].

I don't think this is relevant. (I'm also a very strong fan of lisp). Most criticism of lisp is to the language itself. People acknowledge that lisp is theoretically possible to solve complex problems easily but they claim this slows us down in practice. This is not my claim against prolog. I think the language is pretty powerful, but I'm not sure if we can find something as rock solid as postgres.

> Prolog can only be an improvement over SQL?

Yes, precisely.

> I think you misread my comment.

Yea, I did misread a bit of it.

> I think the language is pretty powerful, but I'm not sure if we can find something as rock solid as postgres.

While PostgreSQL may be better for most projects, SWI Prolog is also usable for practical problems, although (if I'm not mistaken) SWI Prolog requires all facts to be loaded into memory, so there's a limitation in scale. And yes, I could't find any resources indicating whether the SWI Prolog database is ACID compliant.

But with Racklog and Racket Datalog it doesn't make sense to talk about whether they're ACID compliant as there's not yet any storage mechanisms, so they are not yet usable in any context involving persistent data. The limitations of those implementations are very different from limitations with Prolog/Datalog as such.

Racklog is not really Prolog - like the title says it's "Prolog-style" logic programming.

More to the point- SQL is a database language used to store and retrieve data, while Prolog and logic programming languages, like Racklog are languages used to reason over relations, which are naturally stored in a relational database.

So, with Prolog/Racklog, you get a database, plus an inference engine with all the power of the first-order predicate calculus. With SQL, you get a database.

> Racklog is not really Prolog - like the title says it's "Prolog-style" logic programming.

You can write Racklog with the Prolog syntax as well though.[0]

> So, with Prolog/Racklog, you get a database, plus an inference engine with all the power of the first-order predicate calculus. With SQL, you get a database.

That might be true for most Prolog implementations, but Racklog doesn't have a database (and that was what I was whinging about).

[0]: https://docs.racket-lang.org/racklog/Racklog_Module_Language...

Apologies, I think I assumed too much about Racklog's implementation.

However, what I say above is still true when it comes to most Prologs. The comparisons to SQL always seem to miss the point that, though Prolog terms are stored in a database, Prolog is not a database language.

Reply on news.ycombinator.com