Terminplaner in Prolog

July 13, 2009 at 7:30 pm 5 comments


Ich habe meine Prolog-Kenntnisse aufgefrischt und dazu das Terminplaner-Beispiel in Prolog implementiert. Die geringe Anzahl Lines of Code (LoC) der Prolog-Lösung finde ich ziemlich beeindruckend. Ich habe die Größe der Lösung in den verschiedenen Programmiersprachen mal gegenüber gestellt (LoC: ohne Leerzeichen und Kommentare).

Sprache LoC LoC Tests
Java 187 109
Groovy 155 79
Ruby 141 90
Lisp (CLOS) 63 77
Prolog 34 93

LoC ist sicher kein besonders gutes Maß, um die Mächtigkeit einer Programmiersprache zu bewerten. Wenn man allerdings nur 34 Zeilen braucht, wo man sonst 150-200 Zeilen braucht, finde ich das schon ziemlich denkanstößig.

Der Code steht unter github bereit: http://github.com/stefanroock/Terminplaner/tree/master (Achtung: Die Python-Lösung funktioniert noch nicht).

Entry filed under: 1. Tags: , , , .

Peter-Prinzip simuliert LoC und Produktivität

5 Comments Add your own

  • 1. Sebastian  |  July 13, 2009 at 8:33 pm

    Hallo Stefan,
    bei Prolog erkenne ich nicht mehr was das Programm macht. Das liegt wohl eher an meinem fehlenden Prolog-Kenntnissen bzw. irgendeiner deklarativen-logischen Sprache. Nach den LOC ist es bei Prolog auch aufwendiger Tests zu formulieren. Wenn ich also noch mein subjektives Gefühl der Lesbarkeit hinzunehme sind Ruby und Python am einfachsten zu Lesen mit dem wenigsten syntaktischen Rauschen. Und es überrascht mich wie sehr Groovy doch noch nach Java aussieht, das habe ich anders in Erinnerung.

    Wo bleiben die Lösungen in Assembler, brainfuck oder whitespace?😉 Denke Du kannst an vielen Stellen die Anzahl der LOC noch sehr minimieren und gibst dafür Abstraktion und Design auf.

    Gruß – Sebastian

  • 2. stefanroock  |  July 13, 2009 at 8:44 pm

    >Nach den LOC ist es bei Prolog auch aufwendiger Tests zu >formulieren.
    Im Verhältnis hat man in Prolog mehr Testcode. Das könnte aber auch an meinen rudimentären Prolog-Kenntnissen liegen. Auf jeden Fall braucht man für die Tests auch nicht mehr als mit den anderen Sprachen.

    >Denke Du kannst an vielen Stellen die Anzahl der LOC noch sehr
    >minimieren und gibst dafür Abstraktion und Design auf.
    Ist das wirklich so, oder machen wir es uns mit dieser Sichtweise einfach nur bequem in unserer OO-Welt. Wo verletzt die Prolog-Lösung SOLID o.Ä.?

  • 3. Sebastian  |  July 13, 2009 at 9:15 pm

    Wo verletzt die Prolog-Lösung SOLID o.Ä.?

    Das war wohl missverständlich von mir und ich verstehe zuwenig Prolog um das zu erkennen. Ich meinte nur man kann SOLID – das schwer objektiv ohne Kontext zu messen ist – und OO außer Acht lassen und bestimmt noch viel kürzere Lösungen finden.

  • 4. stefanroock  |  July 14, 2009 at 7:29 am

    Ja, da stimme ich Dir zu. LoC im Brainoff-Modus als Maß zu verwenden, führt zu Murks.
    Wobei: OO außer acht lassen könnte vielleicht eine ganz gute Idee sein. Ist OO als Paradigma wirklich überlegen oder sind wir nur entsprechend indoktriniert worden?

  • 5. LoC und Produktivität « Stefan Roock  |  July 14, 2009 at 11:45 am

    […] 14, 2009 Mein letzter Blogpost zu Prolog hat eine Diskussion gestartet, inwiefern LoC (Lines of Code) wirklich relevant sind. Wie bereits im […]

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: