Prolog proposed logic programming, the idea that one should write a program's logic not as a set of procedures, nor as a set of functions, but quite literally as logical statements. A lot of the novelty and excitement, though, was not specifically from logic, but from this being the first major proposal of declarative programming, the idea that one should specify what, not how, as a general paradigm for programming computers. That approach, specifying the solution's properties rather than the algorithm for finding it, is still the part that most fascinates computer-science undergraduates first exposed to Prolog. Specifying problems declaratively does predate Prolog, as in traditional mathematical equation solving, and in mathematical programming, scheduling, and planning systems. But these were intended as optimization systems for specific domains, not as a programming paradigm on par with functional or imperative programming. Prolog proposed that declarative programming could be flexible and general. Indeed it's turned out to be, but Prolog's lunch has largely been eaten, as bits of declarative-programming niceness have been incorporated into a variety of other systems, often in simplified and non-logic-based form.
The first observation was that rather than viewing Prolog as a way to write programs, it could be viewed as a database with a particularly powerful query language. Instead of just retrieving data, as databases of the time were mainly oriented to do, it could deduce complex results from that data. This way, the purely application logic (GUIs and network protocols and such) could be written in whatever language was most convenient, and Prolog could handle what, in this view, it was most natural for: using rules to deduce facts from other facts. Clearly a retreat from the full logic-programming view, but I think Prolog-as-a-database captures a big portion of the low-hanging fruit, and a lot of Prolog programs had that flavor anyway.
By the late 1970s, some Prolog researchers started working on Datalog, a
variant intended to make a Prolog-type system usable as serious next-gen
database. Clearly the relational database wasn't displaced, but the
declarative-programming-over-data model did win to a certain extent. Today, a
lot of logic is written declaratively in SQL, rather than SQL being used purely
as a way to retrieve data for processing in an application language. Most of
the classic Prolog examples can be written in SQL: if you have tables of
sibling and parent relationships, you can write an SQL query that declaratively
defines an "uncle" relationship,
much as you'd do with the Prolog rule
male(A), sibling(A,C), parent(C,B). The addition of recursive queries
to SQL in the 1990s made even more of that sort of thing possible. It's not
quite everything Datalog promised, but it incorporates enough of the
declarative-programming win while retaining the relational-database model in
which a lot is already invested (and where a lot of data is already stored)
that it outcompeted Prolog-derived databases.
Another big set of systems that ate a tasty portion of Prolog's lunch were
propositional rule-based systems. If you take Prolog's model of facts and Horn
clauses, but turn them all into propositional facts and rules, with no logic
variables or unification, your statements all look equivalent to either bare
assertions of facts, like
a., or simple boolean implications, like
a :- b, c. This simplification has some advantages. First, and
a consideration that probably shouldn't be underestimated: it's simpler to
think about. You have facts, and boolean combinations of those facts can imply
other facts. Secondly, it's now computationally
efficient to calculate the whole set of "things that are true" by forward
chaining from the set of initial facts, as opposed to issuing specific queries
that are then answered through backwards chaining. Finally, it becomes easier
to build truth-maintenance systems, which maintain a dependency between facts
and conclusions, so if you add or remove a fact from the database, you can
quickly update the set of things that are now true. These simpler kinds of
declarative programming, especially production-rule systems like Jess and Drools, are now used to encode the core
logic of lots of things, from expert systems to enterprise business logic.
A different strain of research has carried on the logic-programming-as-general-purpose-programming dream, usually by creating hybrid languages that also incorporate some aspects of functional programming or other programming paradigms. Mercury and Oz seem to be two of the more prominent ones, though I sadly know relatively little about them, and they seem to still be searching for their breakthrough.
A quite interesting twist is the addition of LINQ to C#. It's billed as adding something like SQL as a native C# language feature, allowing you to "query" things in the language like arrays, in the same declarative way you might query a database with SQL. This isn't quite logic programming, but you can see it as the reverse of the Prolog→Datalog transition, with SQL as the starting point this time: now we're taking a database query language, and using something modeled on it as a general-purpose programming construct. It's not everything the logic-programming dream promised, but people are today writing applications with large portions of their core logic written declaratively in LINQ, which is quite a win for mainstream adoption of declarative programming. It might be one of the more promising angles for future adoption, as well. If I had to guess, I would put the odds of a successor to LINQ incorporating more features from logic programming higher than I would put the odds of a Prolog descendent finally breaking through to mainstream use. So this might be worth watching.