Because its more powerful than MongoDb or Fortran. The cut operator for instance gives it the ability to express things you just can't do in those other systems. The trade-off is that mastering the cut operator is a rare skill and only that one person who can do it can maintain the Prolog code. Compare that with MongoDb where even the village idiot can use it but with a huge performance cost.
I don't know about MongoDB and its query language, but wrt Fortran, it's unreasonable to say that Prolog is more powerful than Fortran (or vice versa). A more reasonable statement is that Prolog is more expressive than Fortran (though this gets fuzzy, we have to define expressiveness in a way that lets us rank languages). But the power of a language normally means what we can compute using that language. Prolog and Fortran both have the same level of "power", but it's certainly fair to say that expressing many programs is easier in Prolog than Fortran, and there are some (thinking back to my scientific computing days) that are easier to express in Fortran than Prolog.
I would say most programs are easier in Fortran. But there are things you can't express in Fortran but you can in Prolog. There is nothing like the cut operator in Fortran for example. They are very different animals.
You seem to be confusing two different things: What is easily or natively expressed in the language, and what can be expressed in the language.
You can create a logical equivalent of the cut operator in Fortran if you wanted to, but there's no native mechanism or operator to rely on. The languages possess the same computing "power", the difference is not in what they can compute which is your claim with "there are things you can't express in Fortran but you can in Prolog" (utter nonsense). Anything you can get a Prolog program to do, you can get a Fortran program to do (and vice versa).
> You can create a logical equivalent of the cut operator in Fortran if you wanted to
In isolation, no you can't. You could implement a Prolog interpreter in Fortran however. And if you did that, you would be able to write a cut operator because then you are interacting directly with Prolog's machinery. Part of the definition of the cut operator involves changing how code around it behaves. You can't do this with Fortran (or other languages) normally. Then there is the entire concept of backtracking with isn't native in any other language (that I know of).
You could probably make a very poor cut operator in a language with an Any/Object type and casting but why would you. You are not wrong about the math. But you are ignoring the absurd amount of code you would have to write to do it. Its a bit hand-wavy to say because you can implement Prolog in a language, its just as powerful. Although that is mathematically correct but in practice it really isn't.
I think cut operator doesn't make sense for any other language because prolog doesn't execude code linerily. It executes it with depth first search with backtracking. Only when you have a thing that walks the tree it makes sense to have a cut operator that prevents backtracking at some spots.
I don't think the person you responded to knows what the cut operator is, or they wouldn't have written any of their nonsense comments. They seem to think that it's some magical thing and not, as you wrote, a way to stop backtracking from going back through some point. You can implement that in any appropriate search system in any language. It might not be an operator, but it would carry the same meaning and effect.
