Terminplaner in Prolog
Juli 13, 2009 at 7:30 nachmittags 5 Kommentare
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).
5 Kommentare Add your own
Kommentar verfassen
Trackback this post | Subscribe to the comments via RSS Feed
1.
Sebastian | Juli 13, 2009 um 8:33 nachmittags
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 | Juli 13, 2009 um 8:44 nachmittags
>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 | Juli 13, 2009 um 9:15 nachmittags
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 | Juli 14, 2009 um 7:29 vormittags
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 | Juli 14, 2009 um 11:45 vormittags
[...] 14, 2009 Mein letzter Blogpost zu Prolog hat eine Diskussion gestartet, inwiefern LoC (Lines of Code) wirklich relevant sind. Wie bereits im [...]