Manchmal schreibe ich auch hier über das Programmieren. Heute ist es – „mal wieder“ so weit. Angefangen hat es bei mir so ungefähr mit 16 in der Schule, ein TI-irgendetwas in Basic Programmieren. Ich habe mich dBase II und dBase III probiert (zu meiner Zeit bei der BW) und später Dipl-Wing (Vertiefungsausbildung IT/OR) in Karlsruhe. Richtig schlecht war ich in der Programmierung von Modula-2, es hat mich aber immer interessiert, und dann habe ich Eiffel gelernt und das ist eine reine OO-Sprache. Und damit denke ich sagen zu können, mir ist OO sehr geläufig. Ich stellte aber fest:
Manchmal sind Daten einfach nur Daten
Und genau das läuft m.E. schief in den OO-Sprachen. Nein, nicht immer gehören Daten + Programme zusammen. Manchmal sind Daten einfach nur Daten und speziell geilt es für Aufbereitung in XML und was eben dem auch nicht entspricht, sind Relationen in relationalen Datenbanken und hier beißt es sich komplett. Wenn man alles durch Objekte zwängen muß wird viel Zeit einfach nur in die Serialisierung gesteckt. Meine Frage – wofür? Ich mag das nicht. Und ja, ich denke, das ist nicht nur mein Problem.
Im Mythical Man months heißt es auch:
Die Kernaussage: Die Datenstrukturen sind wichtiger als der Code. Wer die Daten(strukturen) eines Systems versteht, versteht auch die Logik fast von selbst – umgekehrt gilt das nicht. In moderner Form wird der Spruch oft Eric S. Raymond zugeschrieben, der ihn in „The Cathedral and the Bazaar“ griffiger formuliert hat:
„Smart data structures and dumb code works a lot better than the other way around.“
Nach über einem Jahr, daß ich mit dem Lernen von C# und Datenbanken verbrachte, habe ich es dran gegeben und bin auf Access VBA zurückgegangen. Was soll ich sagen, es läuft so besser.
Was mich auch erstaunt. Ich finde C eine gute Sprache und kann C++ nicht ausstehen. Ich finde, es liegt am selben Grund. Komplexität ohne einen für mich sichtbaren Gewinn, kann ich wohl nicht leiden.
Vielleicht wäre es gut, wir besinnen uns auf Datenstrukturen und Algorithmen und knallen nicht alles in Objekthierarchien oder Objekte. Mal sind Objekte gut und richtig und manchmal eben nicht.


















