It's criminally underused, and it's a weird blind spot for software developers to have. My input on this is that our primary working tool, a programming language, is so powerful and wide that (within the limits of computability) it can literally do anything; therefore we are less likely to question the paradigm or look for a different one, even when it would be more suited to the problem at hand.
Prolog is a deep language and can teach so you a lot. The main problem is that any prolog program bigger than, say, a thousand lines of code become difficult to debug and understand. There are ways to make things better e.g. avoid impure prolog etc. but it is still problematic.
Engineers are always looking for technologies to hop onto. Prolog is niche for a reason: I don’t think Prolog scales. In some ways it is too flexible and powerful.
On the other hand, with dozens of lines of Prolog you can solve some problems that would take many thousands of lines in other languages (and a lot of calm study before you can map them into a real logic or imperative algorithm).
I still avoid it, because yeah, once you solve that problem and avoid those thousands of lines, you are stuck. If you try make the rest of your system in Prolog, it will become a non-viable mess before you even finish it.
That said, I think the main thing that Prolog is missing is easy integration with other languages. If I could define some environment in Haskell, pack it with some Prolog predicate and get a list back, I would use it all the time.
I think Minikanren does a pretty good job of being an embeddable version of Prolog. It's not that difficult to implement in whatever language you choose and uses the host language's data structures, you just have to implement unification over those days structures (i.e. figure out how to make it a tree). The main things it can't do is function like a database, though even that might be possible if you get creative.
I'm not familiar with Prolog and this statement sounds insane. I'm not doubting you exactly, it's just not something I can concieve. Can you provide an example of a problem that would only take a few dozen lines of Prolog which would take several thousand lines in another, "normal", language?
It's been more than a decade since I worked in Prolog, so I cannot give you a direct example but can try to answer :)
Basically, Prolog is declarative programming. You can attach properties to your data and then define relations between the data based on whether they have that property (or not). Something along the lines of: X is grandfather of Y if X is man and X has child Z which has child Y.
The above statement is very simple to write, a couple of lines. This will perform depth first search (or breadth first with some longer algirithm) using your data. As a result, Prolog can provide all such matches of all your data, or just the grandchildren of X, or both grandfathers of Y, etc.
Anyway, what you are really getting is just a good implementation of the search through the relations based on constraints. The main reason Prolog is used is because other languages just don't provide a good library for constraint based search through your data.
So You are saying that there is really not much difference between prolog and lets say constraint solver written in Java (DSL on top of another language)? Because if this really true than now I understand why this language never caught on.
It depneds on the comment and the article. I actually had some contact with prolog (did a semester in university mamy years ago) and still up till today did not find a reason to use it on real life - mainly because I have responsibily to keep my solutions maintainable for decades and I do not see how could I keep easily find people willing to work on prolog and not switch obver to where reall money is at.
So when I saw an interesting insight that somehow maches my very old intuition (that prolog is mainly constraint solver) I wanted to ask more. And I believe that reading this whole introduction could potentially not give me this insight.
That seems like main reason any high level language exist - to give us abstraction layer with better building blocks to solve problems. The trick is to choose which DSL to use in project so its maintainable (and cost effective). I even long time ago learned some prolog (had a whole semester in university on it) but I cannot find a reason why I would use it anywhere in real projects.
I believe in general purpose languages - from the business point of view its better to invest in one platform/language/ecosystem (if possible of course) than to spread too thin - each specialized language is potential liability (its trade-off but still the additional languages have to carry their own weight allowing for example to access more platforms)
Basically any problem involving a complex search of a solution space is a strong candidate for the above statement. There are specialized tools for doing that in other languages, but a) they specialize on a single optimization/search topic and b) their use is generally quite complex vs. prolog.
Are there any Prolog scripting engines or embeddable runtimes? It feels like the kind of thing where you might use it to solve a small part of your problem domain and leave the rest to a conventional language.
To an extent, you get this with Datalog, which is an easily embeddable subset of pure Prolog.
I've been spending a ton of time with the language and its implementation through my day job, and I recently spoke about its use as a DSL for embedded knowledge bases: https://www.youtube.com/watch?v=lYLkaOq7WbU
May I interest you in microKanren? You can just roll your own. Here’s a shameless self-plug for a close reading I did of the paper that introduces microKanren: https://github.com/ashton314/muKanren_reading
indeed, a LOT of problems boil down to satifiability problems that are super easily expressed in PROLOG. I was recently musing about some of the problems with "automated" ffmpeg processing of obscure files (things like realvideo, etc), because there are a lot of edge cases in terms of filters that can't work on X color space or whatever, and the obvious solution that presented itself was a prolog rules/knowledge base that "understands" the conversion process and finds appropriate filters to put together a chain between some arbitrary input and output tuples.
