Kreuvfs Allerweltsblog

Rezensiert wird im folgenden das Buch „Reguläre Ausdrücke, 3. Auflage“ von Jeffrey E. F. Friedl in der deutschen Übersetzung von Andreas Karrer. Das Buch ist im O’Reilly Verlag erschienen und unter der ISBN 987-3-89721-720-1 auffindbar.

Zu dem Buch bin ich gekommen, nachdem ich im Jahre 2007 in der Dokumentation zum Apache-Webserver auf „PCRE“ gestoßen war. Auch wenn ich anfangs nicht viel davon verstand, so war doch mein Interesse geweckt an der weiten Welt der regulären Ausdrücke. Auf das Buch bin ich dann dadurch gestoßen, dass es einfach überall verlinkt war, wenn es um Literatur zu regulären Ausdrücken ging. Und das kann ich vorweg sagen: Die Investition lohnt sich.

Anders als bei meiner ersten Rezension werde ich dieses Mal auf die Darstellung negativer Seiten verzichten. Der Grund dafür ist, dass ich absolut nichts an diesem Buch auszusetzen habe bis auf ausgesprochen wenige Tippfehler, die die Qualität aber keineswegs schmälern.

Gute Seiten

Der Autor versteht es von Anfang an in einem lockeren erzählerischen Stil mit dem Thema umzugehen. Dies ist auch bei teils sehr trockenen Abschnitten stets gelungen. Ebenfalls merkt man, dass der Autor weiß, wovon er schreibt. Es kam mir niemals so vor als würde sich der Autor um die Erklärung einer Sache drücken wollen.

Die Zahl der Übungsaufgaben ist genau richtig und es werden auch exakt jene Dinge gefordert, die für den späteren Umgang mit regulären Ausdrücken entscheidend sind. Auch daran merkt man eindeutig, dass der Autor versteht, was er da schreibt. Und man merkt daran auch, dass sich der Autor die Mühe gemacht hat zu überlegen, wo es denn Knackpunkte im Verständnis geben kann und wie diese in eine fordernde Aufgabe umgewandelt werden können.

In den ersten 3 Kapiteln werden Grundlagen beschrieben, die Kapitel 4 bis 6 behandeln dann tiefergehende Themen, wobei mein persönliches Highlight Kapitel 6 ist, das sich um Effizienz- und Performancebetrachtungen dreht. Performance ist ein wiederkehrendes Thema, bei dem die einen sagen, dass es bei den heutigen Rechenleistungen ja unerheblich sei bestimmte Dinge zu optimieren, während die andere Seite dagegenhält, dass möglichst gute Performance immer angestrebt werden muss. Ich bin da ein Vertreter der Performancefans. Ein einfaches Beispiel ist das Durchsuchen der Warzone-2100-Quelltexte (.c- und .h-Dateien) mittels grep von der Kommandozeile aus. Verwende ich grep ohne den Schalter -i (Groß- und Kleinschreibung egal), so kann ich selbst auf meinem Computer (1 GHz) die gesamten Quelltexte in einem Augenblick durchsuchen, wenn der gesuchte Text ausschließlich aus Literalen besteht. Schalte ich -i dazu, so kann es bei entsprechend langen Texten (ab 10 Zeichen etwa) schon zu einer spürbaren Verringerung der Ausgabegeschwindigkeit kommen. Wird der gesuchte Text noch ein wenig länger, muss ich sogar über eine Sekunde auf das Ergebnis warten, was nicht mehr hinnehmbar ist.

Der Autor geht auf einen interessanten Fall ein, der nichtsdestotrotz realitätsnah ist und jemand schrieb mir mal, dass man sich heutzutage ja um Effizienz bei regulären Ausdrücken keine Sorge mehr zu machen brauchte. Ich konnte dies mit diesem Beispiel aus dem Buch widerlegen. Der Autor stellt an der entsprechenden Stelle (S. 232) garniert mit einer Portion Humor fest:

[…] Milde ausgedrückt, bedeutet das VIEL Arbeit. Auf meinem Rechner würde das etwa 50 Quintillionen Jahre dauern, plus/minus ein paar hundert Billionen Jahrtausende.¹
[…]
1 Die angegebene Zeit ist aufgrund der Zahlen von anderen Benchmarks hochgerechnet; ich habe die Tests nicht wirklich so lange laufen lassen.

Es sind Dinge wie diese, die mir ein Schmunzeln auf die Lippen zaubern und den Charme dieses Buches ausmachen.

In den letzten Kapiteln werden verschiedene Programmier- und Skriptsprachen behandelt, wobei ich mich ausschließlich um PHP gekümmert habe. Der Autor erweitert die bestehenden PHP-Funktionen um eigene und gibt auch deren Quelltext an, sodass jeder diese weiteren Funktionen nutzen kann.

Es gibt sehr viele Kleinigkeiten, die ebenfalls zeigen, dass viel Zeit und Mühe und dieses Buch gefloßen sind: Die Typografie lässt keine Wünsche offen, zahlreiche Querverweise gestatten das schnelle Auffinden der relevanten Stelle, die Lösungen zu Übungen sind direkt auf der nächsten Seite, sodass man erst nach Umblättern die Lösung erfährt und nicht irgendwo am Ende des Buches zusammengefasst.

Fazit

Kaufbefehl! Wer sich ernsthaft für reguläre Ausdrücke interessiert, kommt um dieses Buch nicht herum. Mir hat es sehr bei der täglichen Arbeit geholfen und dafür gesorgt, dass ich nach Möglichkeit immer auf reguläre Ausdrücke zurückgreife, sofern dies möglich ist. Ich war erstaunt, als ich feststellte, dass sowohl Microsoft Office als auch OpenOffice.org beide reguläre Ausdrücke bei der Suche unterstützen. Aber auch sonst findet man immer wieder Anwendungsfälle für reguläre Ausdrücke, wo man sie vorher nicht vermutet hätte. Viel wichtiger aber: Probleme, die mir vorher unlösbar komplex erschienen, sind nun dank regulärer Ausdrücke sehr viel einfacher zu lösen.

Rezensiert wird im folgenden das Buch “Programmieren lernen mit C” von Karlheinz Zeiner in der vierten Auflage (ISBN: 3-446-21596-4). Die beiliegende CD habe ich dabei nicht beachtet, da das Buch aus einer Bibliothek ausgeliehen wurde und die CD nicht dabei war.

Das Buch wurde mir von einem Informatiker empfohlen, der am Warzone 2100 Resurrection Project teilnimmt, als ich den Wunsch äußerte eben auch das benötigte C zu lernen, um Code beisteuern zu können (auf absehbare Zeit).

Gute Seiten

Es ist für einen Anfänger äußerst hilfreich, wenn wie im Buch geschehen, Standards beachtet werden. Der Autor beschreibt sowohl C89 als auch C99 und gibt darüberhinaus noch Anleitung wie man mit dem auf der CD mitgelieferten Programm und gcc kompiliert unter Beachtung eben jener Standards.

Das Buch ist in übersichtliche Kapitel angeordnet und es werden Kapitel zu den Themen strukturierte Programmierung und Softwareentwicklung angeschnitten, man erhält also über das Basiswissen in der Programmiersprache auch gleich noch weiterführende Informationen.

Viele der Beispiele erläutern den teils schwierigen Stoff gut, allerdings ist dies noch verbesserungswürdig. Das Buch ist so aufgebaut, dass ein Anfang gemacht wird mit einfachen Hallo Welt!-Programmen, bei denen man als Leser nicht zu viel des verwendeten Codes hinterfragen sollte, da man teilweise erst in einigen Kapiteln später erklärt bekommt, was man da eigentlich genau gemacht hat. Es ist also für Anfänger leicht die ersten paar Programmzeilen zusammenzuschreiben und halbwegs zu wissen was das Programm macht.

Die Kapitel zu den einzelnen Themen widmen sich vielen Themen, manche werden auch mehrfach, aber aus einem anderen Blickwinkel, behandelt, um so das Verständnis zu vertiefen.

Sehr gut gelungen sind die vielen Übungsaufgaben im Buch, auch wenn dies meiner Meinung nach teilweise über das Ziel hinausgeschossen war.

Schlechte Seiten

Viele Erklärungen sind für ein Lehrbuch zu schwammig und ungenau, andere Erklärungen wiederum sind richtig, erklären aber nicht den Sinn (warum sollte ich das benutzen, wenn es so doch auch geht?) eines bestimmten Konstrukts oder die Unterschiede zu einem ähnlichem Konstrukt.

Äußerst ärgerlich sind Fälle wie die Erklärung zu dem Wesen einer inline-Funktion. Man spürt förmlich wie sich der Autor darum windet eine Erklärung abzuliefern. Natürlich hat dies vermutlich den Sinn niemanden zu verschrecken, aber dann sollte man doch explizit sagen, warum man etwas nicht erklärt bzw. erklären kann/will.

Ebenfalls wird erst zu spät im Buch erklärt was der Sinn ist, der hinter der Benutzung von Zeigern steckt. Grundsätzlich ist die Erklärung zu Zeigern, also was Zeiger sind, in wenigen Worten getan, warum aber ist es unmöglich bereits an dieser Stelle zu erklären, dass man Zeiger zum Beispiel deswegen an eine Funktion übergibt, weil man nicht die Variable an sich übergeben möchte, sondern eben nur einen Verweis darauf, um unnötige Kopierarbeiten zu sparen und so effizienter zu sein? Es gibt einige weitere Beispiele dieser Art, die es mir unnötig schwer machten den Sinn hinter bestimmten Features von C zu finden.

Weiterhin finde ich es absolut schwachsinnig mitten im Buch mehrere Kapitel zu bringen (da musste ich mich regelrecht durchquälen), die nichts mit C an sich zu tun hatten, sondern sich um Softwareentwicklung im Allgemeinen drehten. Sowas kann ans Ende gepackt werden in einen Anhang, aber es hat nichts unmittelbar damit zu tun eine Programmiersprache zu lernen, also zu lernen sich in einer Programmiersprache korrekt auszudrücken.

Mir hat auch nicht gefallen, dass am Anfang fast nichts erklärt wird, man den Code in einer “Friss oder stirb!”-Mentalität vor den Latz geknallt bekommt und dann erst später nach und nach alles systematisch angegangen wird. Ein Ansatz, bei dem von Anfang an systematisch erklärt wird, hätte mir um Längen besser gefallen.

Effizienzbetrachtungen habe ich an vielen Stellen vergeblich gesucht. Es ist in jeder Programmiersprache wichtig zu wissen wie effizienter Code arbeitet und welche Probleme es häufig in ineffizientem Code gibt. Gerade C kann doch hervorragend eingesetzt werden, um zeitkritische Dinge mit für andere Sprachen atemberaubender Geschwindigkeit auszuführen und das noch unter geringem Speicherverbrauch (huhu, Java).

Dass viele Dinge am Ende des Buches offen blieben, erkenne ich daran, dass ich insgesamt 53 Fragen (nach der Zahl der Fragezeichen gerechnet) an den Informatiker weitergeleitet habe. Darunter waren eher lapidare Dinge wie Unterschiede zu anderen Plattformen (Endianness), aber auch fundamentale wie der Sinn hinter Unionen, da gerade diese im Buch nur sehr kurz dran kamen. Ebenfalls vermisste ich Beispiele aus der realen Welt, die Gebrauch von Funktionen machen, die eben nicht aus den Standardbibliotheken stammen (Bibliotheken Dritter, keine selbstgemachten). Aber auch Hinweise zum Debugging von Programmen, vor allem welche Möglichkeiten man dazu nutzen kann, wären sehr hilfreich gewesen. Das hätte man als letzte Kapitel nehmen können und, wenn das Buch dann zu dick wäre, eben die Kapitel über Softwareentwicklung rauslassen oder vekürzen können.

Zusätzlich zu all diesen Problemen kommen die vielen kleinen Dinge, die mich enorm störten. Darunter ist das typografische Unding (imho) normalen Text linksbündig zu gestalten. Dazu gesellen sich viele kleine Unschönheiten wie etwa “z.B.” statt “z. B.” und so weiter. Das dauernd zu lesen, sorgt dafür, dass der Spaß daran enorm darunter leidet.

Es hat zwar nur nebensächlich etwas mit dem Buch zu tun, aber Herr Zeiner hat seine Meinung zu C als erste Programmiersprache mittlerweile gewandelt, die Relevanz zur Rezension zum Buch kommt nach dem Zitat:

Heute würde ich für den Schulunterricht vorschlagen, gleich mit C# (oder Java) zu beginnen. Das Hauptproblem von C ist, dass die Programmierung einer zeitgemäßen grafisch orientierten Benutzerschnittstelle in C heute uninteressant ist. Der heutige Jugendliche ist eher für die Gestaltung eines Fensters mit Controls zu motivieren als für das Nachdenken über Algorihmen. Eine Konsolapplikation ist für ihn sehr unattraktiv. In C# kann auch der Anfänger relativ rasch eine Windows-Applikation mit einigen Edit-Controls für die Ein-/Ausgabe erstellen. Allerdings gilt auch für C#: Was man in C lernen muss, muss man auch in C# lernen. Lediglich die Zeiger sind verschwunden.

Quelle: Seite zum Buch von Herrn Zeiner Hervorhebungen von mir.
So wie es mir im Buch vorkam, nehmen Zeiger und die dahinterstehende Logik aber großen Raum in C ein. Wenn man Zeiger nun aber “weglässt”, dann muss dieses Konzept doch denjenigen, der dann doch C machen will, erst noch beigebracht werden, oder nicht? Und die Gestaltung eines Fensters ist nicht die Aufgabe eines Programmierers, sondern die eines GUI-Designers, der sich nach allen Usability-Regeln darum kümmert, dass die Funktionen des Programms über die vorhandene Oberfläche so intuitiv und sinnvoll wie nur irgend möglich genutzt werden können. Und auch wenn sich das einfach anhört, kann dies ein hochbezahlter Job sein. Ich merke daran aber, dass es Herrn Zeiner mit seinem Buch wohl eher darauf angekommen ist das Programmieren zu lehren als Programmieren in C zu lehren. Dies ist sehr schade.

Fazit

Alles in allem kann ich dieses Buch nicht weiterempfehlen für diejenigen, die wie ich gerne ein bisschen mehr wissen wollen, also über den Tellerrand hinausblicken möchten. Nach dem schrittweisen Durcharbeiten des Buches über gut zwei Wochen, sind noch viele Fragen geblieben und da mir o. g. Informatiker anbot meine Fragen zu beantworten, bekam er vier DIN A4-Seiten (mit dem Computer geschrieben) mit 22 teils fundamentalen Problemen und insgesamt 53 Fragen.

Da Herr Zeiner auch vor Veröffentlichung des Buches schon Programmierübungen gegeben hat, liegt es nahe zu vermuten, dass er durch das Zusammenstellen aller Lehreinheiten und Übungsaufgaben versucht hat mit bereits getaner Arbeit Geld zu machen (dies ist eine pure Vermutung, sollte aber nicht unerwähnt bleiben).

Für jemanden, der allerdings noch nie in irgendeiner Form programmiert hat, kann es den ersten Kontakt mit der Programmiersprache C herstellen und, wenn man die Übungen macht (habe ich größtenteils ausgelassen), sollte man auch schnell fit in der Syntax und im “Denken in C” werden. Ich nehme daher auch an, dass das Buch nicht mich als Zielgruppe hatte, da ich bereits erste Erfahrungen darin hatte “wie ein Computer zu denken” und mir wenige Teile daher auch auf die Nerven gingen. Es hilft allerdings jedem, der dieses Buch liest, ungemein, wenn jemand, der sich in C auskennt und etwaige Fragen beantworten kann, zur Verfügung steht.

Da ich keinerlei Praxiserfahrung habe, würde ich mich dennoch immer noch nur als C-Anfänger bezeichnen, was aber nichts mit der Qualität des Buches zu tun hat. Ich wäre wahrscheinlich nach dem Lesen jedes Buches, das in eine Programmiersprache einführt, nicht mehr als ein Anfänger.

Kommentare zu diesem Artikel abgeben (benötigt Boardaccount)