Prolog look like it would be the correct tool for the job for a certain class of problems, I wish I had time to learn it. I always wonder why it doesn't get more attention.
I've been teaching myself Prolog, and it's sufficiently different that I feel like I'm learning to program all over again. You can sort of pretend that predicates are just funny functions, where you have to put the return value's container into the argument list, but that's not really what's going on. I loved reading the docs for SWI-Prolog, where most of the predicate docstrings start: "True if...". You can say that the length predicate returns the length of a list, but really it returns true if the given list has a length equal to the given integer. It will tell you the length of a list, sure, but it will also do the reverse:
?- length(List, 5) -> List = [_,_,_,_,_]
Nuts!
? evalo(e, 6)
(+ 3 3)Is that just to distinguish them from normal "eval" (in this case), or is there a deeper meaning?
So yeah, it's just to distinguish from the usual semantics.
- historical inertia, i.e., SQL being better known, being taught to a lot more people, already used everywhere; even if every new project started Datalog, we would "still have SQL databases" for many decades, see the recent publicity for Cobol
- aggregate functions, sorting of results
- syntax: "select foo, bar from table_with_many_many_columns" is easier to get right than "table_with_many_many_columns(_, _, _, _, Bar, _, _, _, _, Foo, _, _, _)" (though in most other aspects Datalog syntax is indeed superior)
That's where Machine Learning and Neural Networks are much better : they can organize enormous amount of arbitrary data (not only text and words) way more faster that a programmer or an expert, given a sufficiently big enough dataset.
In other terms, prolog "doesn't scale" with the diversity and ambiguity of humans knowledge.
pre-answered your own question really. Prolog 'died' in the AI winter, so no one knows it and no one knows anyone who knows it. Every time you think "huh I bet this is like 100 lines in Prolog" it doesn't matter because writing 2000 lines of Java (or whatever you know) is still going to be faster than learning Prolog.
This is also the problem with literally any comment about "using the right tool for the job" with regards to programming languages.
a) You would never train staff or hire experts on Prolog for such few problems and...
b) You could probably do much better with a heuristic algorithm anyway. Especially on hardware of the day when Prolog came out, but even today I imagine this holds true.
Prolog may be useful for quick exploration of a problem space. But for code that needs to run frequently, there just isn't a great need for what Prolog has to offer.
We may see analogous developments with Prolog when our current hardware gets better or changes its characteristics, and when Prolog implementations get better and use better approaches that are now becoming available.
I think one difficulty we are facing when judging developments in this area is that complex software projects such as implementing a Prolog system happen on time scales we are not yet used to.
* I mean seriously it's fantastically expressive: parsing, constraint logic, expert systems, database interaction-- all look and feel completely native, it's beautiful.
In fact, I think precisely due to this elementary difference, it is reasonable to expect it to take longer for Prolog implementations to reach the practical applicability we are now seeing in neural networks after a few decades of research and improvements.
There are some modern Prolog versions that try to use some better searching algorithms, but the language hinders that change.
Whether or not this is true, Prolog is so much more than just "searching". Unification gives you all the powers of pattern matching in functional languages, but adds a lot of extra power on top of that. For anything working with tree-shaped or even DAG-shaped data, Prolog is an excellent choice.
I have spent much more time looking for unexpected exponential runtime than the time it takes to implement the code without unification. That's the main reason I abandoned the language.