
The Art of Prolog (1994) - tosh
https://mitpress.mit.edu/books/art-prolog-second-edition
======
nextos
It should be noted that under the open access tab one can download the book.

Aside from being one of my favorite programming books ever, and on par with
SICP and PAIP I think, the font they used is really beautiful [1]. The PDF
perhaps does not do it justice. On paper it's really crisp and pleasant to
read.

I hope MIT Press opens up The Craft of Prolog [2] too, a fantastic sequel to
The Art of Prolog.

[1] [https://docs.microsoft.com/en-us/typography/font-
list/lucida...](https://docs.microsoft.com/en-us/typography/font-list/lucida-
bright)

[2] [https://mitpress.mit.edu/books/craft-
prolog](https://mitpress.mit.edu/books/craft-prolog)

~~~
jml7c5
It looks like the PDF is a 1-bit scan, so the text is a bit wobbly. Though I
concur that Lucida Bright is lovely.

I wonder if the MIT Press — or the author — has the source files (presumably
LaTeX) somewhere. It would be a shame to have a low-quality scan as the
"definitive" archived version.

~~~
imglorp
The flyleaf (first ed, 3rd printing, 1986) says

    
    
        This book was set in TeX by Sarah Fliegelmann
        at the Weizmann Institute of Science
        and printed and bound by MIT Press
    

That might be another lead.

------
xvilka
If anyone is interested in learning Prolog I can recommend two very good
Prolog books: The Power of Prolog (from the author of the video)[1] and Simply
Logical: Intelligent Reasoning by Example[2]. I also recommend visiting the
Awesome Prolog list[3]. Worth checking also interesting extension of the
Prolog - Probabilistic Prolog, aka ProbLog[4]. And modern ISO-compatible
implementation in Rust language - Scryer Prolog[5].

[1] [https://www.metalevel.at/prolog](https://www.metalevel.at/prolog)

[2] [https://book.simply-logical.space/](https://book.simply-logical.space/)

[3] [https://github.com/klaussinani/awesome-
prolog](https://github.com/klaussinani/awesome-prolog)

[4] [https://github.com/ML-KULeuven/problog](https://github.com/ML-
KULeuven/problog)

[5] [https://github.com/mthom/scryer-prolog](https://github.com/mthom/scryer-
prolog)

------
mark_l_watson
I gave away most of my technical books a few years ago, but I kept The Art if
Prolog and about 50 other classics.

It has been a while since I worked with Prolog professionally, but the
memories are fond/good.

Good to see that the PDF is available for download.

For people who craft their code in languages like Python, Java, JavaScript,
etc., I recommend just playing with an alternative language, whether it be
Scheme, Common Lisp, Prolog, Haskell, ML, etc. Sometimes just a few evenings
working through tutorials on the web is enough to expand the brain.

~~~
Kototama
How did you decided that it was time to give away your technical books?

~~~
mark_l_watson
As inetsee said, it is because of space. I got rid of a whole wall of shelves
in my home office to make room for a meditation area and room to have my
instruments out and handy.

~~~
7thaccount
Instruments?

~~~
keyle
I take it Mark is a musician. Or he likes to have a room to probe with things?

Let's go with musician.

~~~
mark_l_watson
Exactly right. I play didgeridoo, American Native Flute, and guitar.

[1] [https://markwatson.com/fun/](https://markwatson.com/fun/)

~~~
7thaccount
Thanks Mark. I didn't know if it was music or electronics or what lol.

------
throwaway2380
I've been trying to push myself to learn Prolog, using this book, because
Prolog seems like a very elegant way of modeling the interactions between
business rules, compared to the bespoke functions I typically write during web
app jobs.

I have no complaints about the book, but I've been struggling to figure out an
easy setup for "Prolog as a web app backend." Typical Prolog implementations
are not designed to be used as concurrently-accessed databases. Datalog seems
to be a nearby technology that is more pointed towards that use case, but even
then, there seem to be scant few implementations of Datalog databases with
transaction support, and near zero that are open source.

RDF/OWL databases seem to be another conceptually-near possibility, but they
_also_ seem to have few implementations that are prepared for high-scale
concurrent access.

Overall, it seems that there is a decent amount of interest in "logic-type"
query languages as a curiosity, but little attention to implementations that
support use in OLTP business applications, which makes adoption difficult.

Does anybody have any advice?

~~~
pbh101
I recently participated in an online Prolog class by Anne Ogborn. It utilized
SWI-Prolog [2] and SWISH [3], and mentioned Pengines [4] for web. I haven't
used it personally, but that is the pointer I have for Prolog + web.

[1] [https://twitter.com/AnnieTheObscure](https://twitter.com/AnnieTheObscure)
[2] [https://www.swi-prolog.org/](https://www.swi-prolog.org/) [3]
[https://swish.swi-prolog.org/](https://swish.swi-prolog.org/) [4]
[https://pengines.swi-prolog.org/docs/index.html](https://pengines.swi-
prolog.org/docs/index.html) [5]
[http://pathwayslms.com/swipltuts/](http://pathwayslms.com/swipltuts/) [6]
[https://www.youtube.com/watch?v=JmOHV5IlPyU](https://www.youtube.com/watch?v=JmOHV5IlPyU)

------
sosilkj
I've got a few books like this now on my to-read list (SICP, etc).

But in a profession that revolves around getting jira tickets into the Done
column while my boss hovers over me with a stopwatch (so to speak), and then
cramming leetcode for interviews when it's time to hop from one shitshow for
the next ... I've come to the sad conclusion that, in this season of in my
life, I just can't justify spending the additional time on such books.

These books might make me "a better programmer" for some amorphous, platonic
definition thereof, but in the year 2020 will these actually help me to
materially progress career-wise?

~~~
daviddaviddavid
I can sympathize with this perspective. One strategy that I try to employ is
to find books which are both small and good. In the case of Prolog, Clocksin
and Mellish's "Programming in Prolog" falls in that category. The Art of
Prolog is a great book but it's a big book and you could probably spin your
wheels on it for years, whereas a smaller book can conceivably be digested
even if you have a crazy day job and kids and non-programming hobbies, etc.

Regarding just how it might make one a better programmer (while intentionally
not answering anything about how it can "materially progress" one's career), I
think that learning Prolog can make one a better problem solver because it
forces you to specify the solutions to problems in terms of their truth
conditions. This, in turn, makes you more likely to tackle problems by
constructing mini proofs. I find this to be valuable no matter the language or
language family I happen to be working in and it's a habit I definitely
learned from writing Prolog.

------
metafunctor
My favorite quote from the book:

In Prolog programming (in contrast, perhaps, to life in general) our goal is
to fail as quickly as possible.

~~~
johnisgood
And for people who may not have known: the initial version of Erlang was
implemented in Prolog, and the let-it-crash philosophy is central to Erlang.

~~~
im_down_w_otp
While both of the statements you made are true, the "let-it-crash" philosophy
of Erlang seem quite orthogonal to the "fail-fast" of Prolog.

"Let-it-crash" had to do with the idea that a wobbling process/service is
harder to design around than one that's just definitively dead and also that
most non-systematic errors in running programs are "Heisenbugs" (the problem
is transient) and restarting the process/service will make it go away.

In Prolog the point of "fail-fast" is to determine as quickly as possible if
some search branch can't possibly provide a True result, so that you don't
spend unbounded time searching for every possible version of false.

~~~
sitkack
I think these philosophies are complementary, I could easily see one being the
inspiration for the other, just are there are analogs between guard
expressions and pattern matching with logical predicates.

Ideas are contagious.

------
transfire
I will have to read this, should I fine the time.

I learned Prolog in High School, it was a challenge at first -- I didn't get
it right away. But when I did I was amazed.

Yet I have an ongoing problem with Prolog that I have never fully put my
finger on exactly -- it's something about how side-effects intermix with pure
logic. I find it makes the flow of activity hard to follow.

Can anyone else relate to this and perhaps explain it better?

~~~
tom_mellior
Do you mean side effects in the sense of I/O, or updating the database, or do
you mean the binding of logic variables?

------
rudolph9
Somewhat related is Curry [https://www-ps.informatik.uni-
kiel.de/currywiki/](https://www-ps.informatik.uni-kiel.de/currywiki/)

It builds off the concepts of prolog in a purely functional strongly typed
way. The main compiler, PAKCS, actually targets prolog. Hard to wrap your head
around without knowledge of Haskell but with taking a look at.

------
dang
See also:

2018
[https://news.ycombinator.com/item?id=18188003](https://news.ycombinator.com/item?id=18188003)

------
hagmonk

        DEBORDEMENT DE PILE

~~~
anthk
No, stack overflow is in the other tab.

------
sktrdie
I don't know prolog at all. Does anybody have a TLDR to what its pros & cons
are and why it isn't mainstream?

~~~
talideon
This is something that unfortunately doesn't have a straightforward answer.
Prolog ended up being _very_ influential, but its very nature meant it was
never going to become mainstream.

Prolog was intended to be a way to program using logic. It did this in a way
by encoding facts in a manner not dissimilar to a relational database; logical
statements about the world that resembled functions using Horn clauses (which
you can think of as mathematical functions, but applied to logic); and
unification, which is what links all this together. Unification is computation
via the idea that you have a set of data, a bunch of logical statements, and
you want to find everything in the data that satisfies those logical
statement.

If you know SQL, Horn clauses should sound a _lot_ like materialised views.

As to why it never really went mainstream, it's a matter of wrong place, wrong
time. It didn't help that the language needed a checkpointing mechanism
(referred to as 'cuts', and represented by '!') because the unification
mechanism could get confused and do much more work than it needed to, so
developers needed to put cuts in place to tell the interpreter where it could
avoid backtracking to try more solutions within a Horn clause.

If you want to get a taste for it, maybe give this a try:
[https://github.com/norswap/prolog-dry](https://github.com/norswap/prolog-dry)

Prolog is one of a small number of languages that people should learn even if
they never use it in a practical way.

~~~
YeGoblynQueenne
>> As to why it never really went mainstream, it's a matter of wrong place,
wrong time. It didn't help that the language needed a checkpointing mechanism
(referred to as 'cuts', and represented by '!') because the unification
mechanism could get confused and do much more work than it needed to, so
developers needed to put cuts in place to tell the interpreter where it could
avoid backtracking to try more solutions within a Horn clause.

Prolog backtracks when there are more solutions to a goal (think of a goal as
a query). Not because "unification gets confused". Unification doesn't have
anything to do with backtracking, rather backtracking is a mechanism to
represent the natural nondeterminism of logic theories, where multiple
variable instantiations ("bindings") might satisfy a formula.

So, when you enter a query at the Prolgo top-level (the console) Prolog will
try to find a set of variable bindings that refute your query in the context
of your loaded program. If it can, it will report "false", i.e. the query
cannot be satisfied in the context of the program. If it can't, it will report
"true", i.e. the query can be satisfied in the context of the program and it
will also report the variable bindings that make the query true. If there are
more than one sets of bindings that make the query true, you can ask for more
solutions. _At that point_ Prolog will backtrack and give you more solutions.

However, there is nothing forcing your program to be written so as to produce
multiple solutions to a query. It's entirely up to you and how you write your
program. You can write a program so that it's deterministic (succeeds or fails
exactly once) or not. The cut (!/0) is one way to _force_ a program to become
deterministic, but again that's not because anything gets confused. It's
because sometimes it's hard to write a program so as for it to be
deterministic. And sometimes you just have no idea why your program backtracks
and you pepper your code with cuts, hoping it will stop.

Which of course happens less and less as you get to understand how the
language works (and why it's a bad idea to put cuts everywhere in the first
place).

(It's a bad idea because it means you don't understand how your own program
works. Nine times out of ten you don't need to use it when you think you do).

(But I still use the cut all the bloody time because it's convenient).

~~~
talideon
> Not because "unification gets confused".

I know that, and I know the difference between a red and a green cut. However,
I was targeting my explanation towards somebody who is completely unfamiliar
with the language.

~~~
YeGoblynQueenne
But, saying that "the unification mechanism could get confused" and that
developers "needed" to use the cuts to control it makes it sound like
backtracking is somehow wrong or unwanted, or a defect in the language. This
risks confusing someone who is unfamiliar with the language.

