Reflektionen über Prolog

July 27, 2009 at 4:46 pm 1 comment


Ich erkläre meine Experimente mit Prolog jetzt erstmal für beendet und schließe mit ein paar Reflektionen über Prolog. Es ist durchaus möglich, dass ich an der einen oder anderen Stelle einem Irrtum aufgesessen bin. In diesem Fall freue ich mich über entsprechende Kommentare.

  1. Prolog als Sprache fand ich ganz lustig, auch weil die Ansätze so anders sind als das, was man sonst so in Programmiersprachen vorfindet. In diesem Sinne war die Beschäftigung mit Prolog auf jeden Fall zur Horizonterweiterung nützlich.
  2. Für Prolog gibt es einen ISO-Standard, so dass Prolog-Systeme verschiedener Hersteller kompatibel sein sollten. Das ist eigentlich ganz nett. Aber je mehr Programmiersprachen mit ISO-Standard ich kennenlerne, umso mehr habe ich den Eindruck, dass eine ISO-Standardisierung die Fahrkarte ins Reich der toten Programmiersprachen ist.
  3. Möglicherweise ist das auch der Grund dafür, warum es keine Weiterentwicklung von Prolog zu geben scheint. Das finde ich persönlich schade, weil ich die Ansätze vielversprechend finde. Aber irgendwie müsste man die Konzepte noch in die heutige Zeit bringen.
  4. Und ein Nutzen wäre da. Soweit ich das überblicken kann, macht eine Rule-Engine ungefähr, das was Prolog macht – nur eben in einer proprietären Sprache. Wenn man Pech hat, kommt auch noch XML ins Spiel die ganze Geschichte wird auch noch schwer lesbar. Wäre es nicht viel smarter, Prolog dafür zu verwenden?
  5. Prolog hat den Anspruch, den Entwickler weitestgehend von Algorithmen zu entlasten und stattdessen nur noch Spezifikationen schreiben zu lassen. Das finde ich einen lohnenswerten Ansatz. Ich hatte das Gefühl, dass ich tatsächlich weniger Algorithmik betreiben muss. Ich muss aber im Gegenzug wissen, wie Prolog die Regeln auswertet – also letztlich welche Algorithmen Prolog anwendet. Und das fand ich nicht immer trivial. Daher hatte ich auch so meine Schwierigkeiten, den Cut-Operator sinnvoll einzusetzen. Aber vielleicht wird das einfacher, mit mehr Übung?
  6. In die gleiche Problemkategorie fällt, dass ich zwischendurch immer mal Situationen hatte, wo eine Regelauswertung auf einmal 20 Sekunden gedauert hat – bei einer handvoll Fakten. Und mir war nicht immer klar, wie das passiert ist. Insgesamt sollen aber Prolog-Programme auch nicht langsamer sein als Programme, die in anderen Programmiersprachen entwickelt werden.
  7. Beeindruckend fand ich, dass ich mein Terminplaner-Beispiel in Prolog mit extrem wenigen Zeilen Code schreiben konnte, ohne dass der Code schwer verständlich wurde. Allerdings hat das Beispiel wieder Benutzungsoberfläche noch Datenbank. Wenn beides dazukommt und man die Lösung mit Rails oder Grails vergleicht, ist der Unterschied vermutlich nicht mehr so drastisch. Schließlich ist SQL ja sowas wie Prolog-Light.
  8. Apropos Benutzungsoberfläche und Datenbank: Prolog ist keine isolierte Regel-Auswertungsmaschine. Anbindungen an Rich-Client-Libs, HTTP und Datenbanken existiert in Form von Libraries.
  9. Durch sein Pattern-Matching ist es mit Prolog ganz einfach, eine internen DSL zu formulieren – auch wenn man sich wünschen würde, die Klammern der Root-Regel noch loswerden zu können.
  10. Regeln haben in Prolog keinen Rückgabewert. Stattdessen werden als Variablen angegebene Parameter zu diesem Zweck verwendet. Das in sehr flexibel und funktioniert eben auch für mehrere Rückgabewerte. Auf der Negativseite steht, dass man für einfache Ausdrücke eigene Variablen einführen muss. Möchte man an eine Regel index+1 übergeben, muss man dazu eine Extra-Variable einführen. Das finde ich definitiv umständlich.
  11. Die meisten Prolog-Systeme bieten ein Modulkonzept. Das ist nicht im ISO-Standard enthalten, aber zwischen die Prolog-Systemen aber sehr ähnlich. Ich habe das Modulsystem nicht benutzt, aber es sieht vernünftig aus.
  12. Außerdem gibt es sowas wie Objektorientierung (mind. in SWI-Prolog), aber das sieht echt merkwürdig aus.
  13. Und dann ist da noch die Datenbasis mit den Regeln und Fakten. Durch diese Datenbasis lassen sich viele Dinge sehr einfach und elegant formulieren. Allerdings stellt sie auch globalen Zustand dar – mit den üblichen Nachteilen globaler Variablen. So muss man z.B. bei Tests selbst dafür sorgen, dass die Datenbasis aufgeräumt wird. Positiv an der Datenbasis ist allerdings, dass nach Programmausführung bzw. Test die Daten für Post-Mortem-Debugging verfügbar sind.

Hat jemand andere oder ergänzende Erfahrungen? Dann immer her damit!

Entry filed under: #. Tags: .

Beispiel für Closure BDD for Prolog: How To

1 Comment Add your own

  • 1. Rahnfeld  |  August 5, 2011 at 1:21 pm

    Der Punkt ist m.E., dass Prolog nur zwei Prozeduren kennt:
    Unfication und Recursion; letztere ist Pflicht bei allem, was
    mit Listen zu tun hat und damit Kern der Programmierung.
    Ich finde man muss sehr gut rekursiv denken können, um
    zu profitieren – leider fällt mir das nicht leicht.

    Ein anderer Punkt: Wer kann mir sagen, wie ich die temporären
    Datenbankerweiterungen mit assert etc. in meinem Quellcode
    sichern kann, also dauerhaft zur Datenbank hinzufügen kann?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: