Lambda the Ultimate

There are probably many reasons why Prolog, or logic programming, isn't as popular as some might hope. I'd say that one of the top 5 reasons is that the barrier to entry is relatively high. It certainly took me much longer to learn enough logic programming to be able to read and write the simplest of programs in Prolog than in any other programming language I've learned so far. I'm not saying that Prolog would be inherently difficult, but I'm saying that it may require a significant investment of time and effort to be able to program in it. People who are not willing to invest that much time in learning a language will probably not use Prolog.

[Prolog] seems to be extremely well suited to writing embedded languages[, program analyzers, interpreters, and compilers] and has good facilities for meta-programming and reflection.

All of this is news to me - although this is probably no more than a reflection of my general cluelessness about the subject. I'd always assumed that Prolog was for constraint-solving, period, much as a few years ago I assumed that Lisp was for writing Eliza in. Does anyone have any links on the subject of writing embedded languages in Prolog?

For starters, you might find this interesting.

Strangely, my experience of Prolog was the opposite: it didn't seem to have very much there. It seemed to be good for toy problems in the NLP domain (my main interest in it), but for non-trivial sets of data, it was tedious to encode everything, the performance wasn't that great, and if you changed your mind about your domain representations it was tedious to change.

It is possible that there was some better way of doing things that I never learned, but even in Computational Linguistics (as NLP has been renamed ;-) ), Prolog use seems to be way down.

From my point of view, the question should be reversed: why does Mark Watson think that more people should be using Prolog? Does the endorsement of a failed, pie-in-the-sky project in the 80s in Japan really carry that much weight? ;-)

Prolog meta-interpreters are a cool part of Prolog programming, by the way. I don't think they are directly relevant for this discussion, but hey we are just having fun around here, aren't we?

Perhaps this might be due to different backgrounds. My original interest in programming was in (soft) real-time graphics. In the past I never was very interested in (relational) databases (they are simply not the first choice when it comes to representing data in real-time graphics applications). Also, backtracking algorithms are generally not very efficient or predictable (bad worst case bounds), so they don't come up in (soft) real-time systems very often (or more likely, you tend to avoid such non-deterministic searches).

It seemed to be good for toy problems [...]

Prolog doesn't seem to be a language that was explicitly designed for large scale programming.

but for non-trivial sets of data, it was tedious to encode everything [...]

Do you mean that designing a representation (structure) for the data was difficult? If so, then I don't find it particularly surprising.

if you changed your mind about your domain representations it was tedious to change.

Was this basically caused by extensive use of pattern matching? If so, then a small immediate relief might be to consistently use selector predicates instead of direct pattern matching. I wonder whether object-oriented logic languages attack such problems.

why does Mark Watson think that more people should be using Prolog?

I think that Prolog, and declarative domain specific rule based languages, have certain inherent advantages / important applications. For example, if you were to implement a type checker, you might want to use a language like Prolog to encode the rules of the type system and have an excellent compiler for the rule based language to ensure that the type checker will be efficient rather than translate the typing rules to a less declarative language by hand.

I think that Joe Armstrong still digs out the (20-odd year old) Prolog implementation occasionally to experiment with things.

Most likely. I have spent most of my career building database apps. I think that by the time I looked seriously at Prolog I definitely had studied formal logic and I may have already done some functional programming (memory fuzzy here).

Do you mean that designing a representation (structure) for the data was difficult?

Design a good one anyway. ;-) Basically, if you have a fairly mature logical model for your domain and you want to experiment with it, you're ok. Or if you are playing with a small data set and want to experiment with the model your are ok.

Part of the problem is the fine grain of the data. It is as if you had to build a full relational database one piece at a time:

relation(key1, value1) 
relation(key1, value2) 
relation(key1, value3) 
relation(key2, value4) 
.
.
.

I think that Prolog, and declarative domain specific rule based languages, have certain inherent advantages / important applications.

Is it's "trick" really that good or unique? In general, I think you could probably replicate its functionality in a more "general-purpose" language that would allow you to fine tune matching, backtracking, etc. to your particular needs, and also take advantage of the other "tricks" available in the language.

For the same problem domain (if I ever find the time to devote to CL again ;-) ) I would probably want to try using Haskell or SML.

Dynamically typed = unpopular? Hmmm, that almost sounds like a "cognitive factor" argument. ;-)

Also see On the quality of available Prolog implementations.

I was only answering for myself.

Anyway, the question concerns popularity, which is already unavoidably "cognitive".

Also, Microsoft embeded a small Prolog interpreter in the Windows NT network configuration. See this story.

To Bagnara's good "Balkan shacks" argument, I'll add only that Prolog lived in a time of "hilltop kings" language design. ;)

If you wanted to work with language X, you had to do _everything_ in X. Languages claimed ownership of memory, cpu, signals. No embedding, and when an implementation deigned to offer a foreign function interface, it was invariably half-baked and rotten.

The usual "whole program" barrier to entry problem of monolithic implementations gets worse when the language is unfamiliar, worse still when the language's implementations are inconsistent and flakey, and perhaps finally deadly when the language is itself something of a task specialist.

Turbo Prolog lives on as Visual Prolog.

This is an important point. Prolog's idiosyncracies make it less appropriate for system programming, but extremely useful for specific kinds of tasks.

However, this explanation isn't enough. There are embedded Prolog engines out there, and yet even when people decide to use a rule based engine, or expert system shell, they often decide on something other than Prolog. See the discssion of rule based programming here.

Two more comments. First, for the record, I am a very fond of Prolog. I just odn't think it scales. Mercury is an interesting alternative.

Second, I was surprised to hear people found Prolog difficult at first. It always seemed to me that for the first couple of weeks Prolog is very natural. It becomes hard when you try to solve a problem not in its domain that thing become difficult (e.g., when you want to add a user interface to your rule-based program).

In fact, all the times I tried to teach Prolog I was able to get people to understand the approach, and write working programs in less than two hours. You just have to remember to start by hammering in the closed-world assumption.

Maybe they are too busy with teTeX?

Elucidation of above comment - from the article:

The criteria for package inclusion remain problematic. In my previous review I complained that Mandrake included some packages that might seem irrelevant or with a low priority, while leaving out some very important (in my opinion) packages. This is, sadly, again the case. You can install languages such as Prolog or SmallTalk, an obscure typesetting system (lout), and such things from the CD; but packages such as the teTeX documentation have been left out of the CD. I wonder which is more important: a prolog environment or the documentation of the teTeX distribution? One is a really obscure (now) language, while the documentation of teTeX is absolutely essential for any LaTeX user. Shipping teTeX without the docs is tantamount of having a LaTeX installation without a local guide.