
Ask HN: Who/What will do for Prolog what Clojure has done for Lisp? - fogus
This question is inspired (i.e. stolen) from Alex Miller at http://twitter.com/puredanger/status/19451154832293888.<p>Whether you like Clojure or not, it's difficult to deny that it's generated a lot of buzz for Lisp in general.  As a nice side-effect, there has been a rise in the number of organizations willing to take a chance on using Lisp for their products and services.<p>I see some parallels between Lisp and Prolog as families of programming languages.  There are likely as many hobby implementations of Prolog as Lisp.  Likewise, there is a gross misunderstanding of Prolog and Lisp among the general programmer population.  Also, it's unclear how to get started with Prolog and Lisp concerning: implementations, IDEs, documentation, and gurus.  To varying degrees, Clojure provides a solid answer to these common misunderstandings for Lisp, but what about Prolog?<p>Where is the logical successor to Prolog?<p>Some potential candidates are: Oz, Mercury, some sub-Prolog implementation embedded in another language, some other logic language altogether (e.g. Datalog).<p>Thoughts?
======
slashcom
Prolog has its limitations, but it still stands out as one of the oldest,
influential and important declarative programming languages.

IMHO, it's hard to say what is the natural successor to Prolog. For all that
it shares with Lisp, it definitely has never shared even a fraction of the
popularity. They have two entirely different approaches and purposes though,
so this isn't terribly surprising. Even if someone does create a new Prolog
ala Clojure, it would probably still remain in academia.

I think a better question to ask is what direction is declarative programming
headed in? Prolog is just one language in this field, as are some of the
Prolog-alternatives listed by the OP. Remembering that SQL is also a
declarative programming language, I believe that declarative languages are far
from dead; it's a common paradigm, just not one we hear a lot of buzz about.

So all this said, it may be that Prolog doesn't necessarily need a successor.
It does it's job well, but logic-based declarative languages are inherently
too specialized to expect anything causing a surge of popularity.

One interesting variant of declarative programming is called Answer Set
Programming. (<http://en.wikipedia.org/wiki/Answer_set_programming>). It's
particularly good at modeling and solving NP-hard search problems, usually has
Prolog-esque syntax, but does well on programs where Prolog would infinite
loop (e.g. p :- not q. q :- not p.). As a disclaimer, I'm just beginning
research in ASP. :)

~~~
_delirium
I've also switched to ASP, largely because of choice rules plus filtering. You
can write things like:

    
    
       { active(A) } :- thing(A).
    

Which says that for all things A, active(A) is a free choice of true or false,
constrained by the requirement to be consistent with all other clauses in the
program. That lets you do abductive reasoning, e.g. find an explanation, plan,
or cause from a possibility space, consistent with the other asserted facts.

You an also write pure constraints, like:

    
    
       :- active(duck), active(cat).
    

Which says to reject all answers in which both _duck_ and _cat_ are
simultaneously asserted _active_. This allows an overgenerate-and-filter style
of programming, where you use choice rules to generate everything in a
possibility space, and then constraints to filter out the ones you don't want.
Prolog doesn't really naturally support that style of programming, though
certain kinds can be hacked in with Prolog+CHR, or with one of the CSP
extensions.

The main downside in my experience is that ASP doesn't do well on large
programs, even large-but-simple ones that Prolog handles well, due to the fact
that ASP is grounding everything to the moral equivalent of giant SAT
problems. Particularly if you use numerical reasoning over non-tiny ranges.
Say, you have some sprites on a grid, and at each time, each sprite has
exactly one X/Y position:

    
    
       canvas_x(0..799).
       canvas_y(0..599).
       timestep(0..99).
       sprite(mario;luigi;babomb).
       1 { pos(S,X,Y,T) : sprite(S) : canvas_x(X) : canvas_y(Y) } 1 :- timestep(T).
    

A program like that totally blows up due to the 800 x 600 x 100 x 3 ground
instantiations of _pos_ , particularly if _pos_ is then referenced in a lot of
other rules. Since Prolog doesn't ahead-of-time compute all the ground
instantiations, it can avoid that in certain classes of programs (in this
case, you'd memoize the one _pos_ per sprite/timestep once you find it, then
use the cut operator to fail-fast on any other queries). There are papers on
avoiding this via a new generation of "first-order ASP" not based on
propositional grounding, but afaik no implementations exist.

~~~
jamii
The wikipedia page didn't really shed much light on what ASP is doing under
the hood. How does it differ from constraint solvers like
<http://www.gecode.org/> ? I know that gecode can handle problems like your
canvas example well by representing integer variables as sets of intervals.
What kind of problems would ASP have the advantage on?

~~~
_delirium
To some extent why you would use each of the declarative-programming paradigms
is still an open question imo. Lots of things can be modeled in several, with
pros and cons.

I think of ASP as "a semantically nicer Prolog, plus extensions". It
originated as one of the attempts to give Prolog's semantics, which are logic-
inspired but defined by its procedural goal-chaining algorithm, a clean
declarative logical semantics. The "stable model semantics" were one of the
competing ones, which became answer-set programming.

It depends on which constraint solver exactly, but two features not present in
most pure constraint-solving systems are the Prolog-style deductive reasoning,
and negation-as-failure. ASP lets you freely intermingle deductive reasoning
chains with constraints, rather than solving things as purely sets of
variables with constraints on them (though this is true of other approaches
that fall under the "constraint logic programming" heading as well). That lets
you do the generate-and-filter style, where you might have a complex deductive
logic program generating possibilities, and then effectively a constraint
program filtering from them (and the constraint part can sometimes call out to
deductive reasoning chains as well, since it's all the same language).

ASP semantics are sort of a superset of Prolog + constraint solvers +
abductive reasoners, where you can freely intermingle all those approaches. As
a result it isn't, yet anyway, the most efficient reasoner if you fall more
squarely into one of those paradigms. Here's an experimental ASP system that
also adds efficient constraint variables, though: <http://www.cs.uni-
potsdam.de/clingcon/>

------
Zak
I think Lisp was on an upswing before Clojure came around. Certainly, Clojure
has helped a great deal but Paul Graham's essays, Practical Common Lisp and a
proliferation of libraries relevant to the problems of today's programmers all
preceded Clojure and likely contributed to its popularity.

I suspect any significant gains for Prolog will be in the form of Prolog-like
DSL libraries for other languages. It looks like there has been some initial
work on one for Clojure, incidentally.

~~~
p4bl0
I agree with this. For instance there's already one for Racket, another Lisp
(Scheme), see here: <http://docs.racket-lang.org/racklog/index.html>

------
lsb
Constraint Handling Rules. CHR looks pretty interesting; I saw someone
describe an implementation of Fibonacci heaps in CHR[1] as "executable
pseudocode", and that's generally a sign of something useful.

[1]
[http://people.cs.kuleuven.be/~jon.sneyers/presentations/dijk...](http://people.cs.kuleuven.be/~jon.sneyers/presentations/dijkstra_chr.pdf)

~~~
_delirium
I agree they're useful, but CHR has been included as a standard part of most
Prolog implementations since the 1990s. It's possible it just hasn't been
fully discovered yet, but it's had some time to attempt to win.

------
brendano
There won't be a practical successor to Prolog.

Clojure is possible because Lisp already is a general purpose programming
language. Prolog isn't. You couldn't do many of the projects in Practical
Common Lisp with it. For example, imperatively changing mutable state is
_really_ hard to do, yet a very useful approach to many problems.

------
JabavuAdams
Nothing. Lisp's a general purpose multi-paradigm programming language, while
Prolog isn't.

If you need a rules engine, great, but there's no reason to shoe-horn general
programming problems into the Prolog model.

If you have JESS / Java or CLIPS / C, or generally, a rules engine for your
favourite language, what does Prolog bring to the table?

------
jeffmax
Has anyone looked at Pyke (<http://pyke.sourceforge.net/>)? It seems to
combine some of the ideas from Prolog with the ability to use Python when
necessary. We tried it and found it to work as advertised but the
documentation was hard to navigate.

------
fogus
Maybe Prolog needs its own Paul Graham?

------
malkia
not muxh familiar, but I thought erlang is close relative to prolog (never
programmed much in either)

------
locopati
While not familiar with Prolog, I understand that Erlang's pattern matching
comes from that world - so Erlang?

EDIT:

Here's a couple references for the Erlang/Prolog connection...

<http://www.erlang.org/faq/academic.html>

<http://hyperpolyglot.org/logic>

Also I found this while looking for the reference for the Prolog/Erlang
connection...

[http://www.slideshare.net/adorepump/learning-erlang-from-
a-p...](http://www.slideshare.net/adorepump/learning-erlang-from-a-prolog-
dropouts-perspective-presentation)

~~~
silentbicycle
Prolog's unification is quite a bit more powerful than Erlang's pattern
matching, though. You can't pass around uninstantiated variables in Erlang.
Erlang also discarded backtracking (because it mixes poorly with concurrency).

~~~
evgen
OTOH, it is possible to add some of it back in. Check out Robert Virding's
erlog (<http://github.com/rvirding/erlog>) and his explanation of how you can
add backtracking to erlang
([http://rvirding.blogspot.com/2009/03/backtracking-in-
erlang-...](http://rvirding.blogspot.com/2009/03/backtracking-in-erlang-
part-1-control.html))

