Waehrend meines Studiums hatte ich das erste mal Kontakt mit der objektorientieren Programmierung. Sun hatte etwas neues angekuendigt, ein halb uebersetztes und halb interpretiertes Programmkonzept mit passender Programmiersprache, naemlich Java. Seit der Version 0.9 habe ich das Ganze begleitet, es wurde sogar Thema meiner Diplomarbeit. Folgerichtig hat sich auch meine erste festangestellte Lohntaetigkeit mit Java Anwendungs- und Systementwicklung beschaeftigt.
Ich oute mich hier jetzt mal: ich mag Java! Die Sprache selber ist schnoerkellos und fuer meinen Geschmack so Objektorientiert wie moeglich. Zeigeroperationen und die damit verbundenen Schweinereien habe ich nicht lange vermisst. Doch selbst ich muss sagen, dass Java-Applets nicht unbedingt eine gute Idee waren und ich dem Java-Chip immer noch eine Traene hinterher weine. Als Sun beschloss Swing mit in das Paket aufzunehmen wurde unser Verhaeltnis ein wenig angespannt, trotzdem hat es nicht fuer den Bruch gereicht.
Waehrend des Aufstiegs von Java stieg auch eine andere Objektorientierte Sprache auf der Beliebtheitsskala: C++. In meinem jugendlichen Leichtsinn dachte ich damals, wenn ich schon C und Java kann, sollte C++ eigentlich gar kein Problem sein. Leider war dem voellig anders. Die Syntax war verwirrend und immer wieder hatte ich das Gefuehl, dass da ein Alpha Produkt zu frueh veroeffentlicht wurde. Die guten Ideen waren deutlich erkennbar aber Umsetzung und Kompromisse haben mich wenig Begeistert. Templates im Allgemeinen und die STL im Speziellen haben mich dann ueberzeugt, dass C++ nicht wirklich ernst gemeint sein kann. Eine Makrosammlung fuer C ist noch keine neue Programmiersprache sondern bestenfalls ein Beitrag fuer den
Obfuscated C Wettbewerb.
Ungluecklicherweise wird es immer schwerer sich von C++ fern zu halten. Grade wenn man auch mal was anderes als eine Konsolenanwendung schreiben will. Die gebraaeuchichen Bibliotheken fuer Benutzeroberflaechen setzen alle auf C++ auf. Mit SvOllis Partyman/
SLART Projekt gibt es schon einen Grund fuer mich, mich doch mit C++ auseinanderzusetzen, ich befuerchte naemlich, dass ich da auh noch dran herumpfuschen muss um die Fernbedienungssteuerung nach meinen Wuenschen zu realisieren. Zu allem Ueberfluss hat mir Trolltech auf einer Messe einengar wunderbaren USB-Hub mit Tassenwaermer ueberreicht. Ich bin wohl doch kaeuflich. Muss ich mir die C++ Literatur und QT Dokumentation wohl doch noch mal antun. Und im Lebenslauf macht sich so was bestimmt auch gut.
Kommentare
Das hat allerdings auch einen geschichtlichen Grund.
C++ wurde so entworfen, dass bestehende C-Projekte, wenn sie einigermaßen vernünftig gecodet sind, nach Möglichkeit ohne Änderung übernommen werden können. Auch sollten C-Bibliotheken linkbar sein, damit von Anfang an viel erprobter Code zur Verfügung steht. Diese Designentscheidung zur Geburt der Sprache hat zu syntaktischen Konstruktionen geführt, die einem manchmal nur den Kopf schütteln lassen. C ist nun einmal eher ein portabler Makro-Assembler (und gerade deshalb oft gut brauchbar). Es ist ja hübsch, wenn man auf einmal Klassen, Objekte und Referenzen hat; aber die ollen Pointer mit allen ihren Fallstricken bestehen weiterhin. So ein Pointer ist nun einmal ein Konzept aus der "low-level"-Welt, es ist die Adresse eines Objektes im Speicher.
Und denn hat sich der Stroustroup (und wer immer alles mit ihm diskutiert hat) auch noch gesagt, dass auch C++ einen sehr effizienten Code erzeugen muss, wenn die Sprache in "C-Kreisen" Interesse finden soll. Dabei entstanden solche Ideen wie die Templates, die in der Tat ein besserer Ersatz für Makros sind und die Inline-Funktionen, die ebenfalls die meisten Präprozessor-Häcks überflüssig machen.
In der Gesamtwirkung ist C++ eine Sprache, die zwei Welten zusammenbringt, die nicht recht zueinander passen wollen. Das diese Sprache dennoch oft und gern genommen wird, liegt eben daran, dass sie zwei Welten zusammenbringt, die nicht recht zueinander passen wollen -- aber elegant und durchschaubar ist das meist nicht.
Für einen Java-Programmierer ist die Speicherverwaltung in C++ wohl das Übelste. Java geht nun einmal davon aus, dass Speicher eine zu wichtige Ressource ist, um dem Programmierer die Bürde der Kontrolle darüber aufzuhalsen und hat deshalb einen anständigen garbage collector. Und C++ geht davon aus, dass Speicher eine zu wichtige Ressource ist, um sie irgendeinem Automatismus zu überlassen, der nicht unter der Kontrolle des Programmierers steht. Beide Ansätze können zu völlig sinnfreien Diskussionen führen, welcher denn nun der bessere ist -- in der Praxis hat man leider meist nicht die Wahl, sondern ist durch diverse Sachzwänge an eine der Sprachen und damit an eines der Konzepte gebunden. Der C++-Weg ist jedenfalls schwieriger zu beherrschen, die Entwicklungszeiten sind allein wegen der Speicherverwaltung und der damit verbundenen Probleme weitaus größer.
Die STL ist wohl so ziemlich das Irrsinnigste, was sich jemals in eine moderne Programmiersprache eingeschlichen hat. Die Template-Konstruktionen werden in einer Weise verwendet, die zwar effizient und "inline" ist, aber auch den vom Compiler erzeugten Code gewaltig aufblähen kann. Ich würde sogar sagen, dass die STL ein Missbrauch von C++ ist, ein kryptischer Weg, der besser nicht hätte beschritten werden sollen. Dies zeigt sich vor allem darin, dass sich die Konzepte der Bibliothek nicht in der Programmiersprache selbst ausdrücken lassen, sondern in einer Dokumentation beschrieben werden müssen.