Regelbasierte Abläufe: Prolog?

[Shink]

Wir sind beim Entwickeln eines Backofficesystems und probieren uns an verschiedenen Möglichkeiten regelbasierte Abläufe zu implementieren. Ganz perfekt scheint da nichts zu passen.

Ausimplementierung in Java mit Auslagerung diverser Variablen in die Datenbank scheint am vernünftigsten zu sein, ist aber natürlich ein Horror bei sich ändernden Anforderungen und gleichzeitiger Gültigkeit mehrerer Versionen der selben Regel. Außerdem müsste bei jeder Änderung kompiliert werden.

Rule Engines sind schonmal ein Ansatz, können aber zu wenig: Regeln verkehrt oder mit teilweisen unbekannten Variablen auszuwerten müsste jeweils eigens implementiert werden; somit hätte man die selbe Regel mehrmals - was zu warten sehr problematisch sein dürfte/wird.

Nun bin ich auf die kranke Idee gekommen mal Prolog zu versuchen. Damit kann man z.B. Regeln in jede Richtung auslesen und sich alle gültigen Werte für eine Variable ausgeben lassen. Natürlich muss man dazu aber ein paar nette Dinge dazuimplementieren damit man für die Regeln selbst die geforderte Flexibilität hat.

Meine Fragen an euch:

Wäre so etwas verantwortungsvoll? Immerhin kann so gut wie niemand Prolog programmieren und vielleicht würden es einige Programmierer gar nicht erlernen.
Warum macht so etwas zur Zeit niemand? Ist es so krank oder kommt es möglicherweise erst in Mode (wie z.B. funktionale Programmierung in letzter Zeit)
Gibt es Einschränkungen an die ich nicht denke?
Wer hat Erfahrungen mit Prolog im tatsächlichen Leben, abseits der akademischen Welt? Vielleicht verwendet es ja jemand für Scripting o.ä.

[samm]

Zum ersten Punkt: Ich denke mal, Prolog ist auch für erfahrene Programmierer schwer zu erlernen, da es ein völlig anderes Paradigma als die meisten anderen Sprachen benutzt. Andererseits kenne ich so einige (inkl. mich), die gerne Neues lernen, und so ein unterschiedlicher Ansatz ist eine wirklich erfreuliche Bereicherung des Erfahrungsschatzes.

Zum zweiten Punkt: Ich glaube nicht, dass Prolog noch in Mode kommt. Es ist immerhin schon recht alt, und in unserem Studium (Computerlinguistik) wird es neuerdings weniger stark berücksichtigt als früher. Wobei Unis natürlich nicht die Berufswelt wiederspiegeln ;)

Zum dritten Punkt: Weiss nicht, woran denkst du denn? ;) Einige Punkte, die mir in den Sinn kommen: Es gibt mehrere Implementationen von Prolog, welche sich mindestens in der Unterstützung verschiedener Idiome unterscheiden (z.B. see - seen für File-Input, sogar Objektorientierung (Visual Prolog)), ich benutze beispielsweise SWI-Prolog. Wichtig ist, dass sich die Programmierer über die Implikationen gewissermassen automatischer Rekursion / Backtracking und der Evaluierung verschiedener Möglichkeiten, dem Einfluss der Reihenfolge etc. bewusst sind. Sicherstellen, dass es immer Ausstiegspunkte aus dem Programm gibt, Speicher wird evt. in grossen Mengen benötigt. Es können keine schnellen Reaktionszeiten garantiert werden.

Zum vierten Punkt: Ich nicht, kenne nur akademische Anwendungen. Aber kuck mal hier: http://stackoverflow.com/questions/130097/real-world-prolog-usage (NASA, Web-Scripting, --> business rules <--, Terroristensuche *g*).

[Shink]

Danke für die Antwort; war ja schon skeptisch ob sich da jemand meldet.:freak:

Zum zweiten Punkt: Ich glaube nicht, dass Prolog noch in Mode kommt. Es ist immerhin schon recht alt, und in unserem Studium (Computerlinguistik) wird es neuerdings weniger stark berücksichtigt als früher. Wobei Unis natürlich nicht die Berufswelt wiederspiegeln ;)
Das lasse ich als Argument nicht gelten. Das dachte ich mal über funktionale Programmierung: Verwenden hauptsächlich Freaks, wird schon Gründe geben warum. Und siehe da, jetzt gibt es erste Konzepte in C# und in der Java-Welt schreit jeder nach Clojure oder Scala.
Und wie lange hat nochmal OOP gebraucht bis sie sich "durchgesetzt" hat?


Es gibt mehrere Implementationen von Prolog, welche sich mindestens in der Unterstützung verschiedener Idiome unterscheiden (z.B. see - seen für File-Input, sogar Objektorientierung (Visual Prolog)), ich benutze beispielsweise SWI-Prolog.
Dass das so ein Problem ist hätte ich mir nicht gedacht aber daran scheitere ich jetzt schon. Hab eine schöne Rulebase in SWI-Prolog implementiert und dachte mir: Schön, binden wir das schnell mal in Java ein; am besten über Prova. Und siehe da: Nichts geht mehr und niemand kann einen sagen was da geändert gehört.

Es können keine schnellen Reaktionszeiten garantiert werden.
Das könnte man von Java auch behaupten.

[ethrandil]

Was unterscheidet dein system von einem formel-löser? Was unterscheidet dein system von einem Prozess-manager?

[Shink]

Was unterscheidet dein system von einem formel-löser?
Zum einen hat eine Vielzahl der Formeln nichts mit Arithmetik zu tun.

Unser System muss eigentlich keine Formeln lösen - und entsprechende (mir bekannte) Konkurrenzprodukte können das auch nicht. Könnte es das aber, wäre damit sichergestellt dass Regeln nicht mehrfach für unterschiedliche Zwecke definiert werden müssen.

Beispiel: Es wird eine Rechnung mit den Variablen A,B,C und D durchgeführt und es gibt eine Vielzahl von (sich täglich ändernde, im Aufbau großen Änderungen unterworfene) Regeln für die Gültigkeit dieser Berechnung; z.B.:

Wenn 0<A<10 dann muss D<50 sein.
Wenn A+B>100 dann muss D=0 sein.
A+B müssen unter 150 sein.

Diese Regeln werden verwendet für:
- Feststellung ob Berechnung gültig/möglich ist
- Eingabehilfe in der GUI (man bekommt Grenzen angezeigt, wird ein gültiger Wert eingegeben sieht man was die anderen Werte einnehmen dürfen damit alle Regeln erfüllt bleiben etc.)
- Vorschlagewerte sollen natürlich im gültigen Bereich liegen

Was unterscheidet dein system von einem Prozess-manager?
Hmm... was meinst du mit einem Prozess-Manager? Ein BPMS ist jedenfalls wesentlich umfangreicher.
Jedenfalls muss unser Produkt natürlich nur für den (engen) Einsatzzweck funktionieren für den es geschaffen ist.

[ethrandil]

Na, wen es konkurrenten gibt dürfte es doch nicht gefährlich sein den echten anwendungsfall darzulegen, oder?

Mir fällt es immernoch schwer die Eignung zu bewerten, da mir der kontext unklar ist.

Ansonsten gibt es prozess-manager, die mehrere parallele regeln und abläufe verwalten. Das Problem ergibt sich ja, wenn was geändert wird, aber ein alter ablauf noch da ist.

Wenn unifikation (der mechanismus von prolog) dann essentiell ist, kann man den ja in zB Java nachilden.

Große Software in Prolog - das ist nichts was ich einem profi empfehlen würde.

[Frucht-Tiger]

Es gibt doch sowieso schon Java Libs die viele Prolog Sachen nachgebastelt haben. Zumindest für Constraints habe ich sowas schonmal gesehen.

[Shink]

Wenn unifikation (der mechanismus von prolog) dann essentiell ist, kann man den ja in zB Java nachilden.

Große Software in Prolog - das ist nichts was ich einem profi empfehlen würde.
Natürlich würde - wenn - nur ein winziger Teil in Prolog programmiert werden.

Das man alles in Java nachbilden kann ist klar und vermutlich wird es auch darauf hinauslaufen. Die Frage ist warum man das machen soll wenn es anders viel einfacher und die Integration kein Problem ist.

Es gibt doch sowieso schon Java Libs die viele Prolog Sachen nachgebastelt haben.
Hmm... kannst du mir sagen wonach ich da suchen soll?
Ich würde vor allem Backtracking benötigen.

[samm]

Große Software in Prolog - das ist nichts was ich einem profi empfehlen würde.Was spricht denn dagegen, die rules-engine in Prolog zu haben? Musst ja kein GUI oder grossartigen I/O mit Prolog implementieren ;)
Ich würde vor allem Backtracking benötigen.
Backtracking ist doch in Java ebenso wie in jeder Sprache, die Rekursivität erlaubt, recht gut herzustellen, weil immer nach dem Ende einer rekursiv aufgerufenen Methode in die aufrufende zurückgesprungen wird. Dort muss dann halt je nach Rückgabewert weiter verfahren werden (d.h. ebenfalls Abbruch, wenn FALSE zurückkommt und keine Alternativen mehr existieren, sonst Alternativen versuchen).

[Frucht-Tiger]

Hmm... kannst du mir sagen wonach ich da suchen soll?
Ich würde vor allem Backtracking benötigen.
Die Sache mit den Constraints ist mir hier (http://bach.istc.kobe-u.ac.jp/cream/) beim googlen mal über den Weg gelaufen, wo du genau Suchen musst weiß ich jetzt nicht, aber vielleicht kann dir der Autor von Cream weiterhelfen.

[Yavion]

Meine Fragen an euch:

Wäre so etwas verantwortungsvoll? Immerhin kann so gut wie niemand Prolog programmieren und vielleicht würden es einige Programmierer gar nicht erlernen.
Warum macht so etwas zur Zeit niemand? Ist es so krank oder kommt es möglicherweise erst in Mode (wie z.B. funktionale Programmierung in letzter Zeit)
Gibt es Einschränkungen an die ich nicht denke?
Wer hat Erfahrungen mit Prolog im tatsächlichen Leben, abseits der akademischen Welt? Vielleicht verwendet es ja jemand für Scripting o.ä.


Prolog hat das prinzipielle Problem, zwar schön für die schnelle Entwicklung von Prototypen zu sein aber vom Prinzip her nicht sehr performant zu sein und einfach, sorry "zum kotzen(!)" zu debuggen zu sein. Ein Prolog Trace ist einfach ziemlich ätzend zu durchforsten, wenn man eigentlich noch was anders vor hat. Noch schöner wird es dann, wenn man die Sache auch noch mit "cuts" auf Performance trimmen möchte. Letzteres ist ein schönes Hobby (hatte seinerzeit mal ein Sudoku-Löser in Prolog realisisert) aber nicht sehr effektiv.

Prolog ist eine (imho) schöne Sprache und einfach Klasse wenn man sich daran gewöhnt hat: Wenn man eine Sache in Prolog implementiert hat und sie läuft, hat man ein Problem so erfasst, dass es einem i.d.R. keine große Schwierigkeit bereitet, sie in einer imperativen Sprache zu umzusezten.
Als Produktivsystem ist Prolog aber derzeit m.E. nicht geeignet.

[Coda]

Das lasse ich als Argument nicht gelten. Das dachte ich mal über funktionale Programmierung: Verwenden hauptsächlich Freaks, wird schon Gründe geben warum. Und siehe da, jetzt gibt es erste Konzepte in C# und in der Java-Welt schreit jeder nach Clojure oder Scala.
Microsoft liefert mit F# bei Visual Studio 2010 sogar eine funktionale Programmiersprache aus. Basiert auf OCAML.

Schaut ziemlich cool aus, aber ich habe gerade keine Zeit um das zu lernen.

[Shink]

Prolog hat das prinzipielle Problem, zwar schön für die schnelle Entwicklung von Prototypen zu sein aber vom Prinzip her nicht sehr performant zu sein und einfach, sorry "zum kotzen(!)" zu debuggen zu sein.
Hmm... das selbe könnte man auch über Rule Engines im allgemeinen sagen.
Diese werden in letzter Zeit auch mit (nur teilweise funktionalem - kein Vergleich zu Prolog) Backward Chaining ausgestattet. Genaugenommen ist das schon ein Schritt in die Richtung "Prolog for Business":freak:; mal sehen wo wir da in ein paar Jahren sind.

[Gast]

Für mich klingt das nach einem sehr guten Beispiel für irgendwelche Workflow Engines. In der Java Welt kenne ich mich aber nicht aus und weiß nicht, was es da alles gibt.