Submit blocking is not only a feature targeted at admins (they configure how submit criteria), but also for users: users have to know if their change is ready to be submitted.
IIRC, The result of a failing Prolog rule was a single string, which would surfaced to the user. It was often impossible for users to understand why that condition triggered and what they could do to address the issue.
On a technical level the idea was also flawed. The Prolog interpreter had to be constrained (to avoid infinite loops), with hardcoded recursion limit. This meant that adding one Prolog rule too many could trigger a failure in the interpreter which would then throw 5xx errors and wedge the server.
>> The Prolog interpreter had to be constrained (to avoid infinite loops), with hardcoded recursion limit.
Oh well that sounds like bad coding, definitely. You may run into that sort of problem -infinite recursions- the first few times you code in Prolog but you learn to avoid it, just as you learn to avoid infinite do-while loops etc.
Btw, since you mention the server being wedged, a few years ago I was working at a C# shop and there was an incident where _all_ our deployments died because of an infinite iteration. Some code was missing its exit condition from the loop and since this was on our platform which had the common functionality, it affected all our clients.
There was a meeting upstairs, inevitably. When the development team head returned from the meeting he told us that he had explained what happened and the upstairs had decided that we should no longer use iteration because it risked going haywire, as we had just seen. The alternative? Use recursion instead. In C#. Obviously nobody ever complied with this stupid idea.
But you can bring down a bunch of servers very easily in any language you like. Another time, in the same company, there was an infinite recursion now, created in the web templating language we used, an in-house version of django. That was a bit unexpected. In another job, I got some gentle ribbing from colleagues for sucking up all the juice from the database servers with an inexpertly written SQL script. And so on.
I mean, people say sometimes that all that stuff about the halting problem is purely theoretical and so on, but then non-termination bites you in the boogies and you're left with egg on your practically-minded, results-oriented face.
> You may run into that sort of problem -infinite recursions- the first few times you code in Prolog but you learn to avoid it
But almost all of the people configuring Gerrit submit predicates are doing so as their first and only Prolog experience. They are not the authors of Gerrit or even the owners of the server instance.
In that case the idea was not flawed "at the technical level", but at the personal level. Like I say in another comment, a good engineer never blames her tools- especially so when PEBKAC, yes?
To make yet another analogy, I know almost no C++. If you asked me to write some C++ templates to configure your system, I'd probably make a very big mess. Despite the people saying that they're a bit like unification and so on. I just don't know how to use them. So don't ask me to. And don't ask your users who don't know Prolog to use it. That's a bad project management decision.
Also, friendly advice: configuration predicates in Prolog should _never_ _ever_ _ever_ be "rules"; only "facts". That way you don't risk infinite recursions- or run much risk besides. The same goes for any other language I think: don't let the configuration execute arbitrary code or you're in for a surprise, inevitably.
I'd say "we don't have the human resources to support the development of this system in the long term" to be a pretty valid technical reason. Remember that we're engineers, not scientists -- the goal is efficacy
