"What are you doing?", asked Minsky.
"I am training a randomly wired neural net to play Tic-tac-toe", Sussman replied.
"Why is the net wired randomly?", asked Minsky.
"I do not want it to have any preconceptions of how to play", Sussman said.
Minsky then shut his eyes.
"Why do you close your eyes?" Sussman asked his teacher.
"So that the room will be empty."
At that moment, Sussman was enlightened.
That being said, the field of Operations Research, at least philosophically speaking, has picked up where AI researchers dropped it off. They've fully embraced the idea that human experts can model many systems extremely well, and have built incredible tools to do so: mathematical modeling and optimization, constraint programming, boolsat, graphical models, etc. Effectively speaking, if you think expert systems are cool, the next logical step is to delve into constraint programming, which is a sort of evolution of logic programming. I'd recommend the Minizinc Tutorial for a practical introduction with a nice DSL. Constraint Processing by Rina Dechter is a great intro with a more academic bent. I'd say mathematical modeling has been Ops Research's greatest success, and I'd definitely recommend Model Building with Mathematical Programming by Paul Williams.
I'd also say that Baysians have embraced these ideas (that of building upon human expertise) within the field of Machine Learning far more than other ML researchers have. My recommendations here are probably less helpful...I've only ever toyed with Bayesian learning models, but never employed them professionally. But I would recommend Doing Bayesian Data Analysis by Kruschke. It was very helpful as an introductory material.
These are in widespread use for a few applications. Probably every bank has at least one iLog instance running for enforcing business rules. Another one is "complex event processing", where a RETE engine makes it easy to aggregate small events into larger events. Also, a few efforts, such as Inform7 and Clara have tried to push the boundaries of programming for non-experts and real-life applications.
It is interesting, however, that the technology is not further applied, and a deep analysis of that could be worthwhile. For instance, RETE networks can eat "callback hell" situations for lunch, much like the complex event processing case. Instead, however, we are seeing one awful Javascript framework after another, and coroutines pushed as a very narrow answer to the problems on the server.
Note that all forms of A.I. have ties to optimization. For instance, usually when you train a neural net you are minimizing some kind of an error function. Drools (and iLog) both have optimization frameworks, etc.
The recent discussion of "superintelligence" has been marked by both a lack of imagination and any awareness of previous work on the subject. For instance, Rules engines are a fairly direct answer to "AI Safety" and "AI Ethics" problems that there is so much handwringing about. Most areas that require computers to be "creative" amount to some kind of multi-objective optimization, and even if rules can't make a system good, they can at least prevent the worst abuses.
I likewise find it sad that the idea has died so much that we continue to build square wheels that were made obsolete by rule engines. I remember a futile attempt at Amazon to get a team to scrap their system in favor of a RETE based rule engine. Theirs was a poorly performing and fragile homemade "rule engine" that compiled xml rules into if/else statements, which after tens of thousands of rules had slowed to a snails pace. Somehow the magic of O(1) escaped them, and they practically required me to reimplement their system from scratch in order to convince them. So I let it go.
I had never considered the possibility of killing callback hell with a rules engine but I can definitely see it now. I personally have toyed with building a compiler that eschews the pipeline architecture with a rules engine where both analyses and optimizations are implemented as rules. I definitely think there is a world of possibilities out there, but maybe we'll need another AI winter before people consider them again.
ps: this book https://www.amazon.ca/Prolog-Programming-Artificial-Intellig...
I don't think there have been many head-to-head comparisons. Academic researchers simply ceased using "expert system" in their research grant applications and began to use "neural network".
For real-world applications your choice of model would likely depends on the data available (e.g., human expert vs historical data on electronic media).
I think this Quora posting characterizes well the status of expert systems vis-a-vis neural networks today:
"Artificial Intelligence: Are Expert Systems outdated?"
https://www.quora.com/Artificial-Intelligence-Are-Expert-Sys...
Prolog, OTOH, is as minimalistic and pragmatic as ever, with many implementations around, based on an ISO standard even. There's a slowly evolving initiative to come up with an extended standard library across Prolog implementations (eg. Prolog Commons). Though as you might know, Prolog doesn't solve hard problems in itself; rather, it gives you a Turing-complete language based on backtracking, negation-as-failure, closed-world reasoning, and extra-logical mechanisms as primitives to build more interesting reasoning or planning/optimization problems on.
OWL2 points to a world where a production rules or logic language is fronted by a macro language that lets you say something like
"x is a transitive property"
rather than write
"x(a,b) and x(b,c) implies x(a,c)"
In fact, many RDFS and OWL implementations work exactly that way. RDFS/OWL is designed to support data integration in the sense of "this predicate is an alias of that predicate" but aren't revolutionary because it lacks the ability to do things like
"CentigradeTemperature(x,T) implies KelvinTemperature(x,T+273.15)"
which ordinary production rules engines do easily. Many semantic web tools have such a production rules engine hidden inside (Jena/GraphDB/...) but production rules have resisted standardization.
Note that "Datalog", a subset of Prolog that is purely logical and doesn't have cuts and all of that awful stuff, has caught on, but there has never been a "Turbo Datalog" or "Common Datalog" because frequently Datalog-equivalent functionality gets build into semantic web tools, Datomic, or systems that don't claim any formal compatibility with anything else.
RDF suffered a lot because of RDF/XML where it was really unclear where RDF ended and XML started. Today there is Turtle and JSON-LD, both of which are pretty ergonomic.
One issue I see is that many companies have their own "semantic web"-like technologies which are their own secret sauce and competitive advantage (thus not shared) whereas there seems to be a huge amount of fear and loathing of the W3C standards process, especially amoung people who are veterans of it.
While many people like JSON-LD, if you see actual uses of it such as Google's corporate contacts ([1]), I can't help but think it merely adds to the already heavy "syntacticity" of the semantic stack. For me, JSON-LD feels like an appeasement to the JSON and pragmatic web developers crowd, but then its JSON gets very complicated/counter-intuitive and squeezes @type, @context and other meta-meta attributes into JSON which won't make pragmatist happy.
Personally, my go-to stack for logic has become Datalog and Prolog once again (unmatched in terms of minimalism, elegance, and power IMHO).
[1]: https://developers.google.com/search/docs/data-types/corpora...
For some kinds of video game agents, traditional logic programming might be fine.
But for anything that I would consider using in the real world, I would want to use probabilistic knowledge representation and reasoning.
Even for many kinds of video games you'd want that instead. Like in a first person shooter where the agents have limited knowledge of the world state, you want to be able to reason about the other player's position and status without cheating, so that the agent can be more realistic and fair.
The schedules and timetables need to be exactly, defined according to a large number of requirements (hard constraints and weighted preferences).
While these exact schedules could be created through probabilistic means, the systematic approach of logic search provides more consistent results than a stochastic search, and the imperative programming style allows finer control over the search algorithm than what would be easy to achieve in a pure logic language.