[sproutini]

The problem with Prolog is that it's based on unification, and small unification engines can be expressed in a few lines in any functional programming language.

That narrows down the already small niche where one would choose Prolog by probably a few orders.

[tpoacher]

Is this in the same sense that "one could write lisp in 99 lines of c"?

In my opinion, this does not imply that proper lisp (and correspondingly prolog) implementations are useless, just because a simple implementation can be written in a different, "more expressive" language.

[jhbadger]

There is a very practical embedable logic-programming engine called miniKanren for many programming languages that can be used to add the logic-programming techniques of Prolog to other languages.

https://en.wikipedia.org/wiki/MiniKanren

There's a great book in the same series as the "Little Lisper"/"Little Schemer" books called "The Reasoned Schemer" that uses MiniKanren with Scheme.

[sproutini]

No, not really. A lisp in 99 lines of C would barely be useful. In contrast, Prolog mostly shines where you need reasoning/unification over a database of facts -happens pretty often,- but that's just too easily expressed in any proper functional language. And with a bit more pain in an imperative/OO language.

[YeGoblynQueenne]

What makes Prolog, Prolog is not unification on its own but SLD-Resolution with unification, where "SLD" stands for [L]inear Resolution with a [S]election rule restricted to [D]efinite clauses. If you know your Resolution typology, that means soundness and refutation-completeness (or completeness with subsumption) [1].

I don't think I've ever seen a discussion of Resolution in functional programming textbook implementations of "Prolog". They typically just bodge some depth-first search with backtracking and unification in polish notation and call it "Prolog", or "logic programming". A bit like if I wrote a "lisp" with eval(X):- call(X), then completely ignored all that jazz about lambda calculus and concentrated on garbage collection and linked lists.

A good starting point instead, if one wishes to understand Prolog and not just dismiss it out of hand, is to try and understand Resolution, and what unification does for Resolution, and why it ended up in Prolog (and how) in the first place. I'd start, well, at the beginning:

A Machine-Oriented Logic Based on the Resolution Principle

https://www.semanticscholar.org/paper/A-Machine-Oriented-Log...

Where you can follow the progress from ground Resolution, to unification, the Resolution theorem, and all the way to the (pre-modern) Subsumption Theorem. It's a long way to Prolog from there, but that's where it all begins.

_______________

[1] Although Prolog implemented by DFS is not complete if Prolog implemented by DFS is not complete (etc).

[btbuildem]

For some, how a language is implemented seems to be the paramount thing.

For many, how the language faces the user, how its paradigms fit the problems at hand and the user's mode of seeing the world, that is more important.

These days, with the terabytes the petaflops and the megajoules, it might be even less relevant how the gears are turning inside the black box.

[kazinator]

> expressed in a few lines in any functional programming language

I don't think that performs like a proper Prolog engine on larger problem.

Real Prologs work by compiling to something called the WAM (Warren Abstract Machine).

[z5h]

I've been using Prolog daily for the past 1.5 years. I've also implemented and used a Kanren in Elm, and there is simply a world of practical difference.