Prolog's Death (2010)

I wrote a somewhat related response at the time the "Who Killed Prolog" article this one is responding to came out: http://www.kmjn.org/notes/prolog_lost_steam.html

I agree that "easier to understand" could've helped. But things that are hard to understand can get uptake if they're big wins. The bigger problem in my opinion is that the number of cases where Prolog was a big win significantly decreased over time. When it appeared in the '70s, Prolog's declarative-programming approach based on logic had very few peers where you could do even simple textbook examples in as nice a way. But now even SQL (with features like recursive queries) can do a lot of the intro-level Prolog examples. It doesn't have the full logic semantics with unification, but a lot of problems don't need them. SMT solvers, LINQ, and rules engines like Jess/Drools are a few other declarative paradigms that ended up eating into some of what Prolog proponents once saw as its space. If Prolog were up exclusively against FORTRAN77 or K&R C, there would be many problems where it's a big win, but that's not the competition anymore.

> Arguably, the imperative programming paradigm is a more natural fit with the von Neumann computer architecture

Prolog's lack of popularity suggests that viewing a computer program as a pure (first order predicate) logic construct isn't a powerful way of thinking in general. That is a bit of a blow to all the programmers who seem to secretly want to be mathematicians because that in turn suggests that the logical aspects of programming are subordinate to hardware realities.

I've gotten a lot of joy out of the Neural Networking fad similarly eclipsing the logic-based AI people. Logic is important and it isn't going away, but reality has too much uncertainty for simple logic to work in practice. The statistically grounded approach makes me happier, and again computer hardware's power is overwhelming the efforts of the logicians to tie everything down to certainties.

Great language though, everyone should take a look at it to see what a different programming model might be.

>> That this process of computation is difficult to grok is especially noticable when you try to debug a Prolog program. Computations get undone when attempts at satisfying a goal fail; other computations get retried down different branches resulting in different unifications and worse of all, the order in which you wrote your clauses in the program makes a difference to how it gets executed and, indeed, whether any part of the program is reachable.

Actually, Prolog's clause selection rule that relies on clause ordering in the database is a boon when it comes to understanding backtracking during debugging ("tracing", please). You know that if you have two clauses of the predicate p/2:

  p(a).
  p(b).

And you make the query:

  ?- p(A).

The interpreter will first find the result p(a) and then backtrack to p(b). You know the order in which choice points will be created, that is. This makes it infinitely easier to trace a Prolog program than in a hypothetical (and very impractical) "purely" declarative langauge where clause order wouldn't matter.

Now, tracing a complex program with lots of recursive calls- that can be difficult. But that's not because of backtracking. It's because of the way Prolog "unfolds" recursion, which is something I'd have trouble explaining even after ten ish years of coding in Prolog. It's something you have to develop a feeling for, after tracing a sufficient number of recursive programs. Now _that_ I'd agree is a difficulty that may keep programmers from using the language. But- backtracking? I don't agree.

I've been reading so much about the death of symbolic AI and the complete victory of statistical approaches lately, that I suspect that a new symbolic hype-cycle is about to start.

I know this sounds counter-intuitive, but if you've been following such trends for a while, you might agree with me.

I think more pure logical languages have had an impact since Prolog, particularly variants of Datalog.

The thing with "Datalog" is that it is really a level of functionality that is implemented in various database query systems and not a well-defined language in and of itself. 15 years ago I remembered searching for papers about it and did not find so many, now it is hot.

The painful thing about Prolog, I think, is the mashup of declarative and imperative, it just doesn't come across as natural.

Prolog is a terrible "programming language" - and I would never try to use it as such. But it is (at least conceptually) an excellent query language. In that regard, it is much closer to SQL, as is its domain of reasonably applicable problems.

Clarification: I dont actually think prolog is terrible (I credit it as the most exciting language I have ever learned), I just mean its not intuitive to "program" with in the imperative sense of telling a computer what to do. What I mean by it is excellent as a query language is - given a set of data, it is great for drawing conclusions from that data (but not in the same way as a "traditional" query language like SQL).

Programming is about building abstraction upon abstraction.

If you don't understand the abstractions upon which you're building, you'll have trouble building upon them.

Unification and backtracking take some effort to grok. If you grok them you can put them to use in a clean and efficient way. If not then Prolog remains a mystery.

I think the complaint given about Prolog is about as applicable to SQL, which is widely used. Oddly, I could imagine it being easier to use as a query language than SQL in some circumstances.

> ...by far the biggest cognitive problem that they have with this language is understanding what the interpreter is doing at any point in time. Prolog’s attempt at being declarative ... is the problem: how to get a computer to do something without telling it what to do?

I mean, people use SQL just fine without understanding how the DB is going to accomplish their queries.

Maybe Prolog just doesn't have the same level of tooling as SQL for deducing "what's going to happen", e.g. an equivalent to SQL's `EXPLAIN ANALYZE`?

> The traversal of a search space in which choice-points are introduced whenever multiple clauses match the current computational goal and a process of (possibly partial) variable instantiation ... and worse of all, the order in which you wrote your clauses in the program makes a difference to how it gets executed and, indeed, whether any part of the program is reachable.

Some people (more than use Prolog) use Erlang—even the parts like chained binary pattern-matching†—just fine. And some people (still more than use Prolog) use the MLs just fine, too, including functional combinators and passing around monadic bindings, despite this playing utter hell on determining "whether any part of the program is reachable."

† `foo(<<A/32,B/A,Rest/binary>>)` — an Erlang clause-head which takes a binary string, and attempts to unify the variable A with the first four bytes of it, and B with the next variable-A bytes of it, and Rest with, well, the rest of it. I.e. A is taken as a uint32 and used to calculate the bounds of a slice on B, all during the attempt to pick a clause to execute. This is common, idiomatic code.

> That this process of computation is difficult to grok is especially noticable when you try to debug a Prolog program. Computations get undone when attempts at satisfying a goal fail...

People write Solidity code for the Ethereum VM just fine. (In fact, this one is kind of hilarious; Prolog is less popular than even an arcane programming environment like the EVM—where all function calls are implicitly nested MVCC transactions that roll back any side-effects upon their Turing-machine substrate upon any trap or fault, including even rolling back the emission of logging statements and the reservation or nullification of memory.)

Discussed a bit at the time: https://news.ycombinator.com/item?id=1624725

Personally I have only used Prolog in an academic context. I'd be curious to hear stories of people using it beyond that context.

All that hype on property based testing is just moving prolog to different platforms

>"worse of all, the order in which you wrote your clauses in the program makes a difference to how it gets executed and, indeed, whether any part of the program is reachable"

That's because the algorithm that prolog uses to do unification uses committed choice - if the logic could be run using efficiently grounded answer sets then the behaviour could be made consistent and that would make the semantics a whole lot clearer. Especially if ! was done away with as well.

needs a (2010)