[downerending]

Here's a 60s attempt:

Prolog was (theoretically) a practical declarative programming language. You describe what you want done, and it "figures out" what to do, as opposed to imperative, where you simply tell the computer each step to do.

That's something of an exaggeration in practice, but yet, there was something to it. A typical program was actually doing depth-first search behind the scenes, so "try this, or else try this, or else try this" algorithms were very easy to express in the language.

As an aid to that, it had unification, which you can think of as pattern matching on steroids. You could write a rule like

something([A, [1, X]]) :- yada(A, X)

which would only match if the argument to 'something' was a list the second element of which was another list that started with 1, and so on. It's far more powerful than this, but it's been many years, and I've forgotten most of it.

As for the cons, implementations of the day were relatively inefficient, although Quintus was fairly good.

The killer problem, in my mind, though is that it didn't really deal well with backtracking through huge data structures. If you were trying to write a bit-blitting algorithm on large arrays, for example, and expecting to backtrack a lot, it just plain wasn't going to work well.

Not sure that helps much. I miss Prolog a lot, but it's hard to see a path forward for it. Even somewhat similar languages like Haskell will probably never get any real traction. Or even Ocaml/F#, which are far more practical.

I suppose the closest we have today are really good Makefiles. Done well, this captures just a bit of Prolog, in a very limited domain.

[tom_mellior]

Why would you backtrack when doing bit-blitting?

[downerending]

In Prolog, backtracking is a fundamental feature of the language, and idiomatic code can do it places you might not think of.

Part of writing efficient Prolog is doing things to avoid such backtracking (by adding cuts or rearranging code).

Bit-blitting is just an example I made up for "large-scale manipulation of array data". There are such cases where backtracking would likely make more sense, though I'm not thinking of an obvious one right now.

[tom_mellior]

The reason you have trouble thinking of an example is that there isn't one. If you know enough Prolog to write idiomatic Prolog code, you also know enough Prolog to think of the cases where your code will backtrack and where it won't. Because idiomatic Prolog code doesn't do unnecessary backtracking.

[YeGoblynQueenne]

That. Prolog will backtrack to get all solutions to a goal, but there is no reason why a goal must have multiple solutions. Unless you program it that way yourself.

[downerending]

You may well be right. As far as I can recall, though, as of the last time I was regularly using Prolog, trying to do serious work on a (say) 1000x1000 array was a recipe for disaster.

The exception would be Turbo Prolog, but it was a rather restrictive subset of the language. Fast as hell, though.