Perl, Java oder C
Für unser Suchmaschinenprojekt Neomo bin ich seit Monaten damit beschäftigt, mich um die jeweils geeignete Programmiersprache für die verschiedenen Module zu kümmern. Natürlich geht es dabei um Geschwindigkeit - wobei die Ausführungsgeschwindigkeit weniger wichtig ist als die Entwicklungsperfomance.
Derzeit setzen wir nun folgende Sprachen ein:
C für alles, was extrem schnell laufen muss und was nicht - oder nur mit großem Aufwand - parallelisierbar ist.
Java für die Module, die evtl. auf Kundensystemen zum Einsatz kommen; schließlich gibt es Javaexperten heute in jeder noch so kleinen IT-Firma. Mit Javamodulen kann also jeder was anfangen und sie überall einsetzen, egal ob Linux, Windows, Mac OS X oder ein sonstiges BSD-artiges System die Zielplattform ist.
Und schließlich Perl für alles wichtige. *g*
Zugegeben, es ist schwerer, mit Perl gut wartbaren Code zu fabrizieren als mit Java. Oder besser müsste ich schreiben: Es ist schwierig, Javacode zu produzieren, der nicht gut wartbar - bei Perl verhält es sich genau anders rum. Dafür lässt sich Perl nicht nur extrem schnell entwickeln, es ist auch in vielen für uns wichtigen Disziplinen teils deutlich schneller als Java, wie sich u.a. im Great Computer Language Shootout nachlesen lässt. So ist ein Perlprogramm bei der Ermittlung von Worthäufigkeiten in einem Text nur um den Faktor zwei langsamer als C++, aber dafür mehr als dreimal so schnell wie Java.
Save This Page
Wer sich bei der Erstellung von wartbarem Code unterstützen lassen will, hat bei Perl viele Möglichkeiten.
Zum Einen sind es natürlich Tests! Tests sind unerlässlich. Wer viel testet macht sich automatisch mehr Gedanken über die API etc.
Dokumentation! Wer versucht, jemandem zu erklären (schriftlich oder mündlich) was der Code macht und warum Funktionen benannt sind wie sie sind und wer das nicht wirklich schafft, hat beim Design wohl etwas falsch gemacht.
Perl::Critic, ok, das hat bei der Erstellung Deines Posts noch nicht existiert, aber jetzt gibt es das Modul. Damit kann man sich auf viele Sachen, die in Damian Conways “Perl Best Practices” beschrieben sind, aufmerksam machen. Mit einigem Aufwand ist es auch möglich, eigene Policies zu entwickeln.
In der nächsten Ausgabe von $foo - Perl-Magazin (http://foo-magazin.de) werde ich Perl::Critic vorstellen. Zu eigenen Policies werde ich aber vermutlich erst in der dritten Ausgabe kommen
strict! Das ist wohl Pflicht für jeden Perl-Programmierer. Ohne strict verheddert man sich leicht in einem Wust von Variablen. Weiß nicht, was schon deklariert und initialisiert wurde. Wer weiß das schon bei einem 1000-Zeilen Code. Mit strict werden die Gültigkeitsbereiche von Variablen eingeschränkt. Einen sehr guten Artikel zu strict gibt es im Wiki von Perl-Community.de. Wer noch kein strict verwendet sollte den Artikel unbedingt mal lesen!
Ein weiteres Modul, das recht nützlich sein kann - vor allem wenn man fremden Code bearbeiten muss: Perl::Tidy. Das sorgt für einen übersichtlicheren Code. Im richtigen Sinne, nicht im “spaßigen” Sinne von Acme::Bleach.
Gruß,
Renée