эм, я сильно сомневаюсь, что на xpce кто-то что-то делает, все же пролог скорее для быстрого прототипирования с последующим переносом связей в бд с обвязкой на другом языке, но все же. Я не особый пролог-прогер, но увидел там два основных недостатка. Во-первых, документация - юзабельность встроенного справочника manpce сомнительна, а остальные доки такие себе. Во-вторых, там у нее вроде другой поток, что осложняет использование глобальных переменных, которые между потоками разделены. А без них осложняется сквозная логика, вроде того же логирования, хотя может это как-то по другому люди делают, тут не знаю, пролог не слишком популярен.

еще он кейс для всяких экспертных систем и т.п., но поддержка пролог-кода очень тяжела, так что сомнительная затея делать это на нем, кгм...

вообще не понял насчёт пролога ничего... он же не императивный, а декларативный, какие потоки и переменные?

прост мы в вузе проходили и это просто автомат вычисления логический, даж не представляю как на таком (без доп. инструментов) что-то написать

Доки кста рил такие се

что то такое https://www.swi-prolog.org/pldoc/man?section=gvar
> "Their value cannot be shared among threads. Each thread has its own namespace and values for global variables."

как по мне, то пролог удобен возможностью показать описание связей непрограммисту, разумеется, для этого нужно где-то писать на русском. Специалист утверждает, что это все корректно и потом вся эта байда заносится в бд. Аналогом может быть какая-то бд с удобным описанием структуры в тексте, но я такой не припомню или же свой кастомный DSL, который будет явно проигрывать прологу. Использовать пролог для чего-то другого... наверное такая себе идея, он действительно неудобен и сложен в поддержке.

хотя может Excel тот же приспособить, но у пролога помимо связей есть аналог sql-запросов в виде правил, а с экселем и т.п. будут сложности.

пока есть недоработка с объяснением правил, вернее, с более удобочитаемой его формой, логированием и т.п.. Но все таки - кейс же.

на чем другом это построить - я хз даже.

хотя там выше где-то кидали ссылку на скриптовый язык для ди. Как правило, к любому языку можно найти скриптовой язык. Тогда основную часть проги можно написать на популярном языке, описание связей делать на скриптовом, все это в бд и  через sql-запросы. Возможно, это более поддерживаемая альтернатива, разве что смотря как эта система будет эволюционировать, кгм...

на распознавателе натуральных языков

Монга не считается как "удобное описание структуры в тексте"?

хотяя там нет строгой структуры так что не считается 8)

как-то пытался я играться с nlp, но мне было ласково предложено писать стеммер для русского языка самому) хотя сейчас в том же пайтоне наверное все есть из коробки. Но в прологе есть DCG или https://ru.wikipedia.org/wiki/DC-грамматика, она позволяет неплохо разбирать команды, вроде как еще ботов пишут под это дело для генерации предложений, но я не видел.

С бд есть одна проблема - пока будет выстраиваться прототип, то изменения будет делать специалист-непрограммист в скрипте\файле\etc и они должны синхронизироваться с бд. Каждый раз чистить и заполнять бд, как и накатывать sql-запрос только для измененных данных выглядит как такая себе идея. Хотя вряд ли данных будет много, так что первый вариант наверное может сработать.

думаю сейчас уже дофига инструментов для полно разбора запросов типа "приправы для картошки". с разобранным предложением уже можно на любом языке работать

логично, наиболее актуален разбор голоса, все же интерактивные экспертные системы, которые задают по одному вопросу да\нет в 2021 году выглядят так себе, особенно на фоне миллионов миллиардов голосовых помощников, иначе зачем все это нужно. С другой стороны, чтобы заставить выдавать её вменяемые добавки для старой доброй картошки пришлось здорово помудохаться, делая правки во множестве мест условной бд. Тут, конечно, нужно более совершенное решение чем пролог, это да.

как же в спп не хватает модулей... особенно без нормальной ide