[octo_t]

I absolutely love programming in Prolog. I've never needed to write anything large in it at all (which is where most prolog interpreters fail), but when it comes together so beautifully at the end, its quite amazing.

I thoroughly recommend "The Art of Prolog" which is an engaging and fun read.

[dhkl]

When I first learned about Prolog in AI class, the first thing that struct me was how beautiful Prolog/logic programming solutions are.

In non-declarative languages like Java, you have to build up the different pieces of computations, while you keep maintaining a mental picture of how the various pieces fit together.

In Prolog, you declare the entities and the relationships/constraints between them, and the system will build the solution for you through inference.

David Nolen has done some awesome work writing the core.logic[1] library, which makes those Prolog gooodies accessible to Clojure programmers.

-- [1] https://github.com/clojure/core.logic

[arethuza]

I seem to recall that one of the issue with Prolog is that, above a certain level of complexity, you can't really write purely declarative Prolog "progams" - you have to start considering the procedural aspect as well which (in certain cases) can be non-trivial.

[yaantc]

(See my other comment below too on this topic)

You indeed have to understand how the Prolog engine works in order to structure the declarative statements of your code in a way that will lead to an efficient execution.

A way to see a Prolog programs is as a sequence of facts and statements, and at least one query. The Prolog engine will then search for a solution that fits the given facts and requirements and answer the query. In a way the Prolog engine will search a space of possible answers to the query to find the one(s) that match the given facts and requirements. The key to speed is to structure the facts and statements that the search will fail as early as possible when a wrong path is taken. This amount to pruning the useless parts of the search space as aggressively as possible, so that the Prolog engine does not waste time evaluating options that are doomed in the end.

Before getting this I was often frustrated with apparently nice and correct Prolog programs that took forever and in effect just looked stuck (at some point you just stop waiting and abort the execution). I guess it's a pretty common frustration when beginning in Prolog. But once you get it, it's possible to come up with efficient code. It's still scary to see that some small changes in statements ordering can lead to dramatic difference in runtime. You can have big differences in performance for imperative programming too, but it's rare that it's so bad that a first implementation is completely useless. In Prolog it's quite common. And the way to optimize Prolog performance is very specific, you need to learn to anticipate how the engine walks the search space. I guess it's one of the big roadblock in the practical use of Prolog.

[qohen]

A book -- in fact, the book -- that covers this sort of thing is Richard O'Keefe's The Craft of Prolog, which, like Sterling & Shapiro's The Art of Prolog, is put out by MIT Press.

[lake99]

Mercury[1], a derivative of Prolog does away with these cuts. So I guess that these declarative short-circuits in Prolog are just a fault that arose because some things were not thought through in the creation of Prolog.

[1] http://mercurylang.org/information/doc-release/mercury_trans...

[popee]

At university we had to learn prolog and for me (C/perl) it was mind blowing experience. Fact that you are writing program as bunch of logical predicates was kind strange at first, but when you get used to it, it's such a great and powerful tool. Also, learning things like unification was just wooow. So, I'd recommend prolog to every programmer, especially today when most people use yet another standard language. On the other hand prolog is sooo out of the box.

[pjmlp]

I really enjoyed learning it back in the day (94-99), specially given that many of our teachers were into Prolog and ML languages.

Sadly I seldom saw it being used commercially.