What is Prolog bad at?

Question

I was recently trying to learn about Prolog and it seems to map well to a lot of domains, but I was having trouble figuring out what it might be bad at.

So what is it bad at (besides things that need real-time/no-gc performance)?

Answer 1

I agree with your general assessment that Prolog maps well to many domains. In my opinion, even more so than most other languages.

To give one of the few examples where it is bad at:

Prolog is decidedly bad at number crunching as it is currently understood. By this I mean many, many largely nonsensical calculations over floating point numbers, accumulating errors in ways that nobody can realistically understand or handle.

This is an area where Prolog implementations cannot compete as it is today, since all these calculations incur too much overhead by the way Prolog reasons about terms, and also because the nastiness of these calculations are generally abhorred in the logic programming community, where the focus is rather on correctness and convienence for users, and other number formats such as rational numbers are typically chosen if at all possible.

However, and I think that will become an important development of the future, once the extreme shortcomings of floating point numbers have become sufficiently widely understood and better formats (example: Unums etc.) have become sufficiently widely known and available, Prolog may become an increasingly important tool also in this area.

In his book, The End of Error, John Gustafson gives a beautiful analogy I often think about:

Many decades ago, it took 30 seconds to print a page. When printers become better, it still took 30 seconds to print a page. We did not spend all advancements of technology to print 5000 low-quality pages in 30 seconds, but rather improved the quality of the pages thousands of times.

I think number crunching will eventually go in the same direction: Use the increasingly available computing power to improve the quality of results, not the quantity.