Das Rezepte-Buch von Doberenz und Gewinnus zu Visual Basic 2005 ist umfangreich, gut strukturiert und behandelt sehr zahlreiche Themen, die für den Programmierer wichtig sind. Aber so breit es auch angelegt ist, so oberflächlich ist es zugleich. Und: es handelt sich nur sehr bedingt um ein Buch über 'Visual Basic'. Diese Mängel sind aber nur zum Teil von den Buch-Autoren zu verantworten. Grund ist, dass Microsoft - besonders jetzt mit den Programmiersprachen der 2005er-Kategorie - einen für den Anwendungsprogrammierer aus meiner Sicht sehr nachteiligen*) Weg beschritten hat, weil die Sprachen selbst inhaltlich weitgehend entleert worden sind. Diese Aussage gilt insofern genau so für die Schwestersprachen von VB2005, also etwa C#. Microsoft-Programmiersprachen dienen heute mehr oder weniger nur noch als (formale) Hülle, indem sie z.B. Kontrollstrukturen oder Deklarationsmöglichkeiten anbieten. Inhaltliche, anwendungsorientierte Funktionen, durch die sich früher die Mächtigkeit von Programmiersprachen ausdrückte, sind so gut gut wie vollständig verschwunden. Die Verwendung von VB oder C# wird damit zur reinen Geschmackssache. Die eigentlich Programmierwerkzeuge verbergen sich nun weitestgehend in den .NET-Klassenbibliotheken.
Um bei VB zu bleiben bedeutet dies, dass allein mit 'Visual Basic 2005' gar nicht mehr (sinnvoll) programmiert werden kann, weil für inhaltliche Funktionalität es zwingend erforderlich ist, auf das .NET 2.0 Framework zuzugreifen. Und genau deshalb wird die Lektüre des Visual Basic 2005-Kochbuchs primär zu einem Ritt durch die .NET-Klassenbibliotheken. Und da kann man, wenn man mit den Klassenbibliotheken des .NET-Frameworks nur wenig vertraut ist, nur staunen. Denn die Autoren halten sich keinesfalls damit auf, die einzelnen Bibliotheken und Objekte des .NET-Frameworks, die sie in ihren 'Rezepten' verwenden, irgendwie auch nur ein wenig tiefer gehend zu erläutern, geschweige denn zu erklären, warum sie gerade 'diese' und keine der anderen Bibliothek verwenden, wofür die verwendete Bibliothek primär gedacht sind und über welche - außer den wenigen verwendeten - Funktionalitäten, Methoden und Eigenschaften sie verfügt. Da wird - zum Beispiel - ohne Vorrede plötzlich eine 'MARS-Technologie' hervorgezaubert, zu der nur gesagt wird, sie sei jetzt unter .NET 2.0 'neu' und mit ihr lasse sich eine Menge Code einsparen. Vorsichtshalber wird darauf hingewiesen, dass der Anwender dabei möglichst nicht 'den Originalinhalt ... des SQL-Servers ... benutzen' solle, um ihn beim Experimentieren mit MARS nicht irrtümlich zu 'zerstören'. Dann werden einige wenige Zeilen Code präsentiert, nachdem ein 'Connectionstring MARS-fähig' gemacht worden ist - und voila, ganze Seiten von Code, die vorher aufgelistet wurden, sollen dadurch jetzt überflüssig geworden sein. Warum das so ist, wieso genau 'MARS' dies macht und wie und wofür MARS sonst noch so gut ist, davon ist überhaupt keine Rede. Auch wird nicht erläutert, für welche Problemstellungen und unter welchen Bedingungen der Leser solch ein Rezept sinnvoll (und gefahrlos) einsetzen sollte bzw darf. Stattdessen hoppla-hopp auf zum nächsten 'Rezept', in dem wieder irgend eine neue - vorher nie erwähnte und auch keinesfalls sonst weiter erläuterte - 'Klassenbibliothek' oder ein .NET-Objekt aus den Untiefen des Frameworks gehoben, anhand eines oft wenig praxisnahen Beispiels kurz manipuliert und ... wieder vergessen wird, weil man schon im nächsten 'Rezept' gelandet ist.
Im Prinzip ist das Buch daher eher eine Anregung zu einer anderen Publikation, deren Arbeitstitel wie folgt lauten könnte: welche Rezepte/Nutzungsmöglichkeiten bietet das .NET-2.0-Framework dem Programmierer ? Ein solches Buch müsste jedoch tiefer in die Materie einsteigen, Struktur, Hintergründe, Sinn, Zweck und praxisorientierte Nutzungsmöglichkeiten des .NET.2.0-Frameworks erläutern. Mit welcher Hülle - sprich: Programmiersprache - dann diese Bibliotheken aufgerufen werden, ist letztlich unerheblich. Sinnvoll und kritisch nutzen kann der Leser das Kochrezepte-Buch von Doberenz und Gewinnus daher nur, wenn er schon ein größeres Verständnis des .NET 2.0-Frameworks hat.
*) Warum ich die 'Entleerung' der Programmiersprachen für gefährlich halte ? Ganz einfach: weil man Anwendungen, die man im Laufe von Jahren mühsam mit Hilfe von VB (oder C# ..) und - im wesentlichen - des Frameworks aufbauen wird, wieder 'wegwerfen' darf, wenn bei der mit Sicherheit später einmal erfolgenden Ablösung des Frameworks durch eine neue Technologie wie üblich eine vermutlich fast vollständige Inkompatbilität gegeben sein wird. Wären hingegen die auch inhaltlichen Funktionalitäten, die nun im Framework enthalten sind, weiterhin Bestandteil der Sprache 'Visual Basic' selbst, stünde Microsoft in der Pflicht und müsste die Sprache an die neue Softwareumgebung anpassen. So aber hat der Programmierer den Schwarzen Peter und darf zusehen, wie er dann seine mühsam mit .NET 2.0 geschriebenen Anwendungen auf die Bibliotheken der dann 'neu' präsentierten Technologien umstellt ... Die in bescheidenem Umfang weiterhin 'kompatbile' Syntax der formalen Sprachhülle von Visual Basic selbst wird ihm dabei dann herzlich wenig nutzen.
