
Prolog's Death (2010) - vector_spaces
https://synthese.wordpress.com/2010/08/21/prologs-death/
======
mjn
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](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.

------
roenxi
> 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.

~~~
TimTheTinker
Prolog may suffer from a lack of popularity, but I'd argue that's not because
it's lacking in power as a means of expressing an idea. Nor is it due to a
hardware paradigm mismatch.

Lisp and its variants (especially Clojure) enjoy increasing popularity for all
sorts of general-purpose use. Lisp is merely a particular notation for
expressing lambda calculus, and is rather far removed from the realities of
Von Neumann hardware.

I'd argue Prolog's demise is due to three facts: (a) the sorts of ideas _best_
expressed in Prolog have diminished due to new languages becoming available,
(b) the remaining ideas best expressed in Prolog are only applicable to a
narrow set of problems, and (c) Prolog itself isn't the most ergonomic
language to use, so it isn't often people's first choice when alternatives are
available.

~~~
SOLAR_FIELDS
Can you elaborate with an example or two? I’ve always been fascinated by
Prolog and thought of it as a language that is very well suited to a specific
class of problems. It would be interesting to know what class of problem
Prolog excels at and why newer languages or new features in existing languages
can do what only Prolog did before.

~~~
TimTheTinker
I'm afraid I can't -- sorry. I'm not a Prolog practitioner. My above
observations are just culled from what I've read over the years. I suspect
some kinds of expert systems remain best implemented using some Prolog.

Perhaps someone who uses Prolog regularly can chime in.

------
YeGoblynQueenne
>> 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.

~~~
segmondy
most people don't know how to debug prolog because they never got taught her.
it has debugging facilities, even GUI debuggers.

[http://www.swi-prolog.org/pldoc/man?section=debugger](http://www.swi-
prolog.org/pldoc/man?section=debugger)

here's an example of a trace from a CLI section.

[trace] ?- animal(X). Call: (7) animal(_G1588) ? creep Call: (8) is_true('has
fur') ? creep ^ Call: (9) format("~w?\n", ['has fur']) ? creep has fur? ^
Exit: (9) format("~w?\n", ['has fur']) ? creep Call: (9) read(yes) ? creep |:

Most don't understand the standard 4-port prolog (call, exit, redo, and fail.)
making it hard to grok what's going on.

[http://www.swi-
prolog.org/pldoc/doc_for?object=section(2,%27...](http://www.swi-
prolog.org/pldoc/doc_for?object=section\(2,%272.9%27,swi\(%27/doc/Manual/debugoverview.html%27\)))

~~~
YeGoblynQueenne
That's not the fault of the language though. If you get taught, say, C# and
you 're never taught how to debug it you'd have the same problem.

The four-port debugger takes some explaining, but it's not the end of the
world. It's actually a very conceptually simple way to understand Prolog's
execution model. It's a shame that it's not taught more often.

------
normalhuman
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.

~~~
nerdponx
I feel like we will end up with a hybrid approach. Powerful statistical models
woven together with some kind of logic system..

~~~
marcosdumay
Well, it's hard to understand why, but for some reason everybody isn't
expecting this.

The hype goes on waves, "symbolic AI solves everything!", "no, numeric AI
solves everything!".

------
PaulHoule
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.

~~~
mmarx
> 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.

Datalog as a language is really just one very specific form of rules (first-
order horn implications containing just constants and variables, where each
variable in the conclusion also occurs in the premise), and every Datalog
program (i.e., every set of rules) is guaranteed to have a finite, universal
model.

[0] Ceri, Gottlob, Tanca. (1989) What you always wanted to know about Datalog
(and never dared to ask). IEEE TRANSACTIONS KNOWLEDGE AND DATA ENGINEERING.
[1] Abiteboul, Hull, Vianu. (1994) Foundations of Databases: The Logical
Level. Pearson.

------
gavanwoolery
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)._

~~~
YeGoblynQueenne
Prolog is not a good language for querying databases (if that's what you mean
by "query language"). Foe one thing, it lacks a SELECT statement or list
comprehensions and the like. If you want all results of a goal, you have to
use one of the bagof/setof/findall predicates, or roll your own.

On the other hand, Prolog programs are logic theories (as are Prolog queries)
and their executio is a proof. The range of programs that can be expressed in
Prolog is the set of programs that are computable by a Turing machine. So yes,
Prolog is a programming language. Whether it's "terrible" or not is up to
personal taste.

I mean, I don't konw of an objective measure of what makes a programming
language "terrible".

~~~
marcosdumay
Software has evolved on a direction where sending sets around is natural. That
is no evidence that sending theorems around is problematic, it's just that
current communication implementations happens to be very data-friendly and
logic-unfriendly.

There is probably a very human reason for that, but mathematically both
representations are perfectly replaceable.

------
nemoniac
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.

------
Glyptodon
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.

------
derefr
> ...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.)

~~~
jcranmer
Declarative programming in general is notorious for being difficult to debug.
SQL is the only language I can think of where this notoriety doesn't come up,
and I'm honestly not sure if that's merely because I've never interacted with
anyone who has had to deal with sufficiently complex queries. But the insanity
that's involved with complex regular expressions, parser generators, even
Python's decorator system in complex declarative projects (e.g., some build
system tooling I've worked on) is commonly complained about.

~~~
hodgesrm
The standard 'debugging' problem in SQL is query optimization, namely figuring
out how to make a query return in seconds instead of a week. Many engineers
simply can't solve it, so a typical solution is to hand it over to a DBA and
go have coffee.

------
dang
Discussed a bit at the time:
[https://news.ycombinator.com/item?id=1624725](https://news.ycombinator.com/item?id=1624725)

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

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

------
sgt101
>"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.

------
tingletech
needs a (2010)

~~~
dang
Added. Thanks!

